VirtualBox

Ticket #10686 (reopened defect)

Opened 22 months ago

Last modified 4 weeks ago

Kernel Panic: MONITOR/MWAIT

Reported by: DasFox Owned by:
Priority: major Component: other
Version: VirtualBox 4.1.14 Keywords:
Cc: Guest type: Linux
Host type: Linux

Description

I'm running Slackware 13.37 x86 host and guest on VirtualBox 4.1.14, this is on a Sony Vaio with a Intel Core i3, and when I try to boot the Slack guest it kernel panics and gives me this message;

kernel panic not syncing: Attempted to kill the idle task! atkbd serio0: Spurious ACK on isa0060/serio0. Some program may be trying to access hardware directly

I'm attaching a screen shot to this bug report you can also see.

I have a desktop running an AMD and the guest will boot and run just fine, it's only on my Vaio with the i3 that it won't boot, so I recompiled the kernel 3.4.3 hoping this would help with no luck.

I've also attached the VB log....

I also noticed that if I try to boot the Slackware 13.37 CD it too won't boot on the Sony and kernel panics and locks up as well.

I read there seems to be an issue here with Slack and i3/i5/i7 cpus?

I hope someone might know a fix for VB OSE 4.1.14 I can apply to get this to bootup?

THANKS

P.S. Since I'm running Slackware and I compiled the OSE version into a slackware package, this is the build script I used;

 http://slackbuilds.org/repository/13.37/system/virtualbox/

Until this gets updated, I'm not able to use 4.1.16....

Attachments

VBox.log Download (84.4 KB) - added by DasFox 22 months ago.
kernel_panic.jpg Download (139.6 KB) - added by DasFox 22 months ago.
pare_cpuinfo.txt Download (558 bytes) - added by parem 17 months ago.
cat proc/cpuinfo
badarch.tiff Download (54.7 KB) - added by parem 17 months ago.
Screenshot of crash pare
pare_VBox.log Download (51.3 KB) - added by parem 17 months ago.
pare vbox log
VBox.2.log Download (76.4 KB) - added by jeffL35 7 weeks ago.
jeffL35_vbox.log
VBox.3.log Download (89.5 KB) - added by wolfish17 5 weeks ago.
vbox.log showing 4.3.8 fail with guest gentoo on mac osx host when 4.3.6 worked.

Change History

Changed 22 months ago by DasFox

Changed 22 months ago by DasFox

comment:1 Changed 22 months ago by DasFox

Hi,

Has anyone had a chance to look this over?

I really need to get the Slackware guest working again for my work...

I hope I can please get this fixed soon?

THANKS

comment:2 Changed 22 months ago by DasFox

I just installed today 4.1.18 and the same problem...

comment:3 Changed 21 months ago by DasFox

I figured out the problem the Intel Virtualization was disabled in the bios, something I overlooked.

Granted I know there are times when people don't reply to bug reports, but this is not often the case, I'm a IT Tech and Unix geek, I've been into computing a little over 20 years.

Had this not been an error on my part, it should still at least be looked at like I'm trying to report legit bug reports and HELP! So the least someone can do to show some caring around here is to make a post/reply to let people know someone is looking into this.

Having this bug report go by 8 weeks without a single word makes a person feel like no one cares...

