Contribute
Register

<< Solved >> Full sleep in the first sleep but not in the subsequent ones before shutdown or reboot

Status
Not open for further replies.
Joined
Dec 10, 2010
Messages
1,374
Motherboard
Gigabyte Z390 Aorus Elite
CPU
i9-9900K
Graphics
RX 6600 XT
Mobile Phone
  1. iOS
Hello everybody. I have observed this behavior in the sleep of my hack:
  • first time it goes to sleep since boot (from Energy Saver / from power button / from Terminal command) it goes well with lights and fans completely off
  • wakes up from sleep with a single touch of keyboard or mouse or with a press of power button
  • next times it goes to sleep it does not turn off lights and fans, screen turns off but fans keep spinning and graphics card light stays on
  • if I restart the PC, the cycle starts again and the first time it goes to sleep everything is as expected, but only the first time.
The pmset -g assertions command shows this output which is the same after full or incomplete sleep.
Code:
Assertion status system-wide:
   BackgroundTask                 0
   ApplePushServiceTask           0
   UserIsActive                   1
   PreventUserIdleDisplaySleep    0
   PreventSystemSleep             0
   ExternalMedia                  0
   InternalPreventDisplaySleep    1
   PreventUserIdleSystemSleep     1
   NetworkClientActive            0
Listed by owning process:
   pid 147(WindowServer): [0x00000f7d000982d7] 00:00:00 UserIsActive named: "com.apple.iohideventsystem.queue.tickle serviceID:1000004e1 name:AppleHIDKeyboardEve product:Apple Keyboard eventType:3"
    Timeout will fire in 60 secs Action=TimeoutActionRelease
   pid 415(sharingd): [0x00000fc400018346] 00:06:27 PreventUserIdleSystemSleep named: "Handoff"
   pid 91(powerd): [0x0000113500108395] 00:00:18 InternalPreventDisplaySleep named: "com.apple.powermanagement.delayDisplayOff"
    Timeout will fire in 42 secs Action=TimeoutActionTurnOff
Kernel Assertions: 0x4=USB
   id=502  level=255 0x4=USB creat=14/6/21 8:47 description=com.apple.usb.externaldevice.14620000 owner=BRCM20702 Hub
   id=504  level=255 0x4=USB creat=14/6/21 8:49 description=com.apple.usb.externaldevice.14840000 owner=Keyboard Hub
   id=506  level=255 0x4=USB creat=14/6/21 8:54 description=com.apple.usb.externaldevice.14843000 owner=USB Optical Mouse
Idle sleep preventers: IODisplayWrangler

Current configuration obtained with pmset -g is:
Code:
autorestart          0
 Sleep On Power Button 1
 hibernatefile        /var/vm/sleepimage
 powernap             0
 networkoversleep     0
 disksleep            15
 sleep                20 (sleep prevented by sharingd)
 hibernatemode        0
 ttyskeepawake        0
 displaysleep         15
 tcpkeepalive         0
 womp                 0
(sleep prevented by sharingd) is shown after full or incomplete sleep.

I have OpenCore 0.7.0 but this behavior happens for several versions of OpenCore. Now I'm in Big Sur 11.4 with MacPro7,1 but it happens also with iMac19,1 and iMacPro1,1 and with Catalina.

The structure of the current EFI folder is:
Code:
├── ACPI
│   ├── SSDT-AWAC-DISABLE.aml
│   ├── SSDT-EC-USBX.aml
│   ├── SSDT-PLUG.aml
│   └── SSDT-PMC.aml
├── Drivers
│   ├── CrScreenshotDxe.efi
│   ├── OpenCanopy.efi
│   ├── OpenHfsPlus.efi
│   └── OpenRuntime.efi
├── Kexts
│   ├── CPUFriend.kext
│   ├── CPUFriendDataProvider.kext
│   ├── IntelMausi.kext
│   ├── Lilu.kext
│   ├── NVMeFix.kext
│   ├── RestrictEvents.kext│
│   ├── SMCProcessor.kext
│   ├── SMCSuperIO.kext
│   ├── USBToolBox.kext
│   ├── UTBMap.kext
│   ├── VirtualSMC.kext
│   ├── WhateverGreen.kext
├── OpenCore.efi
├── Resources
│   ├── Audio
│   ├── Font
│   ├── Image
│   └── Label
├── Tools
│   ├── CsrUtil.efi
│   └── OpenShell.efi
└── config.plist

Attached my current config.plist.

It happens to someone else? What can be the cause that the first sleep works well and the next ones are not complete? What parameter or setting can I look for related to this issue?
Thanks.
 

Attachments

  • config.plist
    20.9 KB · Views: 59
Did you try booting it in safe mode and seeing how sleep works?

It seems some process or application is triggering sharingd.

I have to disconnect all network shares otherwise my machine will not go to sleep.

edit: now I see handoff is the reason....try disabling handoff and then try if sleep works.
 
Do you have wake for network access enabled? That also caused some sleep issues for me.
No, I have it Disabled in BIOS.
 
Did you try booting it in safe mode and seeing how sleep works?

It seems some process or application is triggering sharingd.

I have to disconnect all network shares otherwise my machine will not go to sleep.

edit: now I see handoff is the reason....try disabling handoff and then try if sleep works.
I'll try with Handoff disabled and comment, it's true that I have it enabled. Also safe mode.
 
Good afternoon, It seems that this problem has been solved although the changes I have made are minor and it is hard to believe that they were the cause.
  • First is disabling Handoff in System Preferences> General. @Ben42 told me.
  • Second is setting screen saver so that its timeout is NOT longer than that of screen sleep.
With these 2 modifications, the system goes to sleep several times during the same session, from Energy Saver or from power button or from Terminal. And wake up well.

Note: sometimes I have seen that, although incomplete sleep (fans spinning) always happens when the timeout expires or I press the power button, full sleep (spin off) can take a while (from seconds to 1-2 minutes). It probably has to do with the tasks that macOS is running.
 
Last edited:
Thanks @Ben42 for your suggestion.
 
@miliuco so I assume is this an issue that ran under the radar previously and effects real Mac's as well as our Hacks.

I run all my Hack's with Handoff enabled, where possible. As I use it to move from system to system, usually iPad to one of the iMac's. Including my wife's old iMac 2010 (updated with a BCM94360 WiFi/BT card so uses Handoff/continuity etc. in High Sierra) and my old MacBook Pro mid-2012 running Catalina.

I just booted up my MacBook Pro and generated the pmset -g assertions and pmset -g results. Handoff appears in the assertions results, as it did with your Hack. But the systemwide power settings on the MBP are quite different, which I suppose should be expected. Below are the two screenshots from the MBP.

Screenshot 2021-06-18 at 15.27.41.png sudo pmset-g assertions

Screenshot 2021-06-18 at 15.30.24.png sudo pmset -g

I'll be honest I have not noticed this full sleep, then partial sleep pattern on any of my Mac's or Hack's but I haven't really looked at the sleep processes, well not recently.

The two screenshots below are from my Haswell Refresh iMac1 system, which sleeps OK, as far as I can tell. but I do reset or check the Power Settings on the iMac1 system after each update. I have never looked at the assertions results before. Seems I have some Magic Wake calls and a number of USB device calls.

Screenshot 2021-06-18 at 15.36.54.png sudo pmset -g

Screenshot 2021-06-18 at 15.37.37.png sudo pmset -g assertions

What do you think?
 
@Edhawk
When you get pmset assertions it doesn't mean that sleep doesn't work, as you already know.

For example, you have Handoff enabled and some assertions are related to Handoff. You also have the IoDisplayWrangler process that has to do with display energy saving and doesn't mean anything wrong. And USB devices usually are listed even though they don't cause problems with sleep.

The images that you have uploaded seem normal to me. Compatible with a good sleep function.

I assume you have Wake on lan enabled in BIOS, right? I have it disabled.

The important thing is if the computer goes to complete sleep with lights and fans off.

On the Macs that I have owned or own, sleep has worked fine with the default settings. On rare occasions I have had to modify something. And pmset assertions usually return USB devices or "sleep prevented by sharing" or IoDisplayWrangler even if works fine.

In the Hacks, at least since Catalina, I have a habit of adjusting it this way:
Code:
sudo pmset autopoweroff 0
sudo pmset powernap 0
sudo pmset proximitywake 0
sudo pmset standby 0
sudo pmset tcpkeepalive 0

sudo pmset autorestart 0
sudo pmset hibernatemode 0
sudo pmset ttyskeepawake 0
sudo pmset womp 0

sudo pmset displaysleep 10
sudo pmset disksleep 15
sudo pmset sleep 20

defaults write com.apple.loginwindow PowerButtonSleepsSystem -bool no
All in a single command:
Code:
sudo pmset autopoweroff 0;sudo pmset powernap 0;sudo pmset proximitywake 0;sudo pmset standby 0;sudo pmset tcpkeepalive 0;sudo pmset autorestart 0;sudo pmset hibernatemode 0;sudo pmset ttyskeepawake 0;sudo pmset womp 0;sudo pmset displaysleep 10;sudo pmset disksleep 15;sudo pmset sleep 20;defaults write com.apple.loginwindow PowerButtonSleepsSystem -bool no
 
It was the 'Wake for Ethernet network access' option that was enabled, bios was set correctly with Wake on Lan disabled. i've disabled the System Preferences > Energy Saver setting.

That is some Terminal Command. I didn't know you could add commands together like that, in to one command with the semi-colon separator. You learn something new every day!

I have been using these commands since I was running Mavericks/Yosemite I think:

Disable Hibernation
sudo pmset -a hibernatemode 0
sudo rm /var/vm/sleepimage
sudo mkdir /var/vm/sleepimage

Disable other hibernation options
sudo pmset -a standby 0
sudo pmset -a autopoweroff 0
sudo pmset powernap 0

Added these two recently since running Catalina:
sudo pmset proximitywake 0
sudo pmset tcpkeepalive 1

I found that the 'sudo pmset tcpkeepalive 0' command gave a warning message last time I used it, so set it back to 1. It didn't produce the same warning when I just applied the command using 0. Not sure what's changed other than disabling the Wake on Ethernet network access option. But the Magic-wake assertion has been removed.

Screenshot 2021-06-18 at 21.34.23.png

As you say the 'sharingd Handoff' and USB devices are still present but don't interfere with the Sleep/wake pattern.

Any idea why the 'mod=01/01/1970' date is generated on my system? I would put money on the fact that none of these components or lines of code existed in 1970! Bios & system date and time are set correctly so it shouldn't be an internal clock issue.
 
Status
Not open for further replies.
Back
Top