kernel panics on latest versions of VirtualBox

[mauricev]

Mac Pro running 10.14.5 and VirtualBox 6.0.10 and just saw a kernel panic with a Linux VM running. I believe this has happened several times now when a VBox VM has been running. This line looks suspicious

Code: Select all

      Kernel Extensions in backtrace:
         org.virtualbox.kext.VBoxDrv(6.0.10)[FD628542-B180-34C4-AF29-CE70F4F9F587]@0xffffff7f9e785000->0xffffff7f9e874fff

Attachments included.

[TheKingOfKongs]

I am having the same issue. OSX 10.14.6 and Virtual Box 6.0.10. Constant kernel panics when running Windows Guests. Here is the kext output:

Code: Select all

Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
  111    3 0xffffff7f83eb2000 0xf0000    0xf0000    org.virtualbox.kext.VBoxDrv (6.0.10) FD628542-B180-34C4-AF29-CE70F4F9F587 <8 6 5 3 1>
  175    0 0xffffff7f849bf000 0x6000     0x6000     com.valvesoftware.SteamInput (4357.73.42) 17B6ECD0-A50A-3D6A-B350-9C70805EE129 <44 6 5 3>
  176    0 0xffffff7f849c5000 0xb000     0xb000     com.displaylink.driver.DisplayLinkDriver (5.1 (32)) 8678B312-80ED-392A-AFF2-DCCF562FB604 <119 13 6 5 3>
  186    0 0xffffff7f85acc000 0x8000     0x8000     org.virtualbox.kext.VBoxUSB (6.0.10) 8626D518-71CF-3493-A7BC-5A5F24561525 <185 111 56 8 6 5 3 1>
  187    0 0xffffff7f85ad4000 0x5000     0x5000     org.virtualbox.kext.VBoxNetFlt (6.0.10) E9EF0869-64B9-3C71-9133-4082F8227256 <111 8 6 5 3 1>
  188    0 0xffffff7f85ad9000 0x6000     0x6000     org.virtualbox.kext.VBoxNetAdp (6.0.10) 9F140CBD-4713-3F03-AAD1-FBBC2B6C49A1 <111 6 5 1>
  189    0 0xffffff7f85adf000 0x7000     0x7000     com.sophos.nke.swi (9.7.15) 727E1482-79C1-3F33-A3C4-F147A406D5CA <5 1>
  190    0 0xffffff7f85ae6000 0x8000     0x8000     com.sophos.kext.oas (9.7.4) FE151087-F3B0-3F51-BD15-3313B8BCDDAB <6 5 2 1>
  192    0 0xffffff7f85afd000 0x15000    0x15000    com.google.drivefs.filesystems.dfsfuse (33.0.15) E5E211F7-709C-37A9-A894-5A389DF2C60D <8 6 5 3 1>
  193    0 0xffffff7f85b12000 0x16000    0x16000    com.box.filesystems.osxfuse (303.6.4) EC6C2373-B225-372E-B5AF-DD46E748A1AE <8 6 5 3 1>

[socratis]

Usually when there's a kernel panic there is some conflict with another 3rd party kernel. Start uninstalling 3rd party software one-by-one and see if you can pinpoint the problem.

@mauricev
"net.lundman.spl" and "net.lundman.zfs" seem to return a lot of problems under OSX.

@TheKingOfKongs,
the "com.valvesoftware.SteamInput" seems suspect. Also, highly suspect is the "com.box.filesystems.osxfuse" one. It might have a conflict with the official OSXFUSE, which is distributed with VirtualBox and should be labelled as "com.github.osxfuse".

[mauricev]

@mauricev"net.lundman.spl" and "net.lundman.zfs" seem to return a lot of problems under OSX.

I've been using it on two Mac Pros for years without incident.

This is a recent change. It's looking like this is a recently introduced bug in VirtualBox.

[mauricev]

There seems to be a similar report here
viewtopic.php?f=8&t=93236&start=15

[socratis]

Not sure if it's a bug in VirtualBox, in OSX, or in net.lundman. Or a combination of all the above, I simply say to try it. And if you've been using it for years, then start reverting recent changes. Starting with VirtualBox, i.e. downgrade it and see what happens.

BTW, what's the relationship with the thread that you linked to? I didn't see any mention of net.lundman in there...

[mauricev]

