VMWare on 2.6.0-test9?
Simon Hill
Thanks.
Petr Vandrovec
> Does test9 need any more patches after 'update 43' to get VMWare working?
No. Just ignore message vmnet prints - both test8 and test9 contains patch to
get bridged networking to work.
Petr
David K
I'm still having problems though:
---
sudo vmware-config.pl
Password:
Making sure VMware Workstation's services are stopped.
Stopping VMware services:
Virtual machine monitor [ OK ]
Bridged networking on /dev/vmnet0 [ OK ]
DHCP server on /dev/vmnet8 [ OK ]
NAT networking on /dev/vmnet8 [ OK ]
Host-only networking on /dev/vmnet8 [ OK ]
Virtual ethernet [ OK ]
grep: /proc/ksyms: No such file or directory
grep: /proc/ksyms: No such file or directory
grep: /proc/ksyms: No such file or directory
Trying to find a suitable vmmon module for your running kernel.
None of VMware Workstation's pre-built vmmon modules is suitable for your
running kernel. Do you want this program to try to build the vmmon module for
your system (you need to have a C compiler installed on your system)? [yes]
Using compiler "/usr/bin/gcc". Use environment variable CC to override.
What is the location of the directory of C header files that match your running
kernel? [/lib/modules/2.6.0-0.test9.1.67/build/include]
Extracting the sources of the vmmon module.
Building the vmmon module.
Building for VMware Workstation 4.x.x
make: Entering directory `/tmp/vmware-config6/vmmon-only'
make[1]: Entering directory `/tmp/vmware-config6/vmmon-only'
make[2]: Entering directory `/tmp/vmware-config6/vmmon-only/driver-2.6.0-0.test9.1.67'
make[2]: Leaving directory `/tmp/vmware-config6/vmmon-only/driver-2.6.0-0.test9.1.67'
make[2]: Entering directory `/tmp/vmware-config6/vmmon-only/driver-2.6.0-0.test9.1.67'
In file included from ../common/hostif.h:18,
from ../common/task.C:43:
../include/vcpuset.h: In function `VCPUSet VCPUSet_SingletonChecked(unsigned
int)':
../include/vcpuset.h:52: warning: comparison between signed and unsigned
integer expressions
make[2]: Leaving directory `/tmp/vmware-config6/vmmon-only/driver-2.6.0-0.test9.1.67'
make[1]: Leaving directory `/tmp/vmware-config6/vmmon-only'
make: Leaving directory `/tmp/vmware-config6/vmmon-only'
Unable to make a vmmon module that can be loaded in the running kernel:
insmod: error inserting '/tmp/vmware-config6/vmmon.o': -1 File exists
There is probably a slight difference in the kernel configuration between the
set of C header files you specified and your running kernel. You may want to
rebuild a kernel based on that directory, or specify another directory.
For more information on how to troubleshoot module-related problems, please
visit our Web site at "http://www.vmware.com/download/modules/modules.html" and
"http://www.vmware.com/support/reference/linux/prebuilt_modules_linux.html".
Execution aborted.
---
After doing this the vmmon module is loaded, and I can't get it to unload.
Any ideas?
Regards, David
Petr Vandrovec
> make[1]: Leaving directory `/tmp/vmware-config6/vmmon-only'
> make: Leaving directory `/tmp/vmware-config6/vmmon-only'
> Unable to make a vmmon module that can be loaded in the running kernel:
> insmod: error inserting '/tmp/vmware-config6/vmmon.o': -1 File exists
^^^^^^^^^^^
You have vmmon loaded. Are you sure that you built your kernel with support
for 'rmmod' ? What happens if you do 'lsmod; rmmod vmmon; lsmod' ?
Petr
David K
Yes, I use Red Hat's precompiled kernels (this one from
http://people.redhat.com/~arjanv/2.5/RPMS.kernel/ )
I can insert/remove other modules (just tried it, to make sure).
lsmod:
Module Size Used by
vmmon 70649 1
-snip-
rmmod:
ERROR: Module vmmon is in use
lsmod:
Module Size Used by
vmmon 70649 1
-snip-
"service vmware stop" (same as /etc/init.d/vmware stop) says:
At least one instance of VMware Workstation is still running. Please stop all running
instances of VMware Workstation first.
I tried changing all ksyms -> kallsyms in vmware-config.pl too, it does
not seem to help.
I can, however, run vmware if I reboot into kernel 2.4.22-1.2088.nptl, but
there's hardware in my box that does not work good with the 2.4.x-kernels.
OTOH, since the 2.6-kernel is still beta, I'm not expecting everything
to run perfectly just yet :)
Thanks for your help, please let me know if there's anything else I can
try to get it working.
Regards, David
Petr Vandrovec
> On Thu, 30 Oct 2003 15:54:13 +0100, Petr Vandrovec wrote:
>
>
>>David K wrote:
>>
>>>>make[1]: Leaving directory `/tmp/vmware-config6/vmmon-only'
>>>
>>>make: Leaving directory `/tmp/vmware-config6/vmmon-only'
>>>Unable to make a vmmon module that can be loaded in the running kernel:
>>>insmod: error inserting '/tmp/vmware-config6/vmmon.o': -1 File exists
>>
>> ^^^^^^^^^^^
>>
>>You have vmmon loaded. Are you sure that you built your kernel with support
>>for 'rmmod' ? What happens if you do 'lsmod; rmmod vmmon; lsmod' ?
>> Petr
>
>
> Yes, I use Red Hat's precompiled kernels (this one from
> http://people.redhat.com/~arjanv/2.5/RPMS.kernel/ )
>
> I can insert/remove other modules (just tried it, to make sure).
>
> lsmod:
> Module Size Used by
> vmmon 70649 1
> -snip-
>
> there's hardware in my box that does not work good with the 2.4.x-kernels.
> OTOH, since the 2.6-kernel is still beta, I'm not expecting everything
> to run perfectly just yet :)
Create /etc/vmware/not_configured file. Reboot to 2.6.x kernel. Do
"insmod /lib/modules/2.6.*/misc/vmmon.o". Do "lsmod". Try "rmmod vmmon"...
Then remove /etc/vmware/not_configured (so /etc/init.d/vmware script can work).
If you'll get 'used by 1' in the 'lsmod', then you are out of luck, and your kernel
was built without 'rmmod' support. Probably. You can also run 'dmesg' after doing
'insmod'. Maybe it will reveal something interesting...
Petr
Petr Vandrovec
>
> If you'll get 'used by 1' in the 'lsmod', then you are out of luck, and
> your kernel
> was built without 'rmmod' support. Probably. You can also run 'dmesg'
> after doing
> 'insmod'. Maybe it will reveal something interesting...
As RPM's (2.6.0-0.test9.1.67) configs say that unload is enabled, 'dmesg' is probably
only way to go... Maybe 'fuser /dev/vmmon' could reveal something too.
Petr
Simon Roberts
I'm having exactly the same problem (vmware 4.05, kernel 2.6.0-test9
from http://people.redhat.com/arjanv/2.5/RPMS.kernel/, and
vmware-any-any-update43). I have more information if it helps (this
is from a fresh boot):
[root@simon-linux root]# rpm -q VMwareWorkstation
VMwareWorkstation-4.0.5-6030
[root@simon-linux root]# uname -a
Linux simon-linux.fifthweb.net 2.6.0-0.test9.1.67smp #1 SMP Tue Oct 28
08:42:17 EST 2003 i686 i686 i386 GNU/Linux
[root@simon-linux root]# lsmod | sort
ata_piix 8068 5
autofs 16512 0
ext3 104360 2
ieee1394 214188 1 ohci1394
iptable_filter 3584 1
ip_tables 17536 1 iptable_filter
ipv6 229312 10
jbd 56728 1 ext3
libata 35456 1 ata_piix,[permanent]
md5 4736 1
Module Size Used by
ohci1394 31624 0
parport 40552 1 parport_pc
parport_pc 25640 0
raid0 8320 1
scsi_mod 110256 2 sd_mod,libata
sd_mod 15904 7
sk98lin 138176 1
[root@simon-linux root]# cd vmware-any-any-update43/
[root@simon-linux vmware-any-any-update43]# ./runme.pl
Updating /usr/bin/vmware ... Unknown version
Sorry, there is no binary patch available for your version of vmware.
VMware modules in "/usr/lib/vmware/modules/source" has been updated.
Before running VMware for the first time after update, you need to
configure it
for your running kernel by invoking the following command:
"/usr/bin/vmware-config.pl". Do you want this script to invoke the
command for
you now? [yes]
Stopping VMware services:
Virtual machine monitor [ OK ]
Bridged networking on /dev/vmnet0 [ OK ]
DHCP server on /dev/vmnet8 [ OK ]
NAT networking on /dev/vmnet8 [ OK ]
Host-only networking on /dev/vmnet8 [ OK ]
Virtual ethernet [ OK ]
Trying to find a suitable vmmon module for your running kernel.
None of VMware Workstation's pre-built vmmon modules is suitable for
your
running kernel. Do you want this program to try to build the vmmon
module for
your system (you need to have a C compiler installed on your system)?
[yes]
Using compiler "/usr/bin/gcc". Use environment variable CC to
override.
What is the location of the directory of C header files that match
your running
kernel? [/lib/modules/2.6.0-0.test9.1.67smp/build/include]
Extracting the sources of the vmmon module.
Building the vmmon module.
Building for VMware Workstation 4.x.x
make: Entering directory /tmp/vmware-config0/vmmon-only'
make[1]: Entering directory /tmp/vmware-config0/vmmon-only'
make[2]: Entering directory
/tmp/vmware-config0/vmmon-only/driver-2.6.0-0.test9.1.67smp'
make[2]: Leaving directory
/tmp/vmware-config0/vmmon-only/driver-2.6.0-0.test9.1.67smp'
make[2]: Entering directory
/tmp/vmware-config0/vmmon-only/driver-2.6.0-0.test9.1.67smp'
In file included from ../common/hostif.h:18,
from ../common/task.C:43:
../include/vcpuset.h: In function VCPUSet
VCPUSet_SingletonChecked(unsigned
int)':
../include/vcpuset.h:52: warning: comparison between signed and
unsigned
integer expressions
make[2]: Leaving directory
/tmp/vmware-config0/vmmon-only/driver-2.6.0-0.test9.1.67smp'
make[1]: Leaving directory /tmp/vmware-config0/vmmon-only'
make: Leaving directory /tmp/vmware-config0/vmmon-only'
vmmon: no version for "struct_module" found: kernel tainted.
vmmon: no version magic, tainting kernel.
vmmon: module license 'unspecified' taints kernel.
Unable to handle kernel NULL pointer dereference at virtual address
000000a5
printing eip:
c01cdc60
*pde = 7ce8e067
Oops: 0000 [#1]
CPU: 1
EIP: 0060:[<c01cdc60>] Tainted: PF
EFLAGS: 00010202
EIP is at misc_register+0x3f/0x108
eax: c02fbc8c ebx: 000000a5 ecx: c0305120 edx: c030512c
esi: c02f7b08 edi: f8b0257c ebp: f5ba5fac esp: f5ba5f88
ds: 007b es: 007b ss: 0068
Process insmod (pid: 1985, threadinfo=f5ba4000 task=f594c080)
Stack: c02c53cc f8b01f00 f8af11c0 f8b02528 f8b01f00 f5ba5fac f8af10b9
00000000
c02c53b0 f5ba4000 c0132a5c 09ff5018 00000000 00000000 c010a413
09ff5018
000175f7 09ff5008 00000000 00000000 bfecc468 00000080 0000007b
0000007b
Call Trace:
[<f8af11c0>] init_module+0x13e/0x1aa [vmmon]
[<f8af10b9>] init_module+0x37/0x1aa [vmmon]
[<c0132a5c>] sys_init_module+0x104/0x212
[<c010a413>] syscall_call+0x7/0xb
Code: 8b 03 39 01 74 44 8b 51 0c 8d 42 f4 89 c1 8b 40 0c 0f 18 00
Unable to make a vmmon module that can be loaded in the running
kernel:
<4>vmmon: no version magic, tainting kernel.
insmod: error inserting '/tmp/vmware-config0/vmmon.o': -1 File exists
us...@domain.invalid
(this message might be a duplicate, I posted via google groups, which
may not get gated here correctly)
I am having exactly the same problem (same version of VMware, same
kernel from http://people.redhat.com/arjanv/2.5/RPMS.kernel/, same
vmware-any-any-43 patch).
As discussed in a seperate thread, this is causing a NULL pointer
dereference problem upon loading, leaving the kernel/vmmon module in a
mixed up state. My experience was something like this:
Stopping VMware services:
Virtual machine monitor [ OK ]
Bridged networking on /dev/vmnet0 [ OK ]
DHCP server on /dev/vmnet8 [ OK ]
NAT networking on /dev/vmnet8 [ OK ]
Host-only networking on /dev/vmnet8 [ OK ]
Virtual ethernet [ OK ]
Trying to find a suitable vmmon module for your running kernel.
None of VMware Workstation's pre-built vmmon modules is suitable for your
running kernel. Do you want this program to try to build the vmmon
module for
your system (you need to have a C compiler installed on your system)? [yes]
Using compiler "/usr/bin/gcc". Use environment variable CC to override.
What is the location of the directory of C header files that match your
running
kernel? [/lib/modules/2.6.0-0.test9.1.67smp/build/include]
Extracting the sources of the vmmon module.
Building the vmmon module.
Building for VMware Workstation 4.x.x
make: Entering directory /tmp/vmware-config0/vmmon-only'
make[1]: Entering directory /tmp/vmware-config0/vmmon-only'
make[2]: Entering directory
/tmp/vmware-config0/vmmon-only/driver-2.6.0-0.test9.1.67smp'
make[2]: Leaving directory
/tmp/vmware-config0/vmmon-only/driver-2.6.0-0.test9.1.67smp'
make[2]: Entering directory
/tmp/vmware-config0/vmmon-only/driver-2.6.0-0.test9.1.67smp'
In file included from ../common/hostif.h:18,
from ../common/task.C:43:
../include/vcpuset.h: In function VCPUSet VCPUSet_SingletonChecked(unsigned
int)':
../include/vcpuset.h:52: warning: comparison between signed and unsigned
integer expressions
make[2]: Leaving directory
Unable to make a vmmon module that can be loaded in the running kernel:
<4>vmmon: no version magic, tainting kernel.
insmod: error inserting '/tmp/vmware-config0/vmmon.o': -1 File exists
lyr...@hotmail.com
> What is the location of the directory of C header files that match your
> running
> kernel? [/lib/modules/2.6.0-0.test9.1.67smp/build/include]
> Extracting the sources of the vmmon module.
I've had a look around the vmware code, and it looks okay to me
(passing a <linux/miscdevice.h> miscdevice to misc_register). Could it
be a struct alignment issue (ie: kernel is compiled one way, vmware
another)? I thought it might be SMP-related, but my UP kernel does the
same thing.
Petr Vandrovec
> Petr Vandrovec wrote:
>
>> Petr Vandrovec wrote:
>>
>>>
>>> If you'll get 'used by 1' in the 'lsmod', then you are out of luck,
>>> and your kernel
>>> was built without 'rmmod' support. Probably. You can also run 'dmesg'
>>> after doing
>>> 'insmod'. Maybe it will reveal something interesting...
>>
>>
>>
>> As RPM's (2.6.0-0.test9.1.67) configs say that unload is enabled,
>> 'dmesg' is probably
>> only way to go... Maybe 'fuser /dev/vmmon' could reveal something too.
>> Petr
>>
>
> (this message might be a duplicate, I posted via google groups, which
> may not get gated here correctly)
>
> I am having exactly the same problem (same version of VMware, same
> kernel from http://people.redhat.com/arjanv/2.5/RPMS.kernel/, same
> vmware-any-any-43 patch).
linux-2.6.0-compile.patch in Arjan's kernel is responsible for that. It
adds -mregparm=3 to the CFLAGS, completely breaking ABI: functions do not expect
arguments on the stack, but in registers (and so misc_register() uses leftover
165 value in EAX as a miscdevice pointer...).
Only possible fix is that we'll require you to install complete kernel
sources (not only headers, but full sources, with Makefiles & everything)
and we'll use these Makefiles to fetch correct CFLAGS.
And it is impossible to use correct CFLAGS, as vmmon REQUIRES to be built with
-mregparm=0, otherwise assembly code contained in it will not work correctly.
And if you'll talk to Arjan: in his packages there is /boot/vmlinux-* symlink
to /usr/lib/debug/.... In which package I can find /usr/lib/debug/... file?!
Or is debugging of RH's kernels no longer supported?
For now only solution is NOT using RedHat's kernels. You can try adding
-mregparm=3 to the CC_KFLAGS in vmmon-only/Makefile and vmnet-only/Makefile, but
I'm about 90% sure that poweron attempt will reboot your host.
Petr
Simon Roberts
> adds -mregparm=3 to the CFLAGS, completely breaking ABI: functions do
> not expect arguments on the stack, but in registers (and so
> misc_register() uses leftover 165 value
> in EAX as a miscdevice pointer...).
>
> Only possible fix is that we'll require you to install complete kernel
> sources (not only headers, but full sources, with Makefiles & everything)
> and we'll use these Makefiles to fetch correct CFLAGS.
>
> And it is impossible to use correct CFLAGS, as vmmon REQUIRES to be
> built with
> -mregparm=0, otherwise assembly code contained in it will not work
> correctly.
> And if you'll talk to Arjan: in his packages there is /boot/vmlinux-*
> symlink
> to /usr/lib/debug/.... In which package I can find /usr/lib/debug/...
> file?!
> Or is debugging of RH's kernels no longer supported?
>
> For now only solution is NOT using RedHat's kernels. You can try adding
> -mregparm=3 to the CC_KFLAGS in vmmon-only/Makefile and
> vmnet-only/Makefile, but
> I'm about 90% sure that poweron attempt will reboot your host.
> Petr
>
Thanks a lot for your quick reply (in the weekend, no less). I've been
banging my head against this for a couple of days. I could see that the
vmware code looked to be doing the right thing, but my printk in
misc_register weren't being called the time that it crashed. Uuugh. It
smelled like an alignment issue, or something, and I guess that the
mregparam=3 is the most extreme example of that :)
Rebuilding the kernel RPM without the -mregparam=3 from the patch fixed
everything. Was it just a performance hack?
It's all working beautifully now, thanks again for your help.
Simon
Petr Vandrovec
> Rebuilding the kernel RPM without the -mregparam=3 from the patch fixed
> everything. Was it just a performance hack?
Yes. Or maybe code size hack.
> It's all working beautifully now, thanks again for your help.
It needs fixing...
Petr
Simon Roberts
Which end do you feel is broken?
Simon Roberts
Chuck Gladu
>(this message might be a duplicate, I posted via google groups, which
>may not get gated here correctly)
Complain to Google.
They should not be allowing you the option of posting to these groups
as they do not route the messages to news.vmware.com (only to their
own server)
--
Chuck Gladu
Please note: I am not a VMware employee and I do not
provide VMware support or answer VMware questions via
e-mail. Please limit your replies/questions to the
VMware newsgroups rather than e-mailing me directly.
Petr Vandrovec
I believe that it is very bad idea to use -mregparm=3, but vmmon/vmnet/vmhgfs/vmxnet
build scripts will have to cope with it somehow. I have some solution (~3 years old...)
but it has very negative impact on other users, as you then need full kernel
sources to build modules, and vmmon can no longer check for you whether gcc version
matches & whether kernel sources match with running kernel. Which is rather unfortunate
and will be killer for SuSE systems (where no checks at insmod time are done) and
will complicate life for Debian users (where currently ~1MB kernel-headers are sufficient
instead of ~30MB kernel-sources).
Petr
Ralf Ertzinger
> And it is impossible to use correct CFLAGS, as vmmon REQUIRES to be built with
> -mregparm=0, otherwise assembly code contained in it will not work correctly.
> And if you'll talk to Arjan: in his packages there is /boot/vmlinux-* symlink
> to /usr/lib/debug/.... In which package I can find /usr/lib/debug/... file?!
> Or is debugging of RH's kernels no longer supported?
I put this in RedHat bugzilla, bug id #108929. The basic response is "this
is vmware's fault".
Petr Vandrovec
Try update44. It should work on recent 2.6.x kernels. Hopefully it should work also
on 2.4.x and 2.2.x kernels. If you have such, please try update44, and tell me if
something goes wrong. I tested 2.6.0-test9-c1413 and 2.4.22-ac1 only. And if you have
RH's 2.6.x kernel, do 'sync' before powering on VM.
Petr
Michael
>
> Try update44. It should work on recent 2.6.x kernels. Hopefully it should work also
> on 2.4.x and 2.2.x kernels. If you have such, please try update44, and tell me if
> something goes wrong. I tested 2.6.0-test9-c1413 and 2.4.22-ac1 only. And if you have
> RH's 2.6.x kernel, do 'sync' before powering on VM.
> Petr
Hi Petr,
Thanks a heaps for your patch. I have tried it with Arjan's Redhat
kernel http://people.redhat.com/arjanv/2.5/kernel-2.6.0-0.test9.1.70.rpm
Ran runme.pl from your update44. Created a new VM, did 'sync' before
power on and the results are not particularly nice. I have a core dump
if you want it, 8MB in size....
From vmware.log :
,.. Normal looking log until,..
Nov 06 12:47:11: vmx| No valid NVRAM file found, will create default
NVRAM.
Nov 06 12:47:11: vmx| Using unified VGA.
Nov 06 12:47:11: vmx| SVGA frame buffer size 0x01000000
Nov 06 12:47:11: vmx| USB: Initializing UHCI host controller
Nov 06 12:47:11: vmx| USB: Initializing USB Generic backend
Nov 06 12:47:11: vmx| USB: Unable to open "/proc/bus/usb/devices" (No
such file or directory).
Nov 06 12:47:11: vmx| USB: Unable to initialize USB Generic backend.
Nov 06 12:47:11: vmx| VMMon_GetkHzEstimate: Calculated 1887707 kHz
Nov 06 12:47:11: vmx| VLANCE: send cluster threshold is 80, size = 3
recalcInterval is 2 ticks
Nov 06 12:47:11: vmx| Ethernet0 MAC Address: 00:0c:29:3c:b6:50
Nov 06 12:47:11: vmx| VMXNET: send cluster threshold is 80, size = 3
recalcInterval is 2 ticks
Nov 06 12:47:11: vmx| VMX_PowerOn: ModuleTable_PowerOn = 1
Nov 06 12:47:11: vmx| VMX_PowerOn: Barrier_Last = 1
Nov 06 12:47:11: vcpu-0| VTHREAD thread 4 "vcpu-0" pid 2082 started
Nov 06 12:47:11: vmx| VTHREAD create thread 4 "vcpu-0"
Nov 06 12:47:11: vmx| TOOLS DnD rpc state already set to 0
Nov 06 12:47:11: vmx| TOOLS received request in VMX to set option
'enableDnD' -> '0'
Nov 06 12:47:13: vmx| Caught signal 11 -- pid 2076
Nov 06 12:47:13: vmx| SIGNAL: eip 0x4017e841 esp 0xbffff0dc ebp 0xbffff128
Nov 06 12:47:13: vmx| SIGNAL: eax 0xfffffffc ebx 0x1c ecx 0xbffff300
edx 0xbffff280 esi 0x0 edi 0xbffff170
Nov 06 12:47:13: vmx| SIGNAL: stack 0xbffff0dc : 0x00000000 0x00000000
0x000186a0 0x00000000
Nov 06 12:47:13: vmx| SIGNAL: stack 0xbffff0ec : 0x080f1938 0x0000001c
0xbffff300 0xbffff280
Nov 06 12:47:13: vmx| SIGNAL: stack 0xbffff0fc : 0x00000000 0xbffff170
0x403ff044 0xbffff138
Nov 06 12:47:13: vmx| SIGNAL: stack 0xbffff10c : 0x407ff06c 0x00000000
0xbffff300 0xbffff138
Nov 06 12:47:13: vmx| SIGNAL: stack 0xbffff11c : 0x082381c0 0xbffff170
0xbffff300 0xbffff398
Nov 06 12:47:13: vmx| SIGNAL: stack 0xbffff12c : 0x080edb85 0x0000001c
0xbffff300 0xbffff280
Nov 06 12:47:13: vmx| SIGNAL: stack 0xbffff13c : 0x00000000 0xbffff170
0x00000002 0x0829bd10
Nov 06 12:47:13: vmx| SIGNAL: stack 0xbffff14c : 0x082381dc 0x40429b28
0x00000001 0x0000000e
Nov 06 12:47:13: vmx| Backtrace:
Nov 06 12:47:13: vmx| Backtrace[0] 0xbfffed48 eip 0x80f1194
Nov 06 12:47:13: vmx| Backtrace[1] 0xbfffed78 eip 0x80f0fb0
Nov 06 12:47:13: vmx| Backtrace[2] 0xbfffedfc eip 0x4005e4be
Nov 06 12:47:13: vmx| Backtrace[3] 0xbffff128 eip 0x400cc5d8
Nov 06 12:47:13: vmx| Backtrace[4] 0xbffff398 eip 0x80edb85
Nov 06 12:47:13: vmx| Backtrace[5] 0xbffff3d8 eip 0x80ec9c7
Nov 06 12:47:13: vmx| Backtrace[6] 0xbffff428 eip 0x8058b85
Nov 06 12:47:13: vmx| Backtrace[7] 0xbffff448 eip 0x8058b0c
Nov 06 12:47:13: vmx| Backtrace[8] 0xbffff468 eip 0x8057744
Nov 06 12:47:13: vmx| Backtrace[9] 0xbffff768 eip 0x804e1b5
Nov 06 12:47:13: vmx| Backtrace[10] 0xbffff798 eip 0x804c8c5
Nov 06 12:47:13: vmx| Backtrace[11] 0xbffff7b8 eip 0x400b9a07
Nov 06 12:47:13: vmx| Backtrace[12] 00000000 eip 0x804b941
Nov 06 12:47:13: vmx| Your core dump size limit is 999999 kb.
Nov 06 12:47:13: vmx| Attempting to dump core ...
Nov 06 12:47:13: vmx| VTHREAD thread 0 start exiting
Nov 06 12:47:13: vmx| VTHREAD thread 0 exiting, 1 left
Nov 06 12:47:15: mks| MKS lock got type None
(END)
Cheers,
Michael
David K
When building the vmmon and vmnet modules I get the following messages:
Building for VMware Workstation 4.x.x
make: Entering directory `/tmp/vmware-config2/vmmon-only'
make[1]: Entering directory `/lib/modules/2.6.0-0.test9.1.70/build'
CHK include/linux/version.h
*** Warning: Overriding SUBDIRS on the command line can cause
*** inconsistencies
CHK include/asm-i386/asm_offsets.h
cc1plus: warning: "-Wdeclaration-after-statement" is valid for C/ObjC but not
for C++
Building modules, stage 2.
/lib/modules/2.6.0-0.test9.1.70/build/scripts/Makefile.modpost:17: *** Uh-oh, you have stale module entries. You messed with SUBDIRS,
/lib/modules/2.6.0-0.test9.1.70/build/scripts/Makefile.modpost:18: do not complain if something goes wrong.
make[1]: Leaving directory `/lib/modules/2.6.0-0.test9.1.70/build'
make: Leaving directory `/tmp/vmware-config2/vmmon-only'
The module loads perfectly in the running kernel.
(the same for vmnet)
The modules load fine, it seems, but when I power on the virtual machine
it never gets to even showing the bios bootup text. When I close the VM I
get "Bug 23252: The UI terminated unexpectedly" (probably not surprising).
Regards,
David
Ralf Ertzinger
> Ran runme.pl from your update44. Created a new VM, did 'sync' before
> power on and the results are not particularly nice. I have a core dump
> if you want it, 8MB in size....
>
> From vmware.log :
It's throwing a nice oops, too. This is from 2.6.0-0.test9.1.67:
Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
in_atomic():0, irqs_disabled():1
Call Trace:
[<c0117821>] __might_sleep+0x80/0x8b
[<c0114889>] do_page_fault+0x71/0x42c
[<e08929e8>] do_get_write_access+0x3ed/0x409 [jbd]
[<c01448d7>] __getblk+0x14/0x2b
[<e08eac4d>] ext3_get_inode_loc+0x4f/0x1fc [ext3]
[<e08eb3be>] ext3_do_update_inode+0x2f7/0x31e [ext3]
[<e0892a29>] journal_get_write_access+0x25/0x2c [jbd]
[<c0114818>] do_page_fault+0x0/0x42c
[<c010a2c9>] error_code+0x2d/0x38
[<e0a4c33c>] Task_Switch_V4+0x166/0x866 [vmmon]
[<c012db16>] generic_file_aio_write_nolock+0x7b6/0x8c0
[<e0a49fc6>] Vmx86_RunVM_V4+0x3d/0x200 [vmmon]
[<e0a46cd7>] __LinuxDriver_Ioctl+0x3b6/0x8f8 [vmmon]
[<c0180222>] avc_has_perm+0x3f/0x49
[<c012dc74>] generic_file_write_nolock+0x54/0x6b
[<c0180de5>] inode_has_perm+0x57/0x5f
[<c012f01c>] __alloc_pages+0xb1/0x2e3
[<c0182a3a>] selinux_file_ioctl+0x2fd/0x30e
[<c0137f27>] handle_mm_fault+0x72/0xf7
[<c0142897>] do_sync_write+0x0/0x9d
[<c012ddd7>] generic_file_writev+0x0/0x52
[<c0142dc4>] do_readv_writev+0x235/0x240
[<e0a4730e>] LinuxDriver_IoctlV4+0xba/0xc5 [vmmon]
[<e0a47b3b>] LinuxDriver_Ioctl+0x12b/0x157 [vmmon]
[<c0150361>] sys_ioctl+0x203/0x21e
[<c010a11f>] syscall_call+0x7/0xb
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<00000000>] Tainted: PF
EFLAGS: 00213002
EIP is at 0x0
eax: d25f9488 ebx: d25f9010 ecx: d25f9488 edx: d25f9400
esi: d25f9000 edi: 00000400 ebp: 00000000 esp: d2247d60
ds: 007b es: 007b ss: 0068
Process vmware-vmx (pid: 3196, threadinfo=d2246000 task=d36c26a0)
Stack: e0a4c33c 00000000 d25f9400 d25f9488 00006488 d25f9010 ffff0ff0 00000000
00000000 00000000 000006d0 42864a0c 8005003b 00203246 00000000 0088c000
00330000 d5d78b40 00000060 c012db16 d2247f4c 00000a02 ce0000ff 4286c029
Call Trace:
[<e0a4c33c>] Task_Switch_V4+0x166/0x866 [vmmon]
[<c012db16>] generic_file_aio_write_nolock+0x7b6/0x8c0
[<e0a49fc6>] Vmx86_RunVM_V4+0x3d/0x200 [vmmon]
[<e0a46cd7>] __LinuxDriver_Ioctl+0x3b6/0x8f8 [vmmon]
[<c0180222>] avc_has_perm+0x3f/0x49
[<c012dc74>] generic_file_write_nolock+0x54/0x6b
[<c0180de5>] inode_has_perm+0x57/0x5f
[<c012f01c>] __alloc_pages+0xb1/0x2e3
[<c0182a3a>] selinux_file_ioctl+0x2fd/0x30e
[<c0137f27>] handle_mm_fault+0x72/0xf7
[<c0142897>] do_sync_write+0x0/0x9d
[<c012ddd7>] generic_file_writev+0x0/0x52
[<c0142dc4>] do_readv_writev+0x235/0x240
[<e0a4730e>] LinuxDriver_IoctlV4+0xba/0xc5 [vmmon]
[<e0a47b3b>] LinuxDriver_Ioctl+0x12b/0x157 [vmmon]
[<c0150361>] sys_ioctl+0x203/0x21e
[<c010a11f>] syscall_call+0x7/0xb
Code: Bad EIP value.
Petr Vandrovec
I'm afraid that there is no way how to fix it. Unless either C++ will understand
this option, or RedHat will stop using it.
> Building modules, stage 2.
> /lib/modules/2.6.0-0.test9.1.70/build/scripts/Makefile.modpost:17: *** Uh-oh, you have stale module entries. You messed with SUBDIRS,
> /lib/modules/2.6.0-0.test9.1.70/build/scripts/Makefile.modpost:18: do not complain if something goes wrong.
I'm under impression that you MUST receive this message. If you'll find why
it is generated and what I can do to get rid of it, I'll be happy.
Petr
Petr Vandrovec
>
> Michael (mu...@spamcop.net):
>
> > Ran runme.pl from your update44. Created a new VM, did 'sync' before
> > power on and the results are not particularly nice. I have a core dump
> > if you want it, 8MB in size....
> >
> > From vmware.log :
>
> It's throwing a nice oops, too. This is from 2.6.0-0.test9.1.67:
> EIP: 0060:[<00000000>] Tainted: PF
> EFLAGS: 00213002
> EIP is at 0x0
> eax: d25f9488 ebx: d25f9010 ecx: d25f9488 edx: d25f9400
> esi: d25f9000 edi: 00000400 ebp: 00000000 esp: d2247d60
> ds: 007b es: 007b ss: 0068
> Process vmware-vmx (pid: 3196, threadinfo=d2246000 task=d36c26a0)
> Stack: e0a4c33c 00000000 d25f9400 d25f9488 00006488 d25f9010 ffff0ff0 00000000
> 00000000 00000000 000006d0 42864a0c 8005003b 00203246 00000000 0088c000
> 00330000 d5d78b40 00000060 c012db16 d2247f4c 00000a02 ce0000ff 4286c029
> Call Trace:
> [<e0a4c33c>] Task_Switch_V4+0x166/0x866 [vmmon]
Grr. It generates following code for SwitchToMonitor:
mov %ebx,(%esp,1) <------
push $0x6488
push %ecx
push %edx
push $0
call *(%esp,1) <------
pop %ebx
pop %eax
add $0x14,%esp
and it did not notice that %esp changes between two lines marked with "<-----". I'll
have to reread GCC inline asm manual to find how to tell to gcc that %esp changes
during execution of this asm block. Besides that it could do simple 'call %ebx' and
everybody would be happy then...
For now try vmware-any-any-update45. I changed constraint for 'codePtr' from rm to r,
so code generated for this particular case looks correct to me now. But there is dozen of
other variables (newDstVA, src, dst) which still have 'g' constraint, and which could
trigger generating wrong code under some circumstances.
Petr
David K
>> > on 2.4.x and 2.2.x kernels. If you have such, please try update44, and tell me if
Hi,
Just wanted to report that update45 and Arjan's kernel-2.6.0-0.test9.1.82
on Fedora Core 1 works very well now.
Thanks a lot!
David
Michael
Hi David,
I am attempting to run Arjan's 2.6 tst9.1.87. I use Petr's update45 ,
but the scripts seems to think I either don't have kernel source, or
that the source I have does'nt match the running kernel. It does the
usual /usr/src/linux/include which is obviously wrong. WHen I give it
th correct location, it still complains.
Did you rebuild the kernel rpm andthen install it or did just use
Arjan's binaries rpms?
Cheers,
Michael
David K
> I am attempting to run Arjan's 2.6 tst9.1.87. I use Petr's update45 ,
> but the scripts seems to think I either don't have kernel source, or
> that the source I have does'nt match the running kernel. It does the
> usual /usr/src/linux/include which is obviously wrong. WHen I give it
> th correct location, it still complains.
>
> Did you rebuild the kernel rpm andthen install it or did just use
> Arjan's binaries rpms?
>
Hi,
I also had some major problems with the .87 kernel. Try the .90 kernel
instead.
If vmware-config.pl complains that "The kernel defined by this directory
of header files does not have the same address space size as your running
kernel", comment out the "return '';" statement following that message in
vmware-config.pl and you're all set.
Worked for me.
Regards
David
Michael
> On Sun, 16 Nov 2003 20:52:26 +1000, Michael wrote:
>
>
> Hi,
> I also had some major problems with the .87 kernel. Try the .90 kernel
> instead.
>
> If vmware-config.pl complains that "The kernel defined by this directory
> of header files does not have the same address space size as your running
> kernel", comment out the "return '';" statement following that message in
> vmware-config.pl and you're all set.
>
> Worked for me.
>
Ok thanks for that. I really liked the first few 2.6's Arjan came up
with. They made my system run very smoothly when using a VM, so I have
missed it since the newer ones didn't play nicely with VMware..
Cheers,
Michael