A Guide on Fixing Sleep Issues

[shrieken213]

This applies not only to Yosemite but to all recent versions, but since these boards are much more active than the DSDT section, I'll post it here.

 

I've recently struggled to make sleep work with my Z97MX-Gaming 5 and 4790K. It would sleep the first cycle, then instantly wake up on all subsequent cycles. On the kernel log, wake reason was "Wake reason: ?" which obviously does not help! Googling also doesn't do much because "?" can't be searched. But after some work I figured out how to make it all work.

 

The biggest offender to this kind of thing is the peripheral interfaces, namely LAN and USB. Often there is a device that keeps waking the computer up; if you're using the Corsair Hydro series, the USB pump interface is one of these devices. It's common sense, but it's also the easiest to fix because all you need is some trial and error.

 

Now, if that's not the issue (like me who only has keyboard, mouse, audio and some storage), there may be a rogue process that keeps waking the computer up. You can check verbose wake assertions and logs with:

pmset -g assertions
pmset -g log

Assertions override the power management settings, which includes sleep. This does not strictly mean these processes will completely block sleep. For example, if you have a Time Machine backup running on a local hard drive and you set hard drives to spin down when idle, Time Machine will prevent idle spin down. It's nonetheless important to note assertions because it is, after all, a list of things that affect power settings. It is possible that you have your wake issues within the assertions.

 

Logs print much more verbose information than the kernel log. You will see a wall of text, mostly of unimportant information regarding individual processes entering and waking from sleep mode. However, note that at the top of each section you will see entries without PID. These point not to processes but to the actual kernel activity, and these are the important bits. Even if your kernel log says "Wake reason: ?", you will find the exact reasons in the log. You will need to look for:

Wake [CDNVA] due to PWRB XHC1/User: Using AC

In my case, I have a working sleep configuration now, and I woke the computer using PWRB, or the power button. XHC1/User means it was either done through the USB 3.0 port or by the user itself, and since it didn't wake up by itself it's obviously me who woke it up. However, if you have issues, yours might look more like:

Wake [CDNVA] due to GLAN EHC1 EHC2: Using AC

In this case, GLAN (LAN), EHC1 and EHC2 (USB 2.0) woke the computer up. If you see GLAN, your computer may have woken up because of network issues. The most common setting that causes GLAN wake is "Wake for Ethernet Access" under the Energy Saver panel in System Preferences. Disable it.

 

 

My system wokes up immediately after going to sleep.

 

Terminal says: 

kernel[0] <Notice>: Wake reason: PXSX PXSX

I found PXSX in my DSDT, it is returns

                    Name (_PRW, Package (0x02)
                    {
                        0x09, 
                        0x04
                    })

I tried to delete that section but no success. Please help me to fix this problem.

 

 

 

Concerning Dark Wake

 

I was personally helping abn0rmal.pdx with his issue. His pmset -g log returned the following:

2015-06-13 08:45:58 +0300 DarkWake     DarkWake [CDN] due to PXSX PXSX/: Using AC

 

As you can see from the screenshot of my IOReg, PXSX is a generic device name for PCIe connected cards such as your Ethernet and my USB 3.0 PCIe card. NexHimself suggests that in some cases GLAN can be replaced by PXSX, but it is important to note that it's not always a network card. Therefore, before we go ahead and mess with device names in the DSDT, we need to focus on the actual wake mechanism. Note that the process that caused wake was "DarkWake." From what I can gather, dark wake is a state of half-sleep, half-wake, triggered by "Wake for Ethernet Access" which ends up breaking your sleep/wake. If you see this in your log, I suggest using the common boot flag of darkwake=0. 

 

It is also possible that RTC0 is among the reasons. If so, your computer is waking up because of an RTC alarm. This is a setting in the BIOS that you must disable for sleep, and you can find it in the power section of most BIOSes. There are some settings in Clover's configuration as well that affect RTC: AppleRTC under KernelAndKextPatches, Rtc8Allowed under ACPI/DSDT, and FIX_RTC_20000 and FixHPET_0010 under ACPI/DSDT/Fixes. You do not need Rtc8Allowed, and you most likely do not need Fix_RTC. Also, starting with Mavericks, you do not need FixHPET. Only enable AppleRTC if your CMOS resets after a wake or reboot. Rtc8Allowed is an proposed (snake oil? we don't know yet) method of fixing CMOS resets instead of patching AppleRTC.kext like the AppleRTC setting, and it does not really work. 

 

If you see EHC1, EHC2 and so on, USB 2.0 is waking the computer up. Again, this might point to actual devices plugged into the computer. However, it could also mean incorrect settings in your Clover config.plist. Only enable USB injection and FixOwnership if you need them. You should disable AddClockID and HighCurrent to rule out any extraneous causes regarding USB sleep issues.

 

All wake reasons (GLAN, EHC1, etc.) are affected by DSDT settings. If you don't have one, you can find guides on how to extract yours. Let's take a look at the DSDT.

 

 

DSDT

 

Clover has a lot of settings in config.plist that affect the DSDT. The bulk of these settings are under the ACPI/DSDT/Fixes menu. Usually you do not need most of these settings, and it is sometimes safe to completely delete this entry. If you're still unsure about it, try to slim it down as much as you can. 

 

It's also useful to have all of these disabled except the ones you really need while editing your DSDT yourself. That way you know exactly how your DSDT affects your computer, and that it's not Clover that's causing issues.

 

