You are not logged in.

#1 2014-10-10 04:33:08

winslow
Member
Registered: 2014-10-04
Posts: 6

Virtualbox VMs inoperable if started after host suspends to RAM

After my machine wakes from being suspended to RAM, I find that none of my virtualbox guests function correctly. The symptoms seem to vary. The most common symptom is during boot I'll see is

tsc: Fast TSC calibration failed
BUG: soft lockup - CPU#0 stuck for 22s! [dracut-cmdline]

stuck times vary. USB devices are turned off for my machines, which was the most common cause of that symptom that I could find. Rebooting my host machine seems to resolve the issue and allows the guests to operate normally.

Today after waking from suspension, my guest machines booted normally but displayed other symptoms. Namely:

  • One guest allowed me to log in but had no network access

  • Another guest made it to the login prompt but would not prompt for a password
    after a username was entered.

Rebooting the host resolved these issues. Any logs I've checked on the guests have not revealed anything strange there either, although I'd guess I'm just not looking in the right place.

I'm not sure when exactly this started happening, as I just started utilizing suspend to RAM in the last month.

I tried downgrading Virtualbox from 4.3.16 to 4.3.14, but that did not help either.

I have a completely unfounded suspicion that this has something to do with the virtualbox kernel module, but no way to prove it. Nothing strange to me appears in the output of dmesg or journalctl before or after suspending and running virtualbox. I'm not familiar enough with Virtualbox logs to see anything strange in them.

Thank you!

Last edited by winslow (2014-10-10 06:09:57)

Offline

#2 2014-10-11 04:07:00

winslow
Member
Registered: 2014-10-04
Posts: 6

Re: Virtualbox VMs inoperable if started after host suspends to RAM

I did manage to find the following: https://forums.virtualbox.org/viewtopic … nd#p134681

I'll experiment and report back.

Offline

#3 2014-10-11 05:18:17

winslow
Member
Registered: 2014-10-04
Posts: 6

Re: Virtualbox VMs inoperable if started after host suspends to RAM

Well that link unfortunately won't help as VT-x/AMD-V must be enabled for 64bit guests.

I tried going ham and did an

rmmod --force vboxdrv
modprobe vboxdrv

That did not fix the issue, but it did produce this message in journalctl

Oct 10 22:18:47 COOLERMASTER kernel: vboxdrv: Found 4 processor cores.
Oct 10 22:18:47 COOLERMASTER kernel: vboxdrv: fAsync=1 offMin=0xf4e18fbc offMax=0xf4e18fbc
Oct 10 22:18:47 COOLERMASTER kernel: vboxdrv: TSC mode is 'asynchronous', kernel timer mode is 'normal'.
Oct 10 22:18:47 COOLERMASTER kernel: vboxdrv: Successfully loaded version 4.3.16_OSE (interface 0x001a0007).
Oct 10 22:18:54 COOLERMASTER kernel: BUG: unable to handle kernel paging request at ffffffffa02dd5f0
Oct 10 22:18:55 COOLERMASTER kernel: IP: [<ffffffff811c0004>] filp_close+0x24/0x70
Oct 10 22:18:55 COOLERMASTER kernel: PGD 1814067 PUD 1815063 PMD 232f37067 PTE 0
Oct 10 22:18:55 COOLERMASTER kernel: Oops: 0000 [#1] PREEMPT SMP 
Oct 10 22:18:55 COOLERMASTER kernel: Modules linked in: vboxdrv(O) nls_iso8859_1 nls_cp437 vfat fat fuse mousedev hid_generic usbhid joydev xpad hid ff_memless uas led_class usb_storage cfg80211 rf
Oct 10 22:18:55 COOLERMASTER kernel:  fscache ext4 crc16 mbcache jbd2 sd_mod sr_mod crc_t10dif crct10dif_common cdrom ata_generic pata_acpi atkbd libps2 ata_piix libata ehci_pci xhci_hcd ehci_hcd s
Oct 10 22:18:55 COOLERMASTER kernel: CPU: 0 PID: 3033 Comm: dns-monitor Tainted: P  R        O  3.16.4-1-ARCH #1
Oct 10 22:18:55 COOLERMASTER kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Extreme3 Gen3, BIOS P1.30 11/22/2011
Oct 10 22:18:55 COOLERMASTER kernel: task: ffff88011f683d20 ti: ffff880202330000 task.ti: ffff880202330000
Oct 10 22:18:55 COOLERMASTER kernel: RIP: 0010:[<ffffffff811c0004>]  [<ffffffff811c0004>] filp_close+0x24/0x70
Oct 10 22:18:55 COOLERMASTER kernel: RSP: 0018:ffff880202333c90  EFLAGS: 00010246
Oct 10 22:18:55 COOLERMASTER kernel: RAX: ffffffffa02dd580 RBX: ffff8802021b2c00 RCX: ffff880123843758
Oct 10 22:18:55 COOLERMASTER kernel: RDX: 0000000080000000 RSI: ffff880123843700 RDI: ffff8802021b2c00
Oct 10 22:18:55 COOLERMASTER kernel: RBP: ffff880202333ca8 R08: 0000000000000000 R09: ffffea0008418800
Oct 10 22:18:55 COOLERMASTER kernel: R10: ffffffff81250646 R11: ffffea00085b5d00 R12: 0000000000000000
Oct 10 22:18:55 COOLERMASTER kernel: R13: ffff880123843700 R14: ffff880123843710 R15: 0000000000000010
Oct 10 22:18:55 COOLERMASTER kernel: FS:  0000000000000000(0000) GS:ffff88023fa00000(0000) knlGS:0000000000000000
Oct 10 22:18:55 COOLERMASTER kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 10 22:18:55 COOLERMASTER kernel: CR2: ffffffffa02dd5f0 CR3: 0000000001811000 CR4: 00000000000407f0
Oct 10 22:18:55 COOLERMASTER kernel: Stack:
Oct 10 22:18:55 COOLERMASTER kernel:  0000000000000007 0000000000000000 ffff880123843700 ffff880202333ce8
Oct 10 22:18:55 COOLERMASTER kernel:  ffffffff811df988 000000011f683d20 ffff88011f683d20 ffff880123843700
Oct 10 22:18:55 COOLERMASTER kernel:  ffff88011f684478 ffff88020224a6e0 ffff88011f683d20 ffff880202333d10
Oct 10 22:18:55 COOLERMASTER kernel: Call Trace:
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff811df988>] put_files_struct+0x78/0xd0
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff811dfa87>] exit_files+0x47/0x50
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff81070c80>] do_exit+0x370/0xb10
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff810714a3>] do_group_exit+0x43/0xc0
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff81080e90>] get_signal_to_deliver+0x270/0x6e0
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff81014627>] do_signal+0x57/0x700
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff8120156b>] ? __fsnotify_update_child_dentry_flags.part.1+0x10b/0x120
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff812af800>] ? lockref_put_or_lock+0x60/0x80
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff811e1a6e>] ? mntput_no_expire+0x2e/0x180
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff811e1be4>] ? mntput+0x24/0x40
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff811cba3e>] ? path_put+0x1e/0x30
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff81014d38>] do_notify_resume+0x68/0xa0
Oct 10 22:18:55 COOLERMASTER kernel:  [<ffffffff815319e0>] int_signal+0x12/0x17
Oct 10 22:18:55 COOLERMASTER kernel: Code: ea ff 0f 1f 44 00 00 66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 8b 47 38 48 89 fb 48 85 c0 74 46 48 8b 47 28 45 31 e4 49 89 f5 <48> 8b 40 70 48 85 c0 74
Oct 10 22:18:55 COOLERMASTER kernel: RIP  [<ffffffff811c0004>] filp_close+0x24/0x70
Oct 10 22:18:55 COOLERMASTER kernel:  RSP <ffff880202333c90>
Oct 10 22:18:55 COOLERMASTER kernel: CR2: ffffffffa02dd5f0
Oct 10 22:18:55 COOLERMASTER kernel: ---[ end trace 3580edccd1e90cc1 ]---
Oct 10 22:18:55 COOLERMASTER kernel: Fixing recursive fault but reboot is needed!

The TSC mode mismatch might be something? More research necessary. Also no guarantee that this error isn't completely due to the forcible rmmod.

Offline

#4 2014-10-11 05:28:28

winslow
Member
Registered: 2014-10-04
Posts: 6

Re: Virtualbox VMs inoperable if started after host suspends to RAM

Oct 10 22:27:58 COOLERMASTER kernel: vboxdrv: Found 4 processor cores.
Oct 10 22:27:58 COOLERMASTER kernel: vboxdrv: fAsync=0 offMin=0x376 offMax=0x1744a
Oct 10 22:27:58 COOLERMASTER kernel: vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
Oct 10 22:27:58 COOLERMASTER kernel: vboxdrv: Successfully loaded version 4.3.16_OSE (interface 0x001a0007).

is the relevant output from journalctl during the reboot. Not sure if the fact that the TSC changed between normal reboot and resuming from suspend is meaningful.

Offline

Board footer

Powered by FluxBB