MacBook Pro reboots at night after disabling hyper-threading to fully mitigate MDS / ZombieLoad

[9839042]

My wife and I recently followed Apple's steps to disable hyper-threading. My wife did it first a few days ago, and then started complaining that her computer had shut down when she would open it up in the morning. I didn't make the connection, and figured there was just some strange issue going on. Then yesterday, I disabled hyper-threading and woke up today to find that my computer had also shut down overnight (they both did).

Neither of us have installed any new software or done anything out of the ordinary with our laptops. The only change is disabling hyper-threading to fully mitigate MDS.

Has anyone else disabled hyper-threading and noticed this issue? We both have 2018 MacBook Pros with Core i9's running macOS 10.14.5.

 

[Candide1759]

Yes, same. I had upgraded to Mojave, rebooted, applied full MDS nvram mitigations on restart, restored all my windows, all was quiet.

Then shut my lid and it rebooted.

MBP 2015.

 

[9839042]

Thanks for sharing! Interesting to see it’s not just a firmware issue with the 2018s then. I reached out to Apple a few days ago and they actually escalated it to their engineering team, so hopefully we’ll see a fix for this soon.

 

[treekram]

Thanks for sharing! Interesting to see it’s not just a firmware issue with the 2018s then. I reached out to Apple a few days ago and they actually escalated it to their engineering team, so hopefully we’ll see a fix for this soon.

Please report back what Apple says. I thought the mitigation document indicated that perhaps Apple had rushed through the mitigations mainly because the 'nvram boot-args="cwae=2"' command indicated that they didn't take the time to create a separate parameter to do whatever boot-args="cwae=2" does (and what it does should have been explained as well). The boot-args parameter can and is used for a variety of purposes, and is usually not something long-term. Certainly, one would not expect that the 'boot-args="cwae=2"" be used forever. So at some point they're going to create a separate parameter or they're going to implement whatever it does in the OS/firmware, in either case it was rushed because that's what should have been done in the first place. They've already done a supplemental 10.14.5 for the T2 chip fixes, I don't think it would have been a big deal to have waited to get a well-thought out mitigation and put it out in a supplemental.

 

[Chipaholics]

My wife and I recently followed Apple's steps to disable hyper-threading. My wife did it first a few days ago, and then started complaining that her computer had shut down when she would open it up in the morning. I didn't make the connection, and figured there was just some strange issue going on. Then yesterday, I disabled hyper-threading and woke up today to find that my computer had also shut down overnight (they both did).

Neither of us have installed any new software or done anything out of the ordinary with our laptops. The only change is disabling hyper-threading to fully mitigate MDS.

Has anyone else disabled hyper-threading and noticed this issue? We both have 2018 MacBook Pros with Core i9's running macOS 10.14.5.

Thanks for your post, I believe I have a similar issue -

I also followed Apple’s steps to disable hyper-threading and noticed that my 13” MacBook Pro 2018 now reboots and asks for password, every morning without fail, after having gone to sleep during the night.

My unit is one that very very rarely suffered a T2 crash/reboot prior to this last week.

However, I disabled hyper-threading at the same time as carrying out the 10.14.5 update that Apple reported to contain a T2 crash bug fix, so I didn’t know which change caused the change in behaviour.

Yesterday I re-enabled hyper-threading to test, and this morning I still have a T2 crash/reboot. I suspect that it was the 10.14.5 update that is causing problems in my case. I have sent feedback to Apple.

Have you been able to pinpoint the problem as disabling hyper-threading, as opposed to the 10.14.5 update? Did you have problem free time on 10.14.5 supplemental update before disabling hyper-threading?

 

[9839042]

Thanks for your post, I believe I have a similar issue -

I also followed Apple’s steps to disable hyper-threading and noticed that my 13” MacBook Pro 2018 now reboots and asks for password, every morning without fail, after having gone to sleep during the night.

My unit is one that very very rarely suffered a T2 crash/reboot prior to this last week.

However, I disabled hyper-threading at the same time as carrying out the 10.14.5 update that Apple reported to contain a T2 crash bug fix, so I didn’t know which change caused the change in behaviour.

Yesterday I re-enabled hyper-threading to test, and this morning I still have a T2 crash/reboot. I suspect that it was the 10.14.5 update that is causing problems in my case. I have sent feedback to Apple.

Have you been able to pinpoint the problem as disabling hyper-threading, as opposed to the 10.14.5 update? Did you have problem free time on 10.14.5 supplemental update before disabling hyper-threading?

That’s very interesting! Thankfully because my wife and I updated at different times, I have some good insight here.

I updated to 10.14.5 days well before applying the supplemental update. Obviously there were no issues just with 10.14.5.

My wife updated to 10.14.5 (also without the supplemental update) and disabled hyper-threading immediately. That’s when the crashes started. I remember distinctly that she didn’t have the update because when she told me that her laptop had crashed twice overnight, I had her check for updates and the T2 supplemental update came up. She installed it without any improvement.

My laptop did have the supplemental update when I disabled hyper-threading, and obviously it’s in the same situation. Neither of our laptops really experienced the T2 crashes either, it was pretty smooth sailing prior to this.

It’s concerning that you’re still seeing the crashes after re-enabling it. I haven’t tried that on either of our machines, but if that’s the case it seems like resetting the NVRAM somehow isn’t fully wiping it out. That wouldn’t make any sense but who knows what’s going on haha.

 

[Candide1759]

I can now report that my machine is also rebooting since upgrade to Mojave and disabling HT.

I believe the trigger is going into Hibernate (or coming out of Hibernate).

So I am resetting the SMC and NVRAM. It is possible that my settings differ from the normal case.

Here are the settings I use:
(confusingly, some parameters are seconds, some are minutes):

AC:
sudo pmset -c sleep 0
sudo pmset -c standby 0

Battery:
sudo pmset -b sleep 120
sudo pmset -b standby 1

All:
sudo pmset -a standbydelay 5
sudo pmset -a hibernatemode 25
sudo pmset -a acwake 0
sudo pmset -a lidwake 0
sudo pmset -a darkwakes 0
sudo pmset -a ttyskeepawake 0

Sources:
Resetting NVRAM / PRAM (http://support.apple.com/kb/HT1379)
https://apple.stackexchange.com/que...nce-between-autopoweroff-and-standby-in-pmset

 

[9839042]

I can now report that my machine is also rebooting since upgrade to Mojave and disabling HT.

I believe the trigger is going into Hibernate (or coming out of Hibernate).

So I am resetting the SMC and NVRAM. It is possible that my settings differ from the normal case.

Here are the settings I use:
(confusingly, some parameters are seconds, some are minutes):

AC:
sudo pmset -c sleep 0
sudo pmset -c standby 0

Battery:
sudo pmset -b sleep 120
sudo pmset -b standby 1

All:
sudo pmset -a standbydelay 5
sudo pmset -a hibernatemode 25
sudo pmset -a acwake 0
sudo pmset -a lidwake 0
sudo pmset -a darkwakes 0
sudo pmset -a ttyskeepawake 0

Sources:
Resetting NVRAM / PRAM (http://support.apple.com/kb/HT1379)
https://apple.stackexchange.com/que...nce-between-autopoweroff-and-standby-in-pmset

Thanks for the report! Are you planning to re-disable hyper-threading after resetting the NVRAM? If so, let us know if you still see the crashes!

 

[treekram]

Just some information about the steps that Apple mentioned in their document.

The reason why you need to go into Recovery mode to disable and re-enable hyperthreading is because the [nvram boot-args="cwae=2"] command is protected by SIP. The other command, [nvram SMTDisable=%01], is not protected by SIP. This is another reason why Apple should have really made a new parameter for the cwae=2 setting. If you disable SIP (not saying you should - that would be an individual decision), you can enter these commands in the regular Terminal app, prefixed by "sudo" (so "sudo nvram ...").

If you wish to avoid resetting the NVRAM each time you change the settings, you can remove the NVRAM settings by typing in:
nvram -d boot-args
nvram -d SMTDisable
(again, if you do this in the regular Terminal app, prefix it with "sudo ").

I was testing the results of disabling hyperthreading on performance on my 2018 15" MBP and have seen no ill effects of doing these commands vs. resetting the NVRAM. My guess is that Apple either didn't want to spend the time outlining these commands or thought that resetting the NVRAM would be easier to explain and less prone to user mis-typing. Again, I merely point this out as an alternative - if you believe there is value in resetting the NVRAM every time you need to remove the Apple mitigations, continue to do so.

[UPDATE: Interesting - I just found out that if do the "nvram -d SMTDisable" without the sudo in the regular Terminal app, it will go through without complaining but won't remove the parameter so remember to use the sudo if use the nvram -d command in the regular Terminal app - again, maybe Apple was afraid of people doing this and thus opted to have people reset the NVRAM entirely.]

 

[Candide1759]

I am no longer having reboots after hibernation, whether on AC or battery.

I believe the fix was from resetting the SMC (System Management Controller - which is different than the NVRAM).
https://support.apple.com/en-us/HT201295

So my current config is:
1. Reset SMC, reapplied pmset config that works for me.
2. HT disabled via nvram SMTDisable=%01
3. *NOT* IN EFFECT: nvram boot-args="cwae=2"

cwae=2 was not in effect when hibernate was rebooting, and is not in effect when it is working fine. So I am not blaming cwae=2 for anything other than a slowdown I experienced but since we know so little about what it means, I figure I'm going to let it settle out a bit and wait for the deep dive tech sites to tell us what it does and what the impact is on performance.

The reason I had all these pmset configs handy was that the upgrade from Sierra to High Sierra had some network glitches for me. (After I reset the SMC, Airdrop and iPhone hand-off and iPhone personal hotspot started working correctly for me on High Sierra.)

So now I've needed to reset it after upgrading from High Sierra to Mojave, but for different reasons. I notice that it has new variables when I run "pmset -g" (that I didn't see in High Sierra), so perhaps MacOS is not attentive to making sure it upgrades SMC settings on major upgrades.

 

[9839042]

Was just able to replicate the issue reliably. It is indeed from the computer entering standby mode. I was a bit surprised that my computer didn't crash last night, but I noticed that I had it plugged in. By default, MacBook Pros won't enter standby mode until they've been sleeping for 3 hours on battery power. As such, keeping it plugged in should prevent the crash. I suspect this is also why we haven't seen more reported cases of this happening.

In any case, I came up with a quick test to replicate the standby issue. Simply run:
sudo pmset -a standbydelaylow 10
sudo pmset -a standbydelayhigh 10
(or just sudo pmset -a standbydelay 10, depending on your model)

After doing this, unplug your laptop if it's plugged in, and close the lid of your laptop for around a minute. What you've done is instruct your computer to enter standby mode after 10 seconds, instead of 3 hours. When you open it back up, it'll have crashed.

On the bright side, a workaround for the time being without having to make any changes to NVRAM settings (either boot-args or SMTDisable) is to run:
sudo pmset -a standby 0

That will outright disable standby mode, preventing your computer from crashing overnight. Of course, you can also just keep your computer plugged in while the lid is closed.

Hope they get this fixed up soon!

 

[Candide1759]

Was just able to replicate the issue reliably. It is indeed from the computer entering standby mode.
...
Hope they get this fixed up soon!

Nice, glad you were able to replicate it too.

Are you going to try resetting the System Management Controller to see if that resolves it?

See this KB for background and instructions on how to reset.
https://support.apple.com/en-us/HT201295