VMWare on Linux hangs for 5 minutes

[tardich]

Hi,

I'm on Mandriva Loinux 2007, running VMWareWorkstation 5 (latest release). My VMWare installation is running WinXP Pro ServicePack 2, and, when operating Explorer (or Firefox, I just tried), VMWare hangs my whole machine for up to 5 minutes! I still can move my mouse (the pointer could show... or not), my Linux panels (which are normally hidden) will show if I pass over them, but I won't be able to click, nor change to any other application.

When VMWare finally release the machine, everything works normally. This could even happen again in my Internet session.

I'm talking of Explorer or Firefox operation, because it can happen on the browser bootup, and it can happen during the Internet session. I even already saw it at the Internet session shut down.

This is annoying at the point of making VMWare completely useless for Internet browsing.

Christian Tardif

[jsa]

hpet=disable didn't solve the problem for me either.

But, as I mentioned above, yours is a different problem all together I think. Otherwise your freezes would be exactly 5 minutes, and there would be no

significant IO load at the time, unless you happened to have a compile

running or something.

[jlindgren33]

my freezes are[/i] 5 min. i could deal with 30 second hiccups every now and then, but a 5 min lockup is another story.

[hamelg]

Hello,

For some weeks, random lockups happen on my virtual machine. Only the guest OS lockups, the host OS remains fully functional. The lockup is definitive, not for 5 minutes, I must reset the VM.

Here is my config :

Host OS : Linux 2.6.18.1 (vanilla kernel)

Vmware workstation 5.5.2 build-29772

Hardware : IBM Thinkcenter S51, CPU P4 HT 3Ghz

Guest OS : Windows 2000-SP4

The "youtube" test seems to work systematically. Also, lockup mostly happens when I open a windows session, at login time.

hpet=disable has no effect.

Random lockups happen since I have made the following change on my system :

. Disabled HyperThreading in bios

. Disabled SMP support in my kernel

I have done that because I suffered a xorg video driver bug which restarted randomly my xserver.

There is nothing in the virtual machine logfile.

Here is the trace asked when the guest lockups :

$ cat /proc/interrupts ; sleep 10 ; cat /proc/interrupts

CPU0

0: 82681226 XT-PIC timer

1: 22688 XT-PIC i8042

2: 0 XT-PIC cascade

5: 1241492 XT-PIC uhci_hcd:usb5, eth0, i915@pci:0000:00:02.0

8: 0 XT-PIC rtc

9: 112485 XT-PIC acpi, libata, uhci_hcd:usb3

10: 150926 XT-PIC uhci_hcd:usb4

11: 3885609 XT-PIC ehci_hcd:usb1, Intel ICH6, uhci_hcd:usb2

14: 37 XT-PIC ide0

NMI: 0

ERR: 13

CPU0

0: 82691240 XT-PIC timer

1: 22689 XT-PIC i8042

2: 0 XT-PIC cascade

5: 1241619 XT-PIC uhci_hcd:usb5, eth0, i915@pci:0000:00:02.0

8: 0 XT-PIC rtc

9: 112492 XT-PIC acpi, libata, uhci_hcd:usb3

10: 150926 XT-PIC uhci_hcd:usb4

11: 3886078 XT-PIC ehci_hcd:usb1, Intel ICH6, uhci_hcd:usb2

14: 37 XT-PIC ide0

NMI: 0

ERR: 13

$ dmesg | tail -50

bridge-eth0: up

bridge-eth0: already up

bridge-eth0: attached

process `snmpd' is using obsolete setsockopt SO_BSDCOMPAT

Real Time Clock Driver v1.12ac

i2c_adapter i2c-0: Unrecognized version/stepping 0x68 Defaulting to LM85.

\[drm] Initialized drm 1.0.1 20051102

ACPI: PCI Interrupt 0000:00:02.0[A] -> Link \[LNKA] -> GSI 5 (level, low) -> IRQ

5

\[drm] Initialized i915 1.5.0 20060119 on minor 0

/dev/vmnet: open called by PID 1396 (vmware-vmx)

device eth0 entered promiscuous mode

bridge-eth0: enabled promiscuous mode

/dev/vmnet: port on hub 0 successfully opened

/dev/vmmon\[1404]: host clock rate change request 0 -> 19

/dev/vmmon\[1404]: host clock rate change request 19 -> 27

/dev/vmmon\[1404]: host clock rate change request 27 -> 100

device eth0 left promiscuous mode

bridge-eth0: disabled promiscuous mode

/dev/vmnet: open called by PID 1404 (vmware-vmx)

device eth0 entered promiscuous mode

bridge-eth0: enabled promiscuous mode

/dev/vmnet: port on hub 0 successfully opened

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 100

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 100

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 112

/dev/vmmon\[1404]: host clock rate change request 112 -> 100

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 112

/dev/vmmon\[1404]: host clock rate change request 112 -> 100

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 100

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 112

/dev/vmmon\[1404]: host clock rate change request 112 -> 100

spurious 8259A interrupt: IRQ7.

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 100

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 100

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 997

/dev/vmmon\[1404]: host clock rate change request 997 -> 100

/dev/vmmon\[1404]: host clock rate change request 100 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 997

/dev/vmmon\[1404]: host clock rate change request 997 -> 0

/dev/vmmon\[1404]: host clock rate change request 0 -> 100

/dev/vmmon\[1404]: host clock rate change request 100 -> 997

[jsa]

For some weeks, random lockups happen on my virtual machine. Only the

guest OS lockups, the host OS remains fully functional. The lockup is definitive,

not for 5 minutes, I must reset the VM.

I've had those as well, but they are NOT THE SUBJECT of this thread.

Under Vista, I get these long lockups when I have the check box for automatically resizing the guest checked. The Vmware tools can't

resize the guest properly (in Vista), but it tries really hard for a long time.

So check if your setting for automatically resizing guests without

the proper vmware tools installed, or just uncheck it all together.

[hamelg]

I've had those as well, but they are NOT THE SUBJECT

of this thread.

I posted in this thread because my problem looks like closely to the symptom ( "youtube" test, issue related to the linux kernel ...).

So check if your setting for automatically resizing

guests without

the proper vmware tools installed, or just uncheck it

I don't use vista, my vmware tools are cleanly installed and I never use guest in full screen mode.

[petr]

Bootdata ok (command line is root=/dev/sda2 vga=0x314 resume=/dev/sda1 splash=silent hpet=disable)

...

Setting APIC routing to physical flat

ACPI: HPET id: 0x8086a201 base: 0xfed00000

...

hpet0: at MMIO 0xfed00000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 0

hpet0: 3 64-bit timers, 14318180 Hz

Something is wrong with your kernel, it still insists on using HPET, so no surprise that you still observe hangs.

[jakewilliams]

I have all the same issues, Dell Latitude D620 running openSUSE 10.2 x86-64, random 5-minute long lockups.

I am running kernel 2.6.18.8-0.1-default and I also have hpet enabled according to my dmesg output, even though I have hpet=disable in my kernel command line. The dmesg output looks exactly like jsa's.

I don't know if anyone has mentioned it yet, but I had this laptop in runlevel 3 as a test and I was still getting the lockups, so I don't think it has anything to do with the xserver.

Thanks,

Jake

[jlindgren33]

is your cpu a core2duo?

[jakewilliams]

Yes, Core 2 Duo.

[AVonGauss]

Any update on internal testing using the in-house Latitude D620?

[jsa]

How are you running workstation in run level 3?

Or are you running vmware-server?

On a related note:

I note that hpet lines Petr posted only show hpet setting up 3

64bit timers, and I wonder if my freeze would be several years

if those were being used.....

I'm rebooting now to compare with hpet re-enabled to see if

there are any differences in the hpet lines in dmesg and if not

I'll open a bugzilla report with novell for ignoring hept=disable.

[jakewilliams]

SORRY, yes I forgot to mention that I am running Server, not Workstation

Jake

[Neilly]

I also was experiencing the X input freeze problem. My rig is similar to jsa's : Intel Core 2 Duo 6400 at 2.13GHz, OpenSuse 10.2, kernel 2.6.18.8-0.1-bigsmp, VMWare Workstation 5.5.3. The freeze would only occur when a VM (running Windows XP sp2) had focus. Also, fwiw, I have an NVidia 7600GS driving two LCD monitor's using the nvidia driver v97.55, and I do not have XGL or AIGLX enabled, nor Compiz/Beryl.

I have disabled hpet in the bios - kernel parameters do not seem to be standardized across all distro's/bootloaders - and have not had a lockup since.

Cheers,

Ron

[jsa]

>I have disabled hpet in the bios - kernel parameters

You have hpet in the bios? What's it called? I've been looking for that in the Dell bios and can't find any such thing. What name did they use in your bios?

[Neilly]

It is called HPET. I am running an Intel DQ965GF mobo and the setting is found in the 'Advanced' section. HTH, but I'm guessing not...

[dugan]

\[quote]Yep. Take a look at IRQ 8 in your samples - it did not increment while you were dumping data from /proc/interrupts, and only started working after 5 minutes (after 32bit counter wrapped around). There is no other fix than (1) booting with hpet=disable (both disable and disabled should work, code just test first 7 characters only), or (2) build your kernel without HPET support, or (3) disable HPET in the BIOS.[/quote]

Yes, a mod to grub;s menu.lst to add the kernel option for the older kernel allowed this to work for me.

\[quote]There is nothing else we can do - on kernels after 2.6.21 we can try to use kernel's NOHZ infrastructure to provide precise timming for virtual machines, but if you have traditional HZ based kernel you need working /dev/rtc - and rtc emulation over HPET is not working one. I promise to dig up sample code...[/quote]

Cool Deal.

I wanted to update here:

Ubuntu has 7.04 beta available (supposed to be out of beta next month) and it includes a pre-packaged kernel (2.6.20 series, their subver "-14").

I upgraded from 6.10 to 7.04beta, and set this 2.6.20-14 (ubuntu packaged kernel) to be used instead of the 2.6.20.4 that I rolled, and this kernel package does not need to hpet=disable as a kernel arg.

Only providing a followup in case it helps someone else out there.

Thanks for your help Petr.

Now I need to buy a second license to cover this laptop.

[dugan]

Sorry to self-reply, but I didn't see an edit.

both the self-rolled 2.6.20.4 and the 2.6.20-14 (Ubuntu packaged kernel with 7.10 beta) worked for me without hpet=disable.

[waggis]

Hi All,

I have exactly the same proiblem using Vmware server 1.0.0,1.0.1 or 1.0.2 on Open suse 10.2 (as 10.1).

I'm working with a laptop Dell D820, 2 GB RAM, Intel centrino Duo.

Eric

[jsa]

Dugan:

After your next reboot, can you run:

dmesg |grep -i "hpet"

and post the results? I'm interested in knowing if they Fixed hpet or removed hpet from the kernel, in 2.6.20.

If either is the case, then we can assume that Petr is on the right track here.

(which leaves only the problem of determining why ONLY vmware is sensitive

to the hpet problem).

If it is still in the kernel, and unchanged, then we will know we have to keep

searching for the source of the X freeze.

[linuxcruiser]

Just as a confirmation, disabling hpet worked like a charm.

Before doing so, all of my guest operating system's running Windows XP SP2 were freezing up for 5 minutes at a time. The guest clock's would then be delayed 5 minutes until manually adjusted.

Interestingly, the symptoms did not affect Windows Server 2003 R2 guest installations at all, with the expception of Windows Server 2003 R2 x64 during the installation process.

To work around the problem I appended the kernel boot variables in /boot/grub/menu.lst with "hpet=disable". After a reboot, the problem has not reappeared.

Thanks for the info.

Host OS: Ubuntu 6.10 (Server)

Kernel Package: 2.6.17-11-server

Server Model: HP DL360 G5

Processors: 2x Intel Xeon Quad Core (E5345) @ 2.33Ghz

Memory: 16GB RAM