You sometimes need a _DSM injection which inserts device specific methods/properties that you see on your IOReg. Most of the time you do not need it, and when you do, Clover injection does this for you. It is advisable to keep it in Clover.

 

However, there are cases where Clover injects them in the wrong places. A Z97/H97 series board may have a weird USB setup like mine and Clover was having a hard time finding the right USB device. Try moving the _DSM entry from the root hub (HUBN) to the actual device (XHC1 etc.) and vice versa. I was interested in enabling the high current mod, which is injected in the same place as the USB injection under the same _DSM entry. I moved the power settings (e.g. "AAPL,current-available") from the root hub to the actual ports (e.g. HS10 and SS04) for it to work.

 

_PRW

 

Each wake reason (GLAN, etc.) are "Device" entries in the DSDT, located in _SB.PCI0. Here I will use GLAN from my original DSDT as an example.

        Device (GLAN)
        {
            Name (_ADR, 0x00190000)
            OperationRegion (GLBA, PCI_Config, Zero, 0x0100)
            Field (GLBA, AnyAcc, NoLock, Preserve)
            {
                DVID,   16, 
                        Offset (0xCC), 
                        Offset (0xCD), 
                PMEE,   1, 
                    ,   6, 
                PMES,   1
            }
and so on...

Within each device, you have many "methods" that give the device properties. We're interested in the _PRW method, which controls power. If you've edited DSDTs before you will know this little bugger well.

            Method (_PRW, 0, NotSerialized)
            {
                Return (GPRW (0x0D, 0x04))
            }

 

There may be incorrect settings in your raw DSDT, as shown above. GPRW should return 0x09, 0x04. If your DSDT returns something else, that needs fixing.

            Method (_PRW, 0, NotSerialized)
            {
                Return (GPRW (0x09, 0x04))
            }

Apply this to each device that you saw in your pmset log. If an ACPI expert could enlighten us on exactly how _PRW works, that would be great. If you want some more detail on the Clover suggestions, check out the Clover wiki.

 

 

If I forgot any tips, post your own! The more the better!

[abn0rmal.pdx]

My system wokes up immediately after going to sleep.

 

Terminal says: 

kernel[0] <Notice>: Wake reason: PXSX PXSX

I found PXSX in my DSDT, it is returns

                    Name (_PRW, Package (0x02)
                    {
                        0x09, 
                        0x04
                    })

I tried to delete that section but no success. Please help me to fix this problem.

[WaldMeister]

 

My system wokes up immediately after going to sleep.

 

Terminal says: 

kernel[0] <Notice>: Wake reason: PXSX PXSX

I found PXSX in my DSDT, it is returns

                    Name (_PRW, Package (0x02)
                    {
                        0x09, 
                        0x04
                    })

I tried to delete that section but no success. Please help me to fix this problem.

 

 

PXSX is a network device most of the time, did you check for this: 

 

 

 The most common setting that causes GLAN wake is "Wake for Ethernet Access" under the Energy Saver panel in System Preferences. Disable it.

GLAN can be replaced by PXSX in this case. 

[shrieken213]

Added information about dark wake to the main guide. 

[shrieken213]

I discovered the repercussions of the _PRW patch.

Changing to 0x09, 0x04 disables wake by that device completely, at least on the two boards that I tested on. If it's applied to a USB device (EHC, XHC) it will disable wake by USB keyboard and mouse, etc. This will probably limit how you wake the computer to the power button. If we could investigate this further I'd appreciate it.

[viper2g1]

I have been having sleep problems and not until I saw your post did I realize that it might be unavoidable.  I do have the hydro series water cooling pump for my CPU and it is plugged directly into the motherboard via a USB header, I also use corsair commander which also plugs to the motherboard via a USB header.  Am I stuck with sleep problems because of that?  I have disabled network sleep in the bios and in the settings.  Here is my relevant log entries about sleep:

 

Dec 13 15:24:21 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:25:19 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:26:18 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:27:14 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:28:13 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:29:11 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:30:11 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:31:08 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:32:08 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:33:04 Stormageddons-iMac kernel[0]: Wake reason: GLAN XHC HDEF (Network)
Dec 13 15:33:11 Stormageddons-iMac kernel[0]: full wake promotion (reason 1) 2282 ms

[griftopia]

I applied the fix to return 0x09 instead of 0x0D. my syslog was complaining about EHC2,HDEF preventing sleep. Now I don't know/care what EHC2 was at this time. However my HDEF is my webcam. On resume, I lose my webcam. Essentially I think the underlying USB port is not waking up until I reboot. 

 

Can anyone help me? How do I get back the internal USB ports I'm losing on resume?

[michele872]

Can you help me?

2017-05-28 00:48:43.990312+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN EH02 EH01

2017-05-28 00:48:43.990313+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN EH02 EH01

2017-05-28 00:48:56.066356+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN EH02 EH01

2017-05-28 00:48:56.066357+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN EH02 EH01

2017-05-28 00:52:28.961815+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: PWRB EH02 EH01 (User)

2017-05-28 00:52:28.961816+0200  localhost kernel[0]: (AppleACPIPlatform) Wake reason: PWRB EH02 EH01 (User)

[Vahids]

localhost kernel[0]: (AppleACPIPlatform) Wake reason: GLAN XHC XDCI (Network)

 

What should this wake reason related?

[makk]

I have Wake Reason RTC Alarm

 

Wasn't doing this prior to update to 11.6 and switching models MacAir7,2 to MacBookPro12,1

 

Do you have any ideas?