BTW, what's the relationship with the thread that you linked to? I didn't see any mention of net.lundman in there...

Of course not, because zfs is not the cause.

[JiF_Brodeur]

Hi having a similar issues included is my kextstat output, hoping it might help.
Thanks
Jean-François

[mauricev]

6.0.6 appears affected. Now testing 6.0.4.

[chango]

Perhaps not a kernel panic (i.e. no panic screen), but I'm getting unexpected sudden shutdown of my machine far too often (MacBook Pro 2018 15", macOS 10.14.6, Satechi USB-C hub attached with mouse chained, USB-3.0 SSD external drive attached via different port). I previously had success removing the kext installed by Duet Display (I forget the kext name), but now still getting the same symptoms without that kext on my system (subjectively, now less frequently, but might be a distraction). The only non-Apple kexts are VB itself, along with some Intel one; output from kextstat | grep -v 'com.apple' is:

com.intel.driver.EnergyDriver (3.5.3)
org.virtualbox.kext.VBoxDrv (6.0.10)
org.virtualbox.kext.VBoxUSB (6.0.10)
org.virtualbox.kext.VBoxNetFlt (6.0.10)
org.virtualbox.kext.VBoxNetAdp (6.0.10)

Hopefully adding another data point might help the gurus here resolve this one.

[mauricev]

The bug is present in 6.0.4

Code: Select all

*** Panic Report ***
panic(cpu 6 caller 0xffffff800c4db92d): Kernel trap at 0xffffffa44baabf66, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x00007f8c2836e000, CR3: 0x00000002241a619b, CR4: 0x00000000001626e0
RAX: 0x0000000000000000, RBX: 0x00007f8c2023e9a4, RCX: 0x0000000000000200, RDX: 0x0000000000000035
RSP: 0xffffffa43aea9c60, RBP: 0xffffffa43aea9d00, RSI: 0x00007f8c20228000, RDI: 0x00007f8c2836e000
R8:  0x00007f8c2023e978, R9:  0x00007f8c2023e9d8, R10: 0x0000000000000000, R11: 0x00007f8c2023e9a2
R12: 0x00007f8c2023e9a0, R13: 0x0000000000006800, R14: 0x00007f8c2023e998, R15: 0x00007f8c2023e978
RFL: 0x0000000000010246, RIP: 0xffffffa44baabf66, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x00007f8c2836e000, Error code: 0x0000000000000002, Fault CPU: 0x6, PL: 1, VF: 5

Backtrace (CPU 6), Frame : Return Address
0xffffffa43aea9730 : 0xffffff800c3aea2d 
0xffffffa43aea9780 : 0xffffff800c4e9e95 
0xffffffa43aea97c0 : 0xffffff800c4db70a 
0xffffffa43aea9830 : 0xffffff800c35bb40 
0xffffffa43aea9850 : 0xffffff800c3ae447 
0xffffffa43aea9970 : 0xffffff800c3ae293 
0xffffffa43aea99e0 : 0xffffff800c4db92d 
0xffffffa43aea9b50 : 0xffffff800c35bb40 
0xffffffa43aea9b70 : 0xffffffa44baabf66 
0xffffffa43aea9d00 : 0xffffffa44ba976f5 
0xffffffa43aea9dc0 : 0xffffffa44b9df2d9 
0xffffffa43aea9df0 : 0xffffffa44b9d4345 
0xffffffa43aea9e30 : 0xffffffa44b9c9485 
0xffffffa43aea9fb0 : 0xffffffa44bab3178 
0xffffffa43a58b8e0 : 0xffffffa44b9e0e72 
0xffffffa43a58ba70 : 0xffffff7f91d865ef 
0xffffffa43a58ba80 : 0xffffff7f91d9945b 
0xffffffa43a58bb40 : 0xffffff800c63a753 
0xffffffa43a58bb80 : 0xffffff800c62eecf 
0xffffffa43a58bc00 : 0xffffff800c620b34 
0xffffffa43a58be00 : 0xffffff800c89bffb 
0xffffffa43a58be30 : 0xffffff800c8f2259 
0xffffffa43a58bf40 : 0xffffff800c9b9cbd 
0xffffffa43a58bfa0 : 0xffffff800c35c306 
      Kernel Extensions in backtrace:
         org.virtualbox.kext.VBoxDrv(6.0.4)[B3C930F3-E26A-3EAF-A252-107E7A11FBD2]@0xffffff7f91d85000->0xffffff7f91e73fff

