Kernel Error After VirtualBox Wakes up

2008 Nov 26 at 15:51 » Tagged as :virtualization, python,

Things go haywire with VirtualBox when the host system wakes up from sleep.

Message from [email protected] at Nov 17 15:10:33 ... kernel: Code: c0 0f 30 58 8e d8 58 8e c0 5b 41 5c 41 5d 41 5e 41 5f b8 5b f0 ff ff e9 e9 fe ff ff cc cc cc cc b8 ff ff ff ff 48 21 c7 48 31 c0 <0f> 79 fe 73 06 b8 5f f0 ff ff c3 75 05 b8 60 f0 ff ff c3 cc cc There is a detailed dump in the syslog

Nov 19 12:22:32 localhost kernel: Code: 57 f3 0f c7 34 24 73 07 b8 5e f0 ff ff eb 07 75 05 b8 5d f0 ff ff 48 83 c4 08 c3 cc cc cc cc 0f 01 c4 c3 cc cc cc cc 48 31 c0 57 <66> 0f c7 34 24 73 05 b8 5f f0 ff ff 48 83 c4 08 c3 cc cc cc cc
Nov 19 12:22:32 localhost kernel: RIP  [_end+518288498/2113624756] :vboxdrv:g_abExecMemory+0x6e9e/0x180000
Nov 19 12:22:32 localhost kernel:  RSP <ffff81000c495cf8>
Nov 19 12:22:32 localhost kernel: ---[ end trace acf3d78972eadbc4 ]---
Nov 19 12:23:58 localhost kernel: invalid opcode: 0000 [3] SMP
Nov 19 12:23:58 localhost kernel: CPU 0
Nov 19 12:23:58 localhost kernel: Modules linked in: nf_nat_ftp iptable_nat nf_nat nf_conntrack_ftp ppp_synctty ppp_async crc_ccitt ppp_generic slhc vboxdrv ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi scsi_transport_iscsi coretemp w83627ehf hwmon_vid hwmon fuse sunrpc ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack iptable_filter ip_tables ip6_tables x_tables xfs reiserfs dm_mirror dm_log dm_multipath dm_mod snd_hda_intel snd_seq_dummy i915 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep snd iTCO_wdt iTCO_vendor_support atl2 8139too drm sr_mod cdrom ppdev pcspkr i2c_algo_bit parport_pc parport skge mii soundcore i2c_i801 i2c_core sg floppy ata_generic ata_piix pata_acpi libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: kvm]
Nov 19 12:23:58 localhost kernel: Pid: 5456, comm: VirtualBox Tainted: G      D   2.6.26.5-45.fc9.x86_64 #1
Nov 19 12:23:58 localhost kernel: RIP: 0010:[_end+518288498/2113624756]  [_end+518288498/2113624756] :vboxdrv:g_abExecMemory+0x6e9e/0x180000
Nov 19 12:23:58 localhost kernel: RSP: 0018:ffff81001d055cf8  EFLAGS: 00010046
Nov 19 12:23:58 localhost kernel: RAX: 0000000000000000 RBX: 00000000fffffffe RCX: ffffc2000153c000
Nov 19 12:23:58 localhost kernel: RDX: 0000000000000007 RSI: 000000000000000d RDI: 0000000010a26000
Nov 19 12:23:58 localhost kernel: RBP: ffff81001d055d28 R08: ffff810026db7810 R09: 0000000000000000
Nov 19 12:23:58 localhost kernel: R10: 0000000000000000 R11: ffffffffa0493e30 R12: ffffc2000153c000
Nov 19 12:23:58 localhost kernel: R13: ffff810026dd2b90 R14: 00000000c0305689 R15: 0000000040ed0e50
Nov 19 12:23:58 localhost kernel: FS:  0000000040ed1950(0063) GS:ffffffff81417000(0000) knlGS:0000000000000000
Nov 19 12:23:58 localhost kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Nov 19 12:23:58 localhost kernel: CR2: 00007fb7dc586560 CR3: 000000006716e000 CR4: 00000000000026e0
Nov 19 12:23:58 localhost kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Nov 19 12:23:58 localhost kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Nov 19 12:23:58 localhost kernel: Process VirtualBox (pid: 5456, threadinfo ffff81001d054000, task ffff810027d1da80)
Nov 19 12:23:58 localhost kernel: Stack:  0000000010a26000 ffffffffa0493e6e ffff81001d055d38 ffffffffa0497ac2
Nov 19 12:23:58 localhost kernel:  0000000000000287 ffffc2000153c000 ffff81001d055d58 ffffffffa0497aeb
Nov 19 12:23:58 localhost kernel:  ffff81001d055de8 00000000fffffff9 ffff810026dd2b90 ffff810026dd2b90
Nov 19 12:23:58 localhost kernel: Call Trace:
Nov 19 12:23:58 localhost kernel:  [_end+518297890/2113624756] ? :vboxdrv:g_abExecMemory+0x934e/0x180000
Nov 19 12:23:58 localhost kernel:  [_end+518313334/2113624756] ? :vboxdrv:g_abExecMemory+0xcfa2/0x180000
Nov 19 12:23:58 localhost kernel:  [_end+518313375/2113624756] :vboxdrv:g_abExecMemory+0xcfcb/0x180000
Nov 19 12:23:58 localhost kernel:  [_end+518314060/2113624756] :vboxdrv:g_abExecMemory+0xd278/0x180000
Nov 19 12:23:58 localhost kernel:  [_end+518240346/2113624756] :vboxdrv:supdrvIOCtl+0xe73/0x12d6
Nov 19 12:23:58 localhost kernel:  [_end+518248073/2113624756] ? :vboxdrv:rtMemAlloc+0xa5/0xdd
Nov 19 12:23:58 localhost kernel:  [_end+518225179/2113624756] :vboxdrv:VBoxDrvLinuxIOCtl+0x11d/0x19c
Nov 19 12:23:58 localhost kernel:  [hrtick_set+139/252] ? hrtick_set+0x8b/0xfc
Nov 19 12:23:58 localhost kernel:  [vfs_ioctl+42/120] vfs_ioctl+0x2a/0x78
Nov 19 12:23:58 localhost kernel:  [do_vfs_ioctl+583/609] do_vfs_ioctl+0x247/0x261
Nov 19 12:23:58 localhost kernel:  [sys_ioctl+85/119] sys_ioctl+0x55/0x77
Nov 19 12:23:58 localhost kernel:  [sys_write+96/111] ? sys_write+0x60/0x6f
Nov 19 12:23:58 localhost kernel:  [system_call_after_swapgs+138/143] system_call_after_swapgs+0x8a/0x8f
Nov 19 12:23:58 localhost kernel:
Nov 19 12:23:58 localhost kernel:
Nov 19 12:23:58 localhost kernel: Code: 57 f3 0f c7 34 24 73 07 b8 5e f0 ff ff eb 07 75 05 b8 5d f0 ff ff 48 83 c4 08 c3 cc cc cc cc 0f 01 c4 c3 cc cc cc cc 48 31 c0 57 <66> 0f c7 34 24 73 05 b8 5f f0 ff ff 48 83 c4 08 c3 cc cc cc cc
Nov 19 12:23:58 localhost kernel: RIP  [_end+518288498/2113624756] :vboxdrv:g_abExecMemory+0x6e9e/0x180000
Nov 19 12:23:58 localhost kernel:  RSP <ffff81001d055cf8>
Nov 19 12:23:58 localhost kernel: ---[ end trace acf3d78972eadbc4 ]---
What causes VirtualBox to go mad is usmb - the userspace samba file system. My guest images reside on another computer (my file server). I mount the folder using usmb and then start them up with VirtualBox this way I get a huge speed advantage because the hard drive on my desktop isn't being spun into the ground. I can afford to do this because I have gigabit ethernet. When the machine goes to sleep usmb sometimes disconnects. It is acceptable for VirtualBox to gag when that happens but what is not acceptable is for VirtualBox to force me to reboot to fix the error. Of course I can continue to work on the computer doing other tasks but I cannot run another virtual machine till I reboot. Restarting the VirtualBox services does not work.

[email protected]:~$ /etc/rc.d/init.d/vboxdrv restart Stopping VirtualBox kernel module                          [FAILED] (Cannot unload module vboxdrv) The kernel absolutely refuses to unload the vboxdrv module. I tried rmmod, i tried modprobe -r, I tried fuser -v /dev/vbox to see which process might be locking it (fuser didn't say). modprobe -r ran through the night without removing the kernel. I looked through the process table with a fine tooth comb to find any process that might be even remotely associated with it no luck. The VirtualBox kernel module is hanging on grimly like a barnacle on a ships' keel. This behaviour is the same on F9 and F10