Ticket #9460 (closed defect: fixed)

Opened 9 years ago

Last modified 9 years ago

Linux guests crash with Call Trace - Intel DQ67SW mainboard

Reported by: mcw Owned by:
Component: other Version: VirtualBox 4.1.2
Keywords: Call Trace Cc:
Guest type: Linux Host type: other



I just experienced Call Traces nearly every time I wanted to boot (different) Linux(es) as guest on my Windows 7 Pro SP1 x86_64 host.

My hardware: Intel DQ67SWB3 mainboard (BIOS revision 53), Intel Core i7 2600 (non-K, non-S) CPU.

Sporadically, I could boot into the guests, but mostly they crashed, no matter wether these were 32 or 64 bit guests. Disabling I/O-APIC in the VM configuration, nor "noapic", "nolapic" etc. in the guest worked... The only solution that worked for me was: either to allocate more than 1 CPU to the guest or to disable VT-x support (which only works for 32 bit VMs).

Ubuntu 10.04 (server) x86_64 as host seemd to work fine, but I don't know if that was just a coincidence or maybe Linux is more "fault-tolerant(...)".

The "real" solution for this problem was different and simple: Updating the BIOS revision to 54 that Intel just released a few days ago ( -> MWAIT fix). Since I upgraded my BIOS, no Call Traces occured anymore...

I also attached the logs where you can see the inconsistency of the MONITOR/MWAIT flag.

Thanks a lot for the help and support of the friendly guys on IRC (especially MichalM).


broken-VBox.log Download (78.3 KB) - added by mcw 9 years ago.
broken-kernel.txt Download (17.9 KB) - added by mcw 9 years ago.
ok-VBox_1cpu.log Download (78.7 KB) - added by mcw 9 years ago.
ok-VBox_2cpus.log Download (81.5 KB) - added by mcw 9 years ago.
ok-kernel_1cpu.txt Download (18.4 KB) - added by mcw 9 years ago.

Change History

Changed 9 years ago by mcw

Changed 9 years ago by mcw

Changed 9 years ago by mcw

Changed 9 years ago by mcw

Changed 9 years ago by mcw

comment:1 Changed 9 years ago by michaln

  • Status changed from new to closed
  • Resolution set to fixed

The guest crash is always an #UD on a MONITOR instruction. Disabling VT-x or enabling guest SMP causes VirtualBox to not report the MONITOR/MWAIT capability, which works around the problem.

The problem appears to be that the CPU capabilities are not consistent across cores(!!). I don't know how Intel managed that, but the logs prove it. If VirtualBox happens to get the CPUID on a MWAIT-less core, there's no problem because the guest won't try using it. But when the guest sees the capability, it will eventually get scheduled on a core where MONITOR/MWAIT triggers #UD.

Clearly an Intel bug, probably introduced in one of the later BIOS revisions; I have an almost identical system at home with an older BIOS and no such problems.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use