Opened 13 years ago
Closed 13 years ago
#9460 closed defect (fixed)
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 |
Description
Hello,
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 (http://downloadmirror.intel.com/20333/eng/SW_0054_ReleaseNotes.pdf -> 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).
Attachments (5)
Change History (6)
by , 13 years ago
| Attachment: | broken-VBox.log added |
|---|
by , 13 years ago
| Attachment: | broken-kernel.txt added |
|---|
by , 13 years ago
| Attachment: | ok-VBox_1cpu.log added |
|---|
by , 13 years ago
| Attachment: | ok-VBox_2cpus.log added |
|---|
by , 13 years ago
| Attachment: | ok-kernel_1cpu.txt added |
|---|
comment:1 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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.