BSD process name corresponding to current thread: VirtualBoxVM*** Panic Report ***
panic(cpu 6 caller 0xffffff800c4db92d): Kernel trap at 0xffffffa44baabf66, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x00007f8c2836e000, CR3: 0x00000002241a619b, CR4: 0x00000000001626e0
RAX: 0x0000000000000000, RBX: 0x00007f8c2023e9a4, RCX: 0x0000000000000200, RDX: 0x0000000000000035
RSP: 0xffffffa43aea9c60, RBP: 0xffffffa43aea9d00, RSI: 0x00007f8c20228000, RDI: 0x00007f8c2836e000
R8:  0x00007f8c2023e978, R9:  0x00007f8c2023e9d8, R10: 0x0000000000000000, R11: 0x00007f8c2023e9a2
R12: 0x00007f8c2023e9a0, R13: 0x0000000000006800, R14: 0x00007f8c2023e998, R15: 0x00007f8c2023e978
RFL: 0x0000000000010246, RIP: 0xffffffa44baabf66, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x00007f8c2836e000, Error code: 0x0000000000000002, Fault CPU: 0x6, PL: 1, VF: 5

Backtrace (CPU 6), Frame : Return Address
0xffffffa43aea9730 : 0xffffff800c3aea2d 
0xffffffa43aea9780 : 0xffffff800c4e9e95 
0xffffffa43aea97c0 : 0xffffff800c4db70a 
0xffffffa43aea9830 : 0xffffff800c35bb40 
0xffffffa43aea9850 : 0xffffff800c3ae447 
0xffffffa43aea9970 : 0xffffff800c3ae293 
0xffffffa43aea99e0 : 0xffffff800c4db92d 
0xffffffa43aea9b50 : 0xffffff800c35bb40 
0xffffffa43aea9b70 : 0xffffffa44baabf66 
0xffffffa43aea9d00 : 0xffffffa44ba976f5 
0xffffffa43aea9dc0 : 0xffffffa44b9df2d9 
0xffffffa43aea9df0 : 0xffffffa44b9d4345 
0xffffffa43aea9e30 : 0xffffffa44b9c9485 
0xffffffa43aea9fb0 : 0xffffffa44bab3178 
0xffffffa43a58b8e0 : 0xffffffa44b9e0e72 
0xffffffa43a58ba70 : 0xffffff7f91d865ef 
0xffffffa43a58ba80 : 0xffffff7f91d9945b 
0xffffffa43a58bb40 : 0xffffff800c63a753 
0xffffffa43a58bb80 : 0xffffff800c62eecf 
0xffffffa43a58bc00 : 0xffffff800c620b34 
0xffffffa43a58be00 : 0xffffff800c89bffb 
0xffffffa43a58be30 : 0xffffff800c8f2259 
0xffffffa43a58bf40 : 0xffffff800c9b9cbd 
0xffffffa43a58bfa0 : 0xffffff800c35c306 
      Kernel Extensions in backtrace:
         org.virtualbox.kext.VBoxDrv(6.0.4)[B3C930F3-E26A-3EAF-A252-107E7A11FBD2]@0xffffff7f91d85000->0xffffff7f91e73fff

BSD process name corresponding to current thread: VirtualBoxVM

[mauricev]

And in 6.0.2. I seem to have a virtual machine where it happens reliably.

[socratis]

There was a post in the beta section from a developer, that may apply to your situation as well.

we still don't know what causes the crashes, but now have a suspect. You can run the following to disable the potential culprit:

Code: Select all

VBoxManage setextradata global GUI/HidLedsSync 0

If the setting was applied properly, it should be visible in VBox.log where the entry "GUI: HID LEDs sync is enabled" should change to "disabled".

It would be great to know if this has any effect. If it avoids the crashes then it might take a while to confirm, but if it doesn't I guess we will know pretty soon.

[chango]

Just tried booting an Ubuntu 19.04 VM using VirtualBox 6.0.12 r133076 after disabling GUI/HidLedsSync, and same result: unexpected system shut-down. Same kexts as before (but obviously 6.0.12 versions for VB instead of 6.0.10).

[mauricev]

Code: Select all

VBoxManage setextradata global GUI/HidLedsSync 0

This has no effect. Crashes still the same.