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)
Change History (4)
by , 6 years ago
| Attachment: | Kernel_2018-11-01-151543.panic.txt added |
|---|
comment:1 by , 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 &
by , 6 years ago
| Attachment: | VBoxSVC.log added |
|---|
by , 6 years ago
| Attachment: | VirtualBox.xml added |
|---|


Full Kernel Panic