VirtualBox

Opened 6 years ago

Last modified 6 years ago

#18097 new defect

Repeatable Kernel Panic OSX Host 10.13.6, 5.2.18/5.2.20

Reported by: Scott Corscadden Owned by:
Component: other Version: VirtualBox 5.2.18
Keywords: kernel panic Cc:
Guest type: Linux Host type: Mac OS X

Description

Hi there. I've been contributing to a forum topic about this here: https://forums.virtualbox.org/viewtopic.php?f=8&t=89890&sid=71ba74a8550785a1228b2d0ccdcefa74&p=432426#p432426

I have a Mac Mini (10.13.6, 16GB RAM) which is having regular kernel panics while running three Ubuntu VMs, particularly when under load. The three instances are Ubuntu 16.04 and serve as a three-node Graylog cluster (one master, two additional nodes). Perhaps complicating matters is that the .vdi's being written to are not on the local disk; rather they are saved to a Pegasus R2 RAID-5 array connected over (Apple standard) Thunderbolt cable. This allows them to be 2TB each with battery-backed writes, or believe me I'd be keeping them on the boot disk.

I've tried, to no avail:

  • Moving to 5.2.20
  • Wild ass guess that the repeated appearance of com.apple.msdosfs as a last-loaded/uloaded kernel extension was somehow the problem, boot into recovery to disable SIP and move aside that kext (when this didn't work, put it back in place again).
  • Altering the paravirtualization settings on the Ubuntu guests (Default, None, KVM) - currently sitting at the recommended KVM option
  • Finally, added the "keepsyms=1" nvram parameter to at least get the backtrace symbolicated.

I'd be *beyond* happy to take any wild suggestions for additional logging to help diagnose this in any way. The full panic is attached, but this is the top relevant section I believe:

Anonymous UUID:       8C247A86-017F-C949-405A-1CFF90AF12B3

Thu Nov  1 15:15:43 2018

*** Panic Report ***
panic(cpu 0 caller 0xffffff8006f8776f): Kernel trap at 0xffffff80072d36b0, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x0000000100000008, CR3: 0x00000003a8a860ea, CR4: 0x00000000001627e0
RAX: 0xffffff8025937610, RBX: 0x0000000100000000, RCX: 0x0000000009000000, RDX: 0xffffff80076a5128
RSP: 0xffffff91f69dbea0, RBP: 0xffffff91f69dbef0, RSI: 0x0000000000000002, RDI: 0x0000000000000000
R8:  0x0000000000000000, R9:  0x0000000000000400, R10: 0x0000000000000061, R11: 0xffffff91f6b07770
R12: 0xffffff91f69dbea0, R13: 0x0000000000000000, R14: 0xffffff802b6025f0, R15: 0xffffff800782b8d0
RFL: 0x0000000000010206, RIP: 0xffffff80072d36b0, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x0000000100000008, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 1

Backtrace (CPU 0), Frame : Return Address
0xffffff91f69db970 : 0xffffff8006e6c1c6 mach_kernel : _handle_debugger_trap + 0x4c6
0xffffff91f69db9c0 : 0xffffff8006f95274 mach_kernel : _kdp_i386_trap + 0x114
0xffffff91f69dba00 : 0xffffff8006f87544 mach_kernel : _kernel_trap + 0x4e4
0xffffff91f69dba70 : 0xffffff8006e1e1e0 mach_kernel : _return_from_trap + 0xe0
0xffffff91f69dba90 : 0xffffff8006e6bc3c mach_kernel : _panic_trap_to_debugger + 0x21c
0xffffff91f69dbbc0 : 0xffffff8006e6b9fc mach_kernel : _panic + 0x5c
0xffffff91f69dbc20 : 0xffffff8006f8776f mach_kernel : _kernel_trap + 0x70f
0xffffff91f69dbd90 : 0xffffff8006e1e1e0 mach_kernel : _return_from_trap + 0xe0
0xffffff91f69dbdb0 : 0xffffff80072d36b0 mach_kernel : _audit_mac_free + 0xa0
0xffffff91f69dbef0 : 0xffffff80072c5a65 mach_kernel : _audit_free + 0x115
0xffffff91f69dbf10 : 0xffffff80072c6676 mach_kernel : _audit_syscall_exit + 0x46
0xffffff91f69dbf40 : 0xffffff8007403987 mach_kernel : _unix_syscall64 + 0x287
0xffffff91f69dbfa0 : 0xffffff8006e1e9c6 mach_kernel : _hndl_unix_scall64 + 0x16

BSD process name corresponding to current thread: VBoxHeadless
Boot args: -v keepsyms=1

Mac OS version:
17G65

Kernel version:
Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64
Kernel UUID: 1AE5ACFD-3B6F-3D74-AD52-31F1430DBC6F
Kernel slide:     0x0000000006c00000
Kernel text base: 0xffffff8006e00000
__HIB  text base: 0xffffff8006d00000
System model name: Macmini7,1 (Mac-35C5E08120C7EEAF)

System uptime in nanoseconds: 2300159388101
last loaded kext at 246145680169: com.apple.filesystems.msdosfs	1.10 (addr 0xffffff7f8a1c3000, size 69632)
last unloaded kext at 306907560558: com.apple.filesystems.msdosfs	1.10 (addr 0xffffff7f8a1c3000, size 69632)
loaded kexts:
org.virtualbox.kext.VBoxNetAdp	5.2.18
org.virtualbox.kext.VBoxNetFlt	5.2.18
org.virtualbox.kext.VBoxUSB	5.2.18
org.virtualbox.kext.VBoxDrv	5.2.18
com.promise.driver.stex	6.2.9
com.apple.iokit.SCSITaskUserClient	404.30.2
<SNIP>

Best regards, and much respect: VirtualBox is a wonderful technology. ./scc

Attachments (3)

Kernel_2018-11-01-151543.panic.txt (7.8 KB ) - added by Scott Corscadden 6 years ago.
Full Kernel Panic
VBoxSVC.log (2.1 KB ) - added by Scott Corscadden 6 years ago.
VirtualBox.xml (2.3 KB ) - added by Scott Corscadden 6 years ago.

Download all attachments as: .zip

Change History (4)

by Scott Corscadden, 6 years ago

Full Kernel Panic

comment:1 by Scott Corscadden, 6 years ago

Things I forgot to mention:

  • I have run the "Apple Diagnostics" test on this Mac Mini as well, twice (trying each thunderbolt port for the monitor connection). It reported the success code both times (checking RAM seemed to be a common suggestion with page fault traps).
  • I run the VMs themselves headless (the host is headless - no monitor, keyboard or mouse), as an example: nohup VBoxHeadless -s graylog-master -v off &
  • I am giving a LOT of RAM to each of the VMs (elasticsearch/graylog needs a ton of RAM) - 5GB to the master node, and 3.5GB to the other two nodes. I do see this line in the VBoxSVC.log though, so hoped I was within the limit: 00:00:00.662189 Host RAM: 16384MB (16.0GB) total, 14160MB (13.8GB) available.
  • Attached the VBoxSVC.log, VirtualBox.xml
Last edited 6 years ago by Scott Corscadden (previous) (diff)

by Scott Corscadden, 6 years ago

Attachment: VBoxSVC.log added

by Scott Corscadden, 6 years ago

Attachment: VirtualBox.xml added
Note: See TracTickets for help on using tickets.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette