Fixing Sleep

So to understand how to fix sleep issues in macOS, we need to first look at what contributes to sleep issues most of the time:

  • Incorrectly managed devices(most commonly PCIe based devices)

The reason for this is when devices get an S3 call(or S0 for wake), the driver needs to power down the devices and put into a low state mode(vice versa when waking). Problems arise when such devices don't cooperate with the drivers and the main offenders of these issues are:

  • USB Controllers and Devices
  • GPUs
  • Thunderbolt Controllers and Devices
  • NICs(Both Ethernet and Wifi)
  • NVMe Drives

And there are others that can cause sleep issues that aren't directly(or obviously) related to PCI/e:

  • CPU Power Management
  • Displays
  • NVRAM
  • RTC/System Clocks
  • IRQ Conflicts
  • Audio
  • SMBus
  • TSC

And something many people forget are over and under-clocks:

  • CPUs
    • AVX often breaks iGPUs and hurt overall stability
  • Bad RAM(Both overclocks and mismatched RAM)
    • Even bad/mismatched timings can cause serious issues
  • Factory GPU Overclocks
    • OEMs commonly push a card a bit too far with their custom VBIOS
    • Generally these cards will have a physical switch, allowing you to choose a low power VBIOS

Preparations

In macOS

Before we get in too deep, we'll want to first ready our system:

sudo pmset autopoweroff 0
sudo pmset powernap 0
sudo pmset standby 0
sudo pmset proximitywake 0
sudo pmset tcpkeepalive 0

This will do 5 things for us:

  1. Disables autopoweroff: This is a form of hibernation
  2. Disables powernap: Used to periodically wake the machine for network, and updates(but not the display)
  3. Disables standby: Used as a time period between sleep and going into hibernation
  4. Disables wake from iPhone/Watch: Specifically when your iPhone or Apple Watch come near, the machine will wake
  5. Disables TCP Keep Alive mechanism to prevent wake ups every 2 hours

In your config.plist

While minimal changes are needed, here are the ones we care about:

  • Misc -> Boot -> HibernateMode -> None
    • We're gonna avoid the black magic that is S4 for this guide
  • NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> Argomenti di avvio
    • keepsyms=1 - Makes sure that if a kernel panic does happen during sleep, that we get all the important bits from it
    • swd_panic=1 - Avoids issue where going to sleep results in a reboot, this should instead give us a kernel panic log

In your BIOS

  • Disable:
    • Wake on LAN
    • Trusted Platform Module
      • Note that if you're using BitLocker in Windows, disabling this will result in all your encryption keys being lost. If you're using BitLocker, either disable or note that it may be a cause for wake issues.
    • Wake on USB(Certain boards may actually require this on to wake, but most will get random wakeup calls with it)
  • Enable:
    • Wake on Bluetooth(If using a Bluetooth device for waking like a keyboard, otherwise you can disable)

Main culprits

Fixing USB

This is the #1 cause of sleep issues on hacks, mainly because Apple's drivers are quite bad at guessing ports and the port limit patches have the ill-effect of creating instability.

This guide also includes some other fixes than just mapping:

USB maps with macOS Catalina(10.15) and newer: You may find that even with USB mapping, your sleep breaks. one possible solution is renaming the IOClass value from AppleUSBMergeNub to AppleUSBHostMergeProperties. See here for more info: Changes in Catalina's USB IOClassopen in new window

  • Note: Some USB devices that do not have proper drivers in macOS can unfortunately result in sleep issues. For example, Corsair water coolers with USB addressable control can prevent the machine from sleeping correctly. For these situations, we recommend users disconnect these troublesome devices when debugging sleep issues.

Fixing GPUs

With GPUs, it's fairly easy to know what might be causing issues. This being unsupported GPUs in macOS. By default, any GPU that doesn't have drivers already provided in the OS will run off very basic drivers known as VESA drivers. These provide minimal display output but also cause a big issue in that macOS doesn't actually know how to properly interact with these devices. To fix this, well need to either trick macOS into thinking it's a generic PCIe device(which it can better handle, ideal for desktops) or completely power off the card(on laptops, desktop dGPUs have issues powering down)

Special notes for iGPU users on 10.15.4 and newer:

  • iGPU wake is partially broken due to numerous hacks apple uses in AppleGraphicsPowerManagement.kext with real Macs, to get around this you'll likely need igfxonln=1 to force all displays online. Obviously test first to make sure you have this issue.
  • AAPL,ig-platform-id 07009B3E may fail for desktop Coffee Lake (UHD 630) users, you can try 00009B3E instead. 0300923E is also known to work sometimes.

Other iGPU notes:

  • Some systems with iGPUs (e.g. Kaby Lake and Coffee Lake) may cause system instability in lower power states, and can sometimes manifest as NVMe kernel panics. To resolve, you can add forceRenderStandby=0 to your Argomenti di avvio to disable RC6 Render Standby. See here for more info: IGP causes NVMe Kernel Panic CSTS=0xffffffff #1193open in new window
  • Certain Ice Lake laptops may also kernel panic on Cannot allow DC9 without disallowing DC6 due to issues with transitioning states. A work around for this is using either -noDC9 or -nodisplaysleepDC6 in your Argomenti di avvio

Special note for 4k Displays with AMD dGPUs:

  • Some displays may fail to wake randomly, mainly caused by AGDC preferences. To fix, apply this to your dGPU in DeviceProperties:

Fixing Thunderbolt

Thunderbolt is a very tricky topic in the community, mainly due to the complexity of the situation. You really have just 2 paths to go down if you want Thunderbolt and sleep to work simultaneously:

Note: Thunderbolt can be enabled without extra work if you're ok without sleep, and vice versa.

Fixing NICs

NICs(network Interface Controllers) are fairly easy to fix with sleep, it's mainly the following:

  • Disable WakeOnLAN in the BIOS
    • Most systems will enter a sleep/wake loop with this enabled
  • Disable Wake for network access in macOS(SystemPreferences -> Power)
    • Seems to break on a lot of hacks

Fixing NVMe

So macOS can be quite picky when it comes to NVMe drives, and there's also the issue that Apple's power management drivers are limited to Apple branded drives only. So the main things to do are:

And avoid problematic drives, the main culprits:

  • Samsung's PM981 and PM991 SSDs
  • Micron's 2200S

If you however do have these drives in your system, it's best to disable them via an SSDT: Disabling desktop dGPUsopen in new window. This guide is primarily for dGPU but works the exact same way with NVMe drives(as they're both just PCIe devices)

Fixing CPU Power Management

For Intel:

To verify you have working CPU Power Management, see the Fixing Power Management page. And if not, then patch accordingly.

Also note that incorrect frequency vectors can result in wake issues, so either verify you're using the correct SMBIOS or adjust the frequency vectors of your current SMBIOS with CPUFriend. Tools like one-key-cpufriendopen in new window are known for creating bad frequency vectors so be careful with tools not used by Dortania.

A common kernel panic from wake would be:

Sleep Wake failure in EFI

For AMD:

Fret not, for their is still hope for you as well! AMDRyzenCPUPowerManagement.kextopen in new window can add power management to Ryzen based CPUs. Installation and usage is explained on the repo's README.md

Other Culprits

Displays

So display issues are mainly for laptop lid detection, specifically:

  • Incorrectly made SSDT-PNLF
  • OS vs firmware lid wake
  • Keyboard spams from lid waking it(On PS2 based keyboards)

The former is quite easy to fix, see here: Backlight PNLFopen in new window

For the middle, macOS's lid wake detection can bit a bit broken and you may need to outright disable it:

sudo pmset lidwake 0

And set lidwake 1 to re-enable it.

The latter requires a bit more work. What we'll be doing is trying to nullify semi random key spams that happen on Skylake and newer based HPs though pop up in other OEMs as well. This will also assume that your keyboard is PS2 based and are running VoodooPS2open in new window.

To fix this, grab SSDT-HP-FixLidSleep.dslopen in new window and adapt the ACPI pathing to your keyboard(_CID value being PNP0303). Once this is done, compile and drop into both EFI/OC/ACPI and under config.plist -> ACPI -> Add.

For 99% of HP users, this will fix the random key spam. If not, see below threads:

NVRAM

To verify you have working NVRAM, see the Emulated NVRAM page to verify you have working NVRAM. And if not, then patch accordingly.

RTC

This is mainly relevant for Intel 300 series motherboards(Z3xx), specifically that there's 2 issues:

  • Be default the RTC is disabled(instead using AWAC)
  • The RTC is usually not compatible with macOS

To get around the first issue, see here: Fixing AWACopen in new window

For the second one, it's quite easy to tell you have RTC issues when you either shutdown or restart. Specifically you'll be greeted with a "BIOS Restarted in Safemode" error. To fix this, we'll need to prevent macOS from writing to the RTC regions causing these issues. There are a couple fixes:

  • DisableRtcChecksum: Prevent writing to primary checksum (0x58-0x59), works with most boards
  • UEFI -> ProtoclOverride -> AppleRtcRam + NVRAM -> Add -> rtc-blacklist
  • RTCMemoryFixupopen in new window + rtcfx_exclude=
    • Blacklists certain regions at the kernel level, see README for more info on how to setup

With some legacy boards, you may actually need to patch your RTC: Z68 RTCopen in new window

IRQ Conflicts

IRQ issues usually occur during bootups but some may notice that IRQ calls can break with sleep, this fix is fairly easy:

This will provide you with both SSDT-HPET.aml and patches_OC.plist, You will want to add the SSDT to EFI/OC/ACPI and add the ACPI patches into your config.plist from the patches_OC.plist

Audio

Unmanaged or incorrectly managed audio devices can also cause issues, either disable unused audio devices in your BIOS or verify they're working correctly here:

SMBus

Main reason you'd care about SMBus is AppleSMBus can help properly manage both SMBus and PCI devices like with power states. Problem is the kext usually won't load by itself, so you'll need to actually create the SSDT-SMBS-MCHC.

See here on more info on how to make it: Fixing SMBus supportopen in new window

TSC

The TSC(Time Stamp Counter) is responsible for making sure you're hardware is running at the correct speed, problem is some firmware(mainly HEDT/Server and Asus Laptops) will not write the TSC to all cores causing issues. To get around this, we have 3 options:

The former 2 are plug n play, while the latter will need some customizations:

  • Open up the kext(ShowPackageContents in finder, Contents -> Info.plist) and change the Info.plist -> IOKitPersonalities -> IOPropertyMatch -> IOCPUNumber to the number of CPU threads you have starting from 0(i9 7980xe 18 core would be 35 as it has 36 threads total)
  • Compiled version can be found here: TSCAdjustReset.kextopen in new window

The most common way to see the TSC issue:

Case 1Case 2