scheduled wakeup freezes system
gsternagl opened this issue · 9 comments
Hi zearp,
I have 2 NUC8i5BEK which I have running since 2021 with various OSX release just fine.
Since to Ventura I have a wakeup issue.
Wake-up via keyboard or mouse (both USB) works just fine but waking up through scheduled alarms, the machine goes into power-on mode but then freezes without a kernel panic and I have to reboot it then. Not network at this time either. As these scheduled alarms happen frequently, I cannot use sleep anymore.
I had no issues with exactly this same machine with Big Sur or Monterey. It all started when I updated to Ventura. And yes I have your EFI and the latest OpenCore version. I was able to trace it down to be related to Thunderbolt somehow. I have a second display connected via Thunderbolt / Displayport. When I unconnect that display, software schedule wakeups work fine again. When I put it back and reboot (no hotplug enabled), up schedule wakeup the machine freezes again. I have Thunderbold security in legacy mode and TB-firmware is unpatched.
What I have tried thus far:
-
run OSX in safe-mode (to avoid loading 3rd party drivers) => issue is still there -
rebuild the kext-cache or whatever it's called these days with Onyx => issue persists -
booted in text-mode to see whether there are any obscure messages => nothing out of the normal -
updated the NUC8 BIOS to the latest, went back to stock settings and then re-enabled all settings again. -
I have exactly the same NUC8i5BEK with the same HW, BIOS-settings, PM-settings, Coreboot and OSX versions but without a second display connected on the Thunderbolt port => **there I don't have this wakeup issues.**
Originally the "faulty" NUC8 was upgraded from Monterey to Ventura but I had some issues after this upgrade with it. So I re-installed and then restored my last Timemachine backup. As this issue with Thunderbolt didn't exist up to Monterey, I still suspected that there are some left-overs from my previous Monterey or Big Sur days, brought in through Timemachine restore. But I have also been able to reproduce the issue with an external USB-SSD drive which was freshly installed with Ventura.
The NUC8 is running with the stock Bluetooth and Wifi builtin-devices and the required drivers but I have them both switched off all the time because I don't need them.
Anyway: Thanks a ton zearp for giving us all the opportunity to work with these nice little machines and OSX. Your work is greatly appreciated. If you have any ideas how I can debug such an issue I would appreciate. I'd love to be able to see where the system is actually stopping and in which part of the kernel or in which kernel extension. System logs, Power-logs don't show me anything related to the sudden stop.
How do I reproduce:
at e.g. 12:00 I enter:
sudo pmset schedule wake "12/05/2022 12:03:00"
Then I put the system to sleep through the Apple menue (but pmset sleepnow has the same effect).
When the machine tries to wake up at 12:03, power light goes on but USB lights stay off, display(s) also stay off, network is dead, machine does not wake up through KBD, mouse or power-button.
thanks for your help in advance
You may have to enable some pmset things for it to wake up. Your sleep will be so called dark sleep when using scheduled wakes. Dark sleep has always been tricky on hacks. I’ll try on my machine maybe tonight by or tomorrow. If you disabled all pmset things it’s likely not to work.
Also Ventura came out during the holidays. Many kexts need some fixed so I wouldn’t be surprised if some Ventura fixes are needed upstream (OpenCore itself and kexts). It may take a while before those are updated.
My advice would be to stay on Monterey where everything works. Specially on production machines it can’t harm to stay one major version behind until it’s more mature and stable.
Gone are the days where Apple would work on and fix one OS properly. Now they push out a new macOS every single year. With all the downsides that brings. Specially if you use 3rd party hardware like music equipment.
Even on my real Mac I haven’t updated yet because many manufacturers can’t keep up with Apple and didn’t update any drivers for Ventura yet.
Yeah I wish I could go back to Monterey but I produced too much data since then on Ventura and it will be difficult to revert back. I have been using the NUCs for work for a long time as the are really stable despite also having a MBP M2. Anyway I will turn off (auto) sleep for now and just completely shutdown the computer after work. As a sidenote, I prepared an EFI USB stick and removed all non-essential kexts from it, just leaving the core stuff that you need to get the OS to boot up (VirtualSMC, etc.). But the issue waking up via scheduled wakes still is there.
One other solution would be to completely disable scheduled wakeups but I haven't found any solution to do that. Basically any application seems to be able to set their own schedules. My current "pmset -g sched" looks like this:
[0] wake at 12/05/2022 17:00:00 by 'com.apple.alarm.user-visible-com.apple.calaccessd.alarmEngine.alarm.name'
[1] wake at 12/05/2022 19:00:00 by 'com.apple.alarm.user-visible-com.apple.donotdisturb.server.ScheduleLifetimeMonitor.timer' User visible: true
[2] wake at 12/05/2022 19:00:00 by 'com.apple.alarm.user-visible-com.apple.donotdisturb.server.ScheduleLifetimeMonitor.timer' User visible: true
[3] wake at 12/05/2022 19:00:00 by 'com.apple.alarm.user-visible-com.apple.donotdisturb.server.ScheduleLifetimeMonitor.timer' User visible: true
[4] wake at 12/05/2022 19:00:00 by 'com.apple.alarm.user-visible-com.apple.donotdisturb.server.ScheduleLifetimeMonitor.timer' User visible: true
[5] wake at 12/05/2022 19:00:00 by 'com.apple.alarm.user-visible-com.apple.donotdisturb.server.ScheduleLifetimeMonitor.timer' User visible: true
[6] wake at 12/05/2022 19:00:00 by 'com.apple.alarm.user-visible-com.apple.donotdisturb.server.ScheduleLifetimeMonitor.timer' User visible: true
[7] wake at 12/05/2022 19:00:00 by 'com.apple.alarm.user-visible-com.apple.donotdisturb.server.ScheduleLifetimeMonitor.timer' User visible: true
[8] wake at 12/06/2022 10:54:51 by 'com.apple.alarm.user-visible-com.apple.acmd.alarm'
[9] wake at 12/06/2022 11:47:08 by 'com.apple.alarm.user-visible-com.apple.acmd.alarm'
[10] wake at 12/06/2022 13:41:42 by 'com.apple.alarm.user-visible-com.apple.acmd.alarm'
[11] wake at 12/06/2022 13:53:15 by 'com.apple.alarm.user-visible-com.apple.acmd.alarm'
[12] wake at 12/06/2022 14:57:07 by 'com.apple.alarm.user-visible-com.apple.acmd.alarm'
[13] wake at 12/06/2022 15:57:55 by 'com.apple.alarm.user-visible-com.apple.acmd.alarm'
[14] wake at 12/06/2022 16:21:17 by 'com.apple.alarm.user-visible-com.apple.acmd.alarm'
Anytime one of these would wake up my system from a normal sleep it will hang my NUC.
The issue here is dark wake/sleep is tricky to say the least and what you're trying to do requires that. Your computer doesn't really go to sleep as in S3 or some other sleep state. It sort of remains awake so it can fully wake up when some event needs to be handled. Either check mail, make a backup or in your case wake up the machine at a certain time.
For this to work you need luck and have things such as tcp keep alive enabled. I don't know what exactly scheduled wake-ups need in order to work. But I know for Time Machine backups to work while sleeping it needs tcp keep alive. Same applies to some iCloud stuff.
The funny thing is that if I would change the readme to leave certain things on I get people complaining that their machine wakes up during sleep and then goes back to sleep while the screen remains off. So I leave it up to the end user in the readme and only explain the options and say which are essential settings for sleep to work at all.
I fear that without any crashes or panics there is not much to go on for me in order to find some kind of solution. It is a bit outside of the scope of this EFI. Because dark wake/sleep is just difficult on hackintosh. There is another layer of complexity as we're essentially running a mobile (laptop) platform which is always more tricky when it comes to sleep related stuff and a hackintosh.
Do your system logs have any dark wake entries?
Unfortunately there are no entries in the syslog, PM-log, etc. from the wake event which freezes the system. The system just freezes upon software / timer-based wakeup.
What surprises me is that keyboard wakeup from the same initiated sleep / hibernate state works just fine, but a software / timer based wakeup leeds to an immediate freeze without even a panic. It looks like that there is a wakeup code vector which is called but ends in nirvana and cannot be handled by the kernel. But this vector must be different from the one which is used when a keyboard or mouse is touched. However as soon as I remove the thunderbolt-based second display and reboot, sleep and wakeups work just fine. Could this be caused by the underlying and probably incomplete SSDT for the thunderbolt controller ? Which SSDT is responsible for handling that ? Is it SSDT-EC-USBX or SSDT-TYPC ? I have created a DSDT dump of that same NUC on Linux if that would help to compare but I don't know enough about SSDTs to figure out where the differences are. I am using your complete EFI-tree, mostly unmodified except for the personalized items. But nothing changed on the SSDTs or kernel-extensions side. I tried the HibernateFix.kext yesterday and tried to enable debugging messages but wakeup - freeze does not create any more messages. So my suspision is that it's way down in the stack and not even handled by the kernel anymore.
thanks for your help
Tonight I will try a scheduled wake and see what happens. If I get same I could try and debug it but I'm not sure if its fixable.
SSDT-TYPC-NUC8-BC does Thunderbolt related fixes. You can try disabling that one yea, if that fixes it we know where to look for a possible solution.
Hibernate is another black magic thing to get to work on hacks, specially mobile platforms. I got it to work on my old Latitude laptop but sometimes it doesn't wake up from hibernation. Hibernation is disabled on my Macbook by default. Not sure where or if Apple actually uses hibernation sleep anywhere.
I disabled and removed SSDT-TYPC-NUC8-BC from my config and also from the ACPI directory. No real visible changes other than I had problems putting the system to sleep which took a couple of attempts. But the SW driven wake-up still makes the NUC freeze.
I also tried hibernating to disk / flash but can't get it to properly wakeup again. It goes to sleep and then on wakeup it's seems like it's loading memory content from the disk but then restarts into OpenCore bootloader.
I did reset my NVRAM between these attempts just to be on the safe side.
I think for now I will just turn off sleep and shutdown at the end of the day.
Thanks for investing some time with my problem
I'm unable to reproduce it. Just tried a scheduled wake-up myself. Used pmset to set it to wake up after 10 minutes and then used the sleepnow argument to put it to sleep right away and after 10 minutes it woke up showing me the login screen.
This only happens when there is a second screen attached to the Thunderbolt port.
Anyway I have found a workaround to avoid the freeze:
I have added & enabled an old existing kernel patch which turns-off RTC scheduled wakeups. In config.plist I've added:
Kernel -> Patch
Identifier: com.apple.driver.AppleRTC
Base: __ZN8AppleRTC18setupDateTimeAlarmEPK11RTCDateTime
Comment: Disable RTC wake scheduling
Replace: C3
MinKernel: 19.0.0
Count: 1
Enabled: True
Workaround exists