So next time in the future when I find a real bug I might be less likely to file a report when I need help and no one has the consideration to respond... :(

comment:4 Changed 20 months ago by frank

I don't think the spurious ack message has anything to do with the kernel panic. To fix your problem we would need to reproduce it. And enabling VT-x will make the error go away but this is not the real problem. Even without activating VT-x the guest kernel should not crash.

Regarding your complaint about the long response delay: I can only repeat that there is no guarantee for any response time to bug reports for non-paying users. If you open a bug report then this does not only means that you 'ask' for help and for fixing a bug (not demand!) and this also means that other users might have an idea about your problem as well. If you don't get a response within a few days this can have a lot of reasons but the most likely reason is that your problem is nothing we were aware of before and a quick look didn't ring any bell.

comment:5 Changed 17 months ago by frank

  • Summary changed from Kernel Panic When Booting - atkbd serio0: Spurious ACK on isa0060/serio0 to Kernel Panic: MONITOR/MWAIT

I think I know the reason for that kernel panic. The guest crashes when it tries to execute the MWAIT instruction. Most likely the feature flags of your host CPU differs in MONITOR/MWAIT: One or more cores have this feature enabled, other cores don't. The output of /proc/cpuinfo would show that problem. In that case, VBox would pass that bit to the guest when started on a core which has this problem. When executing the guest code on a core without that feature, the guest will panic.

comment:6 Changed 17 months ago by frank

So can you provide the output of

cat /proc/cpuinfo

of that host?

comment:7 Changed 17 months ago by Weikai

I have the exactly same problem and the following is my cpu information and host syslog

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Xeon(R) CPU E31235 @ 3.20GHz
stepping        : 7
microcode       : 0x25
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6386.23
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Xeon(R) CPU E31235 @ 3.20GHz
stepping        : 7
microcode       : 0x25
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 1
cpu cores       : 4
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6385.45
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Xeon(R) CPU E31235 @ 3.20GHz
stepping        : 7
microcode       : 0x25
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 2
cpu cores       : 4
apicid          : 4
initial apicid  : 4
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6385.45
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Xeon(R) CPU E31235 @ 3.20GHz
stepping        : 7
microcode       : 0x25
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 6
initial apicid  : 6
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6385.44
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 4
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Xeon(R) CPU E31235 @ 3.20GHz
stepping        : 7
microcode       : 0x25
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6385.44
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 5
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Xeon(R) CPU E31235 @ 3.20GHz
stepping        : 7
microcode       : 0x25
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 1
cpu cores       : 4
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6385.44
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 6
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Xeon(R) CPU E31235 @ 3.20GHz
stepping        : 7
microcode       : 0x25
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 2
cpu cores       : 4
apicid          : 5
initial apicid  : 5
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6385.44
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Xeon(R) CPU E31235 @ 3.20GHz
stepping        : 7
microcode       : 0x25
cpu MHz         : 3201.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 3
cpu cores       : 4
apicid          : 7
initial apicid  : 7
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6385.44
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:
Last edited 17 months ago by frank (previous) (diff)

comment:8 follow-up: ↓ 12 Changed 17 months ago by frank

Weikai, thanks for the information. Your machine shows the expected features: CPU0 is missing the MONITOR feature flag while all other CPUs have it. I would like to let you test a test build, which VirtualBox package (which Linux distribution and 32-bit or 64-bit) do you need?

Changed 17 months ago by parem

cat proc/cpuinfo

Changed 17 months ago by parem

Screenshot of crash pare

Changed 17 months ago by parem

pare vbox log

comment:9 Changed 17 months ago by parem

I appear to be having a similar if not the same problem. I too am seeing the strings "Spurious ACK on isa0060/serio0" though I note that this may not be the issue as to initial statements.

I only get this crash when I perform a shutdown or restart.

I can make this problem not occur by not loading the vboxguest, vboxsf or vboxvideo kernel modules. If I load vboxsf at boot alone, vboxguest seems to load as well even though I didn't explicitly load that module. Regardless, if I do not load those three vbox kernel modules there is no crash.

If I understand correctly, I appear to have VT-x already active when this happens.

I'm running VirtualBox VM 4.2.4 r81684 on darwin.x86 (OS X 10.6.8).

I've attached screen shot of crash, cat /proc/cpuinfo, vBox.log after crash.

comment:10 follow-up: ↓ 11 Changed 16 months ago by frank

parem, your screenshot shows that your problem is different. It shows a crash inside the vboxsf guest kernel module.

Please could you open a separate ticket and attach the same information there? Also, please attach there the vboxsf.ko kernel module. And please do also add the information which Linux kernel version are you running as guest. Thank you!

comment:11 in reply to: ↑ 10 Changed 16 months ago by parem

Replying to frank:

See defect 11291, https://www.virtualbox.org/ticket/11291

parem, your screenshot shows that your problem is different. It shows a crash inside the vboxsf guest kernel module.

Please could you open a separate ticket and attach the same information there? Also, please attach there the vboxsf.ko kernel module. And please do also add the information which Linux kernel version are you running as guest. Thank you!

comment:12 in reply to: ↑ 8 Changed 16 months ago by Weikai

I'm using the latest Debian wheezy 64bit.

root@cloud:/proc# uname -a Linux cloud 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux

Thank you for the help.

Replying to frank:

Weikai, thanks for the information. Your machine shows the expected features: CPU0 is missing the MONITOR feature flag while all other CPUs have it. I would like to let you test a test build, which VirtualBox package (which Linux distribution and 32-bit or 64-bit) do you need?

comment:13 follow-up: ↓ 14 Changed 16 months ago by frank

Weikai, thanks for the information. In the meantime, VBox 4.2.6 is released and it contains a fix which hopefully fixes your problem. Does it work for you?

comment:14 in reply to: ↑ 13 Changed 16 months ago by Weikai

Replying to frank: Thank you frank. The new version did fix my problem.

comment:15 follow-up: ↓ 16 Changed 16 months ago by frank

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

Thanks for the feedback!

comment:16 in reply to: ↑ 15 Changed 7 weeks ago by jeffL35

  • Status changed from closed to reopened
  • Resolution fixed deleted

THe problem is back in version 4.3.8. It started right after I updated virtualbox. It was just fine with version 4.3.6, before the update. I have an AMD 2 core cpu.

Last edited 7 weeks ago by jeffL35 (previous) (diff)

comment:17 Changed 7 weeks ago by frank

jeffL35, please attach a VBox.log file of such a VM session.

Changed 7 weeks ago by jeffL35

jeffL35_vbox.log

comment:18 Changed 7 weeks ago by jeffL35

It might not be a MONITOR/MWAIT problem.

comment:19 Changed 5 weeks ago by wolfish17

I have the same problem. My Gentoo Linux on OSX 10.9.2 host worked fine on 4.3.6 but failed as indicated above ("Kernel panic -- not syncing" etc) when upgraded to 4.3.8.

comment:20 Changed 5 weeks ago by frank

wolfish17, VBox.log please...

comment:21 Changed 5 weeks ago by frank

jeffL35, your problem should be already fixed in our repository. Here is a 4.3.9 test build, please could you confirm that this build works for you? Thank you!

Changed 5 weeks ago by wolfish17

vbox.log showing 4.3.8 fail with guest gentoo on mac osx host when 4.3.6 worked.

comment:22 follow-up: ↓ 24 Changed 5 weeks ago by frank

wolfish17, your problem is most also likely fixed. Could you confirm that this build fixes your problem?

comment:23 Changed 4 weeks ago by capouch

Is there a Linux (generic) instance of the 4.3.9 test build? I have had the problem, too, and would love to get it behind me.

comment:24 in reply to: ↑ 22 Changed 4 weeks ago by wolfish17

My problem is fixed by 4.3.9. Thank you very much. Sorry for my delay in responding.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use