[SOLVED] Ventura/Sonoma - Random (Scheduled PM) Wake from Sleep

[guindillas]

I use Bluesnooze myself on may hacks to toggle BT on and off during sleep, it get's around a know issue with Magic Mouse not working after wake from sleep :-

Yeah Bluesnooze is a masterpiece, i am using it to because of some waking problems tha spikes the cpu in hackinstosh side.

Have not come across this kext before, after a quick search it seems to be something do with driver management :-

CVE-2022-32917: AppleSPU out of bounds write​

Information about 0-days exploited in-the-wild!
googleprojectzero.github.io

So probably quite important ....

Yeah, I 've red something about macbook pro's with this situation. At the moment is the unique thing darkwaking, funny is with battery it takes 5-6 seconds, and with AC 45 seconds. What the hell should be!

Sleep/Wakes since boot at 2023-11-27 20:11:12 +0100 :12   Dark Wake Count in this sleep cycle:2
2023-11-28 05:05:05 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:17%) 8 secs   
2023-11-28 06:40:08 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:16%) 5 secs   
2023-11-28 08:15:25 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:16%) 6 secs   
2023-11-28 09:50:48 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:16%) 5 secs   
2023-11-28 11:25:48 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:16%) 9 secs   
2023-11-28 11:48:32 +0100 Wake                    Wake from Deep Idle [CDNVA] : due to SMC.OutboxNotEmpty smc.70070000 lid/HID Activity Using BATT (Charge:16%) 2502 secs
Sleep/Wakes since boot at 2023-11-27 20:11:12 +0100 :18   Dark Wake Count in this sleep cycle:5
2023-11-28 14:05:32 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs  
2023-11-28 15:41:13 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs  
2023-11-28 17:17:06 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs  
2023-11-28 18:53:04 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs  
2023-11-28 20:28:41 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs  
2023-11-28 21:46:34 +0100 Wake                    Wake from Deep Idle [CDNVA] : due to SMC.OutboxNotEmpty smc.70070000 lid/UserActivity Assertion Using AC (Charge:70%)

Yesterday I found something interesting in the middle of the night DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty voice_trigger/
this voice_trigger part make me think something about the mic and Siri, but I tried to deactivate siri and still persist with the normal AOP.OutboxNotEmpty spu_queue_overflow_ep42/

In conclusion, Apple should offer his customers the option to choose what happens with the battery, is the more common replacement in this pieces of hardware, and there is no DIY cheap official option. Should be easy a ****n BIG button in the middle of the battery options, something like: Dont waste energy when lid is closed or sleeping, deactivating whatever services are needed. If Apple is choosing to priorice his services, and degrading intentionally the battery performance of his customers, goes for another debate.


Cheers!

 

[pulpinex]

I tried it (Sonoma 1.4.1) --> no more unexpected (scheduled) wakes.

Thanks

 

[pulpinex]

Yeah Bluesnooze is a masterpiece, i am using it to because of some waking problems tha spikes the cpu in hackinstosh side.


Yeah, I 've red something about macbook pro's with this situation. At the moment is the unique thing darkwaking, funny is with battery it takes 5-6 seconds, and with AC 45 seconds. What the hell should be!

Sleep/Wakes since boot at 2023-11-27 20:11:12 +0100 :12   Dark Wake Count in this sleep cycle:2
2023-11-28 05:05:05 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:17%) 8 secs  
2023-11-28 06:40:08 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:16%) 5 secs  
2023-11-28 08:15:25 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:16%) 6 secs  
2023-11-28 09:50:48 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:16%) 5 secs  
2023-11-28 11:25:48 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using BATT (Charge:16%) 9 secs  
2023-11-28 11:48:32 +0100 Wake                    Wake from Deep Idle [CDNVA] : due to SMC.OutboxNotEmpty smc.70070000 lid/HID Activity Using BATT (Charge:16%) 2502 secs
Sleep/Wakes since boot at 2023-11-27 20:11:12 +0100 :18   Dark Wake Count in this sleep cycle:5
2023-11-28 14:05:32 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs 
2023-11-28 15:41:13 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs 
2023-11-28 17:17:06 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs 
2023-11-28 18:53:04 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs 
2023-11-28 20:28:41 +0100 DarkWake                DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty spu_queue_overflow_ep42/ Using AC (Charge:70%) 45 secs 
2023-11-28 21:46:34 +0100 Wake                    Wake from Deep Idle [CDNVA] : due to SMC.OutboxNotEmpty smc.70070000 lid/UserActivity Assertion Using AC (Charge:70%)

Yesterday I found something interesting in the middle of the night DarkWake from Deep Idle [CDN] : due to AOP.OutboxNotEmpty voice_trigger/
this voice_trigger part make me think something about the mic and Siri, but I tried to deactivate siri and still persist with the normal AOP.OutboxNotEmpty spu_queue_overflow_ep42/

In conclusion, Apple should offer his customers the option to choose what happens with the battery, is the more common replacement in this pieces of hardware, and there is no DIY cheap official option. Should be easy a ****n BIG button in the middle of the battery options, something like: Dont waste energy when lid is closed or sleeping, deactivating whatever services are needed. If Apple is choosing to priorice his services, and degrading intentionally the battery performance of his customers, goes for another debate.


Cheers!

Bluesnooze and - I add - Jettison!

 

[Malenca]

hi.. having sleep issues on sonoma. Goes to sleep and then looks like hybernate..Power switch flashs. When trying to wake up with mouse or keyboard nothing happens. Using power switch system comes back but frozen....Any ideas????

 

[Edhawk]

Check your USB configuration is set correctly, assuming you have one. That is the most common reason for Sleep/Wake & instant reboot issues when running a Hack.

 

[rimvydukas]

Hi,
I'm unhappy Mac user which constantly has wake up issues on my genuine Macs. Found this quite interesting thread. I knew most of workarounds, found few new ones, this new wake up in sonoma in particular. Checked my logs and saw the same wakeups. Implemented plist override and these are gone. But I still have more interesting problem. When I issue pmset sleepnow command, laptop screen turns off but mac does not want to sleep, I still get ping replies from it:/ Can anyone help me with this nonsense?

System-wide power settings:
Currently in use:
standby 1
Sleep On Power Button 1
SleepServices 0
hibernatefile /var/vm/sleepimage
powernap 0
networkoversleep 0
disksleep 10
sleep 1 (sleep prevented by AddressBookSourceSync, powerd)
hibernatemode 3
ttyskeepawake 0
displaysleep 2
tcpkeepalive 0
lowpowermode 0
womp 0

And my main problem, I guess is with these entries in log:

2023-12-13 18:55:10.356297+0000 localhost kernel[0]: (AppleTopCaseHIDEventDriver) [HID] [ATC] AppleDeviceManagementHIDEventService:rocessWakeReason Wake reason: Host (0x01)
2023-12-13 21:00:57.743819+0200 localhost kernel[0]: (AppleTopCaseHIDEventDriver) [HID] [ATC] AppleDeviceManagementHIDEventService:rocessWakeReason Wake reason: Host (0x01)
2023-12-13 21:02:03.439418+0200 localhost kernel[0]: (AppleTopCaseHIDEventDriver) [HID] [ATC] AppleDeviceManagementHIDEventService:rocessWakeReason Wake reason: Host (0x01)
2023-12-13 21:17:08.093107+0200 localhost kernel[0]: (AppleTopCaseHIDEventDriver) [HID] [ATC] AppleDeviceManagementHIDEventService:rocessWakeReason Wake reason: Host (0x01)

Laptop in question - Apple Mpro M1 14" with freshly installed sonoma 14.0 and upgraded to 14.2 today. Upgrade didn't change anything

pmset -g sched shows nothing.

 

[jaymonkey]

my main problem, I guess is with these entries in log:

2023-12-13 18:55:10.356297+0000 localhost kernel[0]: (AppleTopCaseHIDEventDriver) [HID] [ATC] AppleDeviceManagementHIDEventService:: processWakeReason Wake reason: Host (0x01)

@rimvydukas,

Seems this is another common problem with genuine Mac's as the same issue is reported here :-

(AppleTopCaseHIDEventDriver) makes my Mac… - Apple Community

discussions.apple.com

And here :-

AppleTopCaseHIDEventDriver is draining battery when sleeping in macOS Ventura

I have a new MacBook Pro M1 Max running Ventura 13.2.1 with just 34 battery cycles but already 92% max capacity. Using log show --last boot --style syslog | fgrep "Wake reason" I was abl...

apple.stackexchange.com

As reported in one of the above threads, a possible fix for the AppleTopCaseHIDEventDriver wake reason might be turning off Bluetooth and WiFi before sleeping. Try it manually first, if it helps then you could automate it using 3rd party tools such as Better Touch Tool and/or Bluesnooze.

All my genuine Mac's are Intel based and are stuck on Big Sur due to their age and don't suffer from this particular sleep/wake issue so I can't unfortunately investigate the problem further.

Cheers
Jay

 

[markoskz]

Hi, i want to comment on what worked for me, i have sonoma, then i use method for ventura fix, and sonoma fix (with powerD by jaymonkey), and I still had sudden awake, one or two overnight..

as others mentioned in a post, In OC config.plist enable the patch that prevents waking up RTC wake reason

then:
1) I added that patch (to true, with checked) in Opencore Configurator
config.plist > kernel > patch > disable RTC wake scheduling
2) I save changes and reset machine
3) I reset NVRAM at Bootloader to flush out for new changes
4) I put it to sleep, and then I didn't wake up randomly, it worked great!!!!

➜  ~ pmset -g stats                                         
Sleep Count:1
Dark Wake Count:0
User Wake Count:1

 

[OSX790]

Thank you @jaymonkey for the info on Sonoma.

I upgraded my machine to Sonoma and it was walking up at random. Applied the changes as detailed for Sonoma but did not work, so did the Ventura fix and all seem to be running fine.

I had already applied the Ventura fix on Ventura then upgraded to Sonoma, so initial thought was that it would remain, but looks like it does not or was a user error on my part.

Thank you

 

[jaymonkey]

I upgraded my machine to Sonoma and it was walking up at random. Applied the changes as detailed for Sonoma but did not work, so did the Ventura fix and all seem to be running fine/ I had already applied the Ventura fix on Ventura then upgraded to Sonoma, so initial thought was that it would remain, but looks like it does not or was a user error on my part.

@OSX790,

As detailed in the updates towards the end of the main guide in post #1, for me i found that the Ventura sleep fix continued to work after updating Ventura multiple times and also after upgrading to Sonoma.

However in all cases i used the small incremental software update/upgrade which only updates the needed files, in the case of the Sonoma upgrade this was approx 4.5GB.

The only thing i can think of is that maybe you used the full fat Macos Sonoma Installer (~15GB) to upgrade from Ventura to Sonoma ... if so then all system files would be re-written and re-flagged, hence the sleep fix would need to be re-applied.

Cheers
Jay