Mac freezes on wakeup

[hotpxl]

Symptom:
My Mac sometimes would freeze on wakeup after installing VirtualBox kext. VirtualBox doesn't have to be open. Nor is a running VM needed. The fact that the kext has been installed would cause this issue. It's nondeterministic.

Configuration:
MacBook Pro (Retina, 15-inch, Mid 2015)
macOS High Sierra Version 10.13.4 (17E199)
VirtualBox Version 5.2.8 r121009 (Qt5.6.3) with Extension Pack 5.2.8r121009

Reproduce:
This happens nondeterministically. After install VirtualBox (and approving kext installation in Security & Privacy), Mac has a chance of freezing on wakeup. Either in battery or with power adapter. On wakeup, the backlight will turn on. My Apple Watch will unlock it and receive a notification doing so. But the screen will remain black, and all inputs are neglected. I can only hold the power key to restart.

I'm pretty sure it's VirtualBox. I did a complete fresh install of Mac, and compared both before and after installing VirtualBox. This occurs only after install VirtualBox and its kext. Also there are no other custom kext installed at all.

Also at the time of wakeup, neither VirtualBox nor a VM is running. And to cause this kind of locking issue, only the kext has permission.

Logs:
I think this might have deadlocked the kernel. Anyways I cannot find anything in Console after restart. I have something relevant though, don't know if it's related.

VirtualBoxVM_2018-04-16-205828_Tarsonis.wakeups_resource.diag.txt

(17.05 KiB) Downloaded 19 times

[socratis]

First of all, I got to say that you're the first one (ever?) reporting such an issue. I took a look at your attached file (how did you generate that?) and I noticed the following:

Wakeups:         45001 wakeups over the last 119 seconds (379 wakeups per second average),
                 exceeding limit of 150 wakeups per second over 300 seconds
Wakeups limit:   45000

Something is really, really weird with your setup. 379 wakeups/sec??? What's going on here?
- What do your power settings look like?
- Anything connected to the MBPr?

I have the exact same MBPr model, albeit I'm in 10.11.6. I have an external 10.13 that I could boot from and try to replicate what you have, but it's a pain going from an internal SSD to a rotational USB3 HD

But there are a lot of people on 10.13.4 using VirtualBox 5.2.8, and none has mentioned anything close to that...

[hotpxl]

My power settings is just default. I never changed them.

At the time of this report, I think had a USB hub (with mouse & keyboard), and also a Dell 4k monitor connected to the computer.

Is there anyway I could see what caused the wakeups?

[socratis]

I'd start by disconnecting things and reconnecting them one at a time. I don't know how to tell what's causing the wakeups, other than taking a look at the logs via the Console.app. Or using 'dmesg' from the command line.

I'd start with the USB hub if I were you...

[hotpxl]

I encountered the same thing today, and I'm starting to think it's not related to VirtualBox.
Today there was a kernel update (security update), and the system reboot for that. After that reboot (things still working), the next wakeup freezes.

[socratis]

That's a really good finding! However, the last Apple security update was not on 2018-05-01, but on 2018-04-29. Maybe you didn't get notified? 10.13.4 was first released on 2018-03-29, which would definitely match what you first described in your report, if indeed it's the OSX 10.13.4 and subsequent updates that are triggering the issue.

The problem that *I* have, is that you're the only one that's been reporting such a behavior. Maybe it's about time to reset the SMC on your Mac?
[quote=""How to know if you need to reset the SMC", among other things"]

• Your Mac notebook doesn't respond properly when you close or open the lid.
• Your Mac sleeps or shuts down unexpectedly and you can't turn it back on.

[/quote]

[hotpxl]

Yeah I have reset SMC and NVRAM a couple of times (more than 10) already. I also reinstalled the OS a couple of times (more than 5) but still the same.

I have a mid-2015 MBP, with a AMD GPU. I guess it's probable that after a kernel upgrade and reboot, the driver was still linked against the old kernel (I'm thinking in Linux terms of modprobe, since I'm not familiar with dynamic kernel modules in mac). The same thing happened to virtualbox because it installed a kext as well.

I know that in Linux, if you upgrade kernel and suspend your machine without a reboot, a KP will likely happen. Though in this case, I rebooted my machine after upgrade

[socratis]

If I go with my personal experience only, then 10.13 is not a lucky number.

Last July, I tried the 10.13 beta. I replaced my 10.9.5 HD, installed 10.13 beta. That forced a firmware update on my 2011 17" MBP (the best MBP ever). The next day I had a dead MBP. Dead as a door nail . So, I'm still "trying" 10.13 (external HD), but only after I've sacrificed a virgin goat and bathed the MBP is its blood!

Any chance of you downgrading, to your original 10.11? Have you kept your installers? You could try a test-run, booting from an ext. HD. But, I got to tell you, there are a lot of people running older/newer MBPs with the latest and greatest OSX, you're the one reporting anything close to that. And I haven't seen a report like that in the 8 years or so that I'm active with VirtualBox...

I hope that it's not a hardware issue that's triggered by something innocuous, like a VirtualBox kext. I'd also attack the problem from that angle as well if I were you...

BTW, do me a favor and post the output of:

• kextstat | grep -v com.apple

[hotpxl]

Sure. Thanks!

Code: Select all

kextstat | grep -v com.apple
Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
  160    3 0xffffff7f86c55000 0x64000    0x64000    org.virtualbox.kext.VBoxDrv (5.2.10) B172CB4D-2DAC-34A3-B1ED-8927A492021C <7 5 4 3 1>
  168    0 0xffffff7f86cb9000 0x8000     0x8000     org.virtualbox.kext.VBoxUSB (5.2.10) 18BFD538-2E5A-328C-B8BF-DF95DFDDFC6F <167 160 52 7 5 4 3 1>
  169    0 0xffffff7f86cc1000 0x5000     0x5000     org.virtualbox.kext.VBoxNetFlt (5.2.10) 97411DA8-28E3-3954-85D4-10B616336375 <160 7 5 4 3 1>
  170    0 0xffffff7f86cc6000 0x6000     0x6000     org.virtualbox.kext.VBoxNetAdp (5.2.10) 4A140B73-8C07-3948-8928-D8700E8C7F8B <160 5 4 1>

[socratis]

Nope, no dice here either...