Got 2 crashes almost simultaneously: "VMware Workstation internal monitor error" and "Lock rank violation"

[tuhyk]

Hello,

I'm running VMware Workstation 6.5.1 (build 126130), the latest available to date (it should be "production" version, but in the vmware.log is a string "option=BETA" - ) on Windows XP Pro SP3, 32-bit as a host. The errors (see subj.) happened during guest startup (guest: Windows XP Pro, SP2, 32-bit).

As I have experienced crashes within the guest (usually STOP Blue Screens), or lockups (see below*) , I have turned on debug to see what's happening. As I have rather frequent problems of this sort on my (newish) machine, I suspect that maybe VMware has some problem accomodating newer Intel motherboards (outside VMware Workstation I have never experienced any problem for many months whatsoever, so I am assuming HW is OK and running as designed). For reference, I have attached vmware.log. I have dutifuly created vmsupport zip file also, only to find out that my support eligibility has run out. Tough luck...

"VMware Workstation internal monitor error" I got a few times, "Lock rank violation" only once after the "VM. W. internal monitor error".

As I have voiced possibility of HW compatibility (this is supported by some IO APIC related messages in vmware logs), here is my setup (or at least what appeares to me as important part of it);

Intel DP35DP (BIOS DPP3510J.86A.0507.2008.1202.0024)

Intel Core 2 Duo E8200 @ 2.66GHz

4GB physical RAM (OS sees 3.25GB)

HDDs are SATA drives configured as IDE/PATA via BIOS option

BIOS settings:

Intel VT is turned ON in BIOS (verified)

XD (AKA execution disable bit) is turned ON in BIOS (verified)

When those crashes occured, also Enhanced Intel Speedstep was turned ON (verified)

I am running VMware Workstation under Power User rights (not as an Administrator).

Could someone confirm that this is an error in VMware Workstation (and preferably that they are working on it ), or point me to some solution? Currently, the VMware Workstation is simply unusable for me (haven't tried downgrade to 6.0.x yet, though)...

Should someone from VMware be interested, I have core dumps for both crashes also ready (ca 180MB total).

-

---

*) Messages I have often found in logs when guest seemed to be non-responding (these are added for reference, I will make separate post about lockups/stalls):

GuestRpcSendTimedOut: message to toolbox timed out

GuestRpcSendTimedOut: message to toolbox-dnd timed out.

VMSAMPLE32: cs=0x2000, eip=0xc3b (lots of these)

RDMSR: unknown MSR[0x119] (read as zero): rip=0x17cc count=25

WRMSR: unknown MSR[0x119]:=2 (sinking): rip=0x17d9 count=26 (lots of similar)

I have curiously found also VMSAMPLE64 in some other vmware.log for other machine on the same 32-bit host (puzzling, for me at least, as I don't know what it is)

[ksc]

The VMSAMPLE messages are benign - those are just a heartbeat that always gets traced out in debug-mode, a way to see if the virtual machine is making progress.

The second error (lock rank violation) came about from the first error - we crashed holding a lock, then error out trying to clean up. It can be ignored.

The original error is this:

Jan 23 01:18:22.687: vcpu-0| MONITOR PANIC: vcpu-0:ASSERT vmcore/vmm/intr/ioapic.c:483

I'll look around and see if we have seen this internally.

[ksc]

No internal reports of this one.

Examining the source code, the bug occurs when an emulated IOAPIC is reprogrammed such that two one CPU's settings are conflicting with each other - which is handled, but this error says the handler didn't catch it. This is all emulation, we barely touch the real hardware - so I don't think it's anything specific to your CPU / motherboard.

That said, if you are getting other random failures, I'd start to suspect a memory error or such.

[tuhyk]

Thanks a lot for research.

As I have mentioned in my first post, I had multiple problems with my VMware Workstation; the other biggie apart from guest crashes were guest stalls/freezes. I have checked memory on the system as per your suggestion (Memtest86+ v2.11) with zero errors found (single run only, but for such frequent problems, should they be induced by memory error, such an error would have been found quite early through the test).

But all things started to work (no errors, no stalls, no crashes), albeit subjectively somewhat slower, only after I turned Intel VT off. Hence my conclusion, that either there is something botched in my CPU/mobo/BIOS setup (or more precisely in Intel's firmware), or there is a bug in VMware's Intel VT implementation...