Since updating to OC .93 I get a crash on sleep.
shrubberies opened this issue · 12 comments
Please provide the follow information:
- Steps to reproduce the issue -- this is crucial
- macOS version and optionally the build number
- Any changes you made to the config and/or EFI other than serials/etc
- Any logs related to the issue if applicable
Since updating to OC .93 I get a crash on sleep. Power button stays lit solid but screen stays black and I can't resume. The only thing in the system logs is a crash report for the bluetooth module. System has been flawless in the 4 previous releases. Ventura 13.3.1 Apple wifi card in the recommended pcie adapter
Does it happen when you downgrade to a previous release? Also please include the logs. I can’t do much without them other than saying I have no issues whatsoever with sleep on any of my NUCs. The config hasn’t changed so if anything it might be a bug somewhere. But I don’t know without those logs and steps to reproduce.
It is crucial to provide steps to reproduce. It may by be some extra work for those opening issues but it’s also no fun to expect me to do clean installs in order to try and reproduce a reported issue without doing the same yourself. Also you didn’t tell me what if anything has changed in your hardware and so on.
I have had the same issue since upgrading to .92 (I upgraded to Ventura at the same time). It does not happen every time the NUC goes to sleep, but when it does occur that fans are spinning fast. I’ve not been able to see anything interesting in the logs.
There are still many variables despite it being a prebuilt kit. I can only test on an unmodified stock NUC which I do before every release. A full clean install, as well as upgrading my other NUCs. So far none of my systems has an issue with sleep or wake.
log show --style syslog | fgrep "[powerd:sleepWake]"
That should give you all the sleep/wake related log info. It might be way too much. I always clean the logs before testing so it's easier to sift trough all the entries.
I would clean the logs (sudo log erase --all) then put the system to sleep and then check the logs again after triggering the issue or after it has happened.
For me it is really difficult if not impossible to fix an issue without steps to reproduce it every single time. In the case of hackintosh that usually means a clean install + steps. Including stuff like bios changes and any other changes not mentioned in the repo. I have to take into account any changes made that aren't default in the EFI. Else it will be next to impossible to pin point and solve these kind of things.
For now I put some of my NUCs to sleep and woke them back up after a few minutes and it all worked ok for me. Other than doing another clean install I have no idea what I can do to reproduce the issue so I can start troubleshooting it.
A quicker way would be to use the previous release and if the problem doesn't happen in there then I have something to work with as we can compare the changes between those versions.
Oh, I see in Ventura the path to powerd changed but this is how a sleep cycle looks on my stock NUC. I put it to sleep manually, wait for the power button led to go amber (I configured it that way in the bios) and after some time wake it up using the usb keyboard/mouse:
$ log show --style syslog | fgrep "[com.apple.powerd:sleepWake]"
2023-05-16 14:36:14.654226+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] vm.darkwake_mode: 0 -> 0
2023-05-16 14:36:14.656820+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] Current PerfMode: Unrestricted, Target PerfMode: Restricted
2023-05-16 14:36:14.670852+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] sendNoRespNotification: 0x19
2023-05-16 14:36:14.679369+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] PID 135 is not entitled to set wake reason
2023-05-16 14:36:29.684964+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] chooseStandbyDelay(): lowBattery = false, battery powered = false, capacity=0, lowBatteryThreshold=0; chosen delay=86400
2023-05-16 14:36:29.685355+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] Eligible for Standby: 1
2023-05-16 14:36:29.685356+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] standbyDelay:86400 eligibleForStandby:1 elapsedTime:0 gDelta2Standby:86400
2023-05-16 14:36:29.685429+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] Entering Sleep state due to 'Software Sleep pid=172'
2023-05-16 14:36:29.685589+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] connectionFireNotification: 0x0 gen 0x1
2023-05-16 14:36:34.393661+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] No AdaptiveWake is requested. InactivityEnd:Mon Jan 1 01:00:00 2001 PowerNap State:1
2023-05-16 14:37:54.035871+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] No need to refresh inactivity prediction: phase=0, start=0.000000, now=705933474.038388
2023-05-16 14:37:54.035875+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] sendNoRespNotification: 0x8019
2023-05-16 14:37:54.050401+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] Updating wake start timestamp to 283201722008
2023-05-16 14:37:54.059180+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] PID 135 is not entitled to set wake reason
2023-05-16 14:37:54.079590+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] vm.darkwake_mode: 0 -> 0
2023-05-16 14:37:54.086469+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] Cancelling dark wake update capabilities timer
2023-05-16 14:37:54.087352+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] vm.darkwake_mode: 0 -> 0
2023-05-16 14:37:54.090063+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] Current PerfMode: Restricted, Target PerfMode: Unrestricted
2023-05-16 14:37:55.375330+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] Updating wake end timestamp to 284579533060
2023-05-16 14:37:55.375496+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] Wake from Normal Sleep [CDNVA] : due to XDCI/HID Activity
2023-05-16 14:37:55.375497+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] WakeDetails: <private>
2023-05-16 14:37:55.376097+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] <private>
2023-05-16 14:37:55.376547+0200 localhost powerd[88]: [com.apple.powerd:sleepWake] sendNoRespNotification: 0x1f
Also be sure to check the sleep related power settings, specially updates can revert those and break sleep. Especially standby and hibernatemode can cause issues when enabled.
sudo pmset standby 0
sudo pmset autopoweroff 0
sudo pmset proximitywake 0
sudo pmset powernap 0
sudo pmset tcpkeepalive 0
sudo pmset womp 0
sudo pmset hibernatemode 0
You can also use Hackintool to check and fix these:
My NUC us completely stock hardware and there is nothing added to the OS. When I revert to the previous release .92 I no longer have the issue. Trying to dump the log doesn't return anything to the terminal.
power settings
Bluetooth crash log
Translated Report (Full Report Below)
Process: bluetoothd [2958]
Path: /usr/sbin/bluetoothd
Identifier: bluetoothd
Version: ???
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 0
Date/Time: 2023-05-15 08:42:57.1917 -0700
OS Version: macOS 13.3.1 (22E772610a)
Report Version: 12
Anonymous UUID: 8DDA3AD7-BFE3-BAB7-94D0-286824A71BE3
Sleep/Wake UUID: 9298B9FB-2921-45D8-95C3-853B9CE0AF97
Time Awake Since Boot: 30000 seconds
Time Since Wake: 12938 seconds
System Integrity Protection: enabled
Crashed Thread: 2
Exception Type: EXC_GUARD
Exception Codes: GUARD_TYPE_USER
Exception Codes: 0x6000000000000012, 0x0000000000000002
Termination Reason: Namespace LIBSYSTEM, Code 2 Application Triggered Fault
Thread 0:
0 libsystem_kernel.dylib 0x7ff81cd5b5b2 mach_msg2_trap + 10
1 libsystem_kernel.dylib 0x7ff81cd6972d mach_msg2_internal + 78
2 libsystem_kernel.dylib 0x7ff81cd625e4 mach_msg_overwrite + 692
3 libsystem_kernel.dylib 0x7ff81cd5b89a mach_msg + 19
4 CoreFoundation 0x7ff81ce761af __CFRunLoopServiceMachPort + 145
5 CoreFoundation 0x7ff81ce74c30 __CFRunLoopRun + 1365
6 CoreFoundation 0x7ff81ce74071 CFRunLoopRunSpecific + 560
7 CoreFoundation 0x7ff81cef7675 CFRunLoopRun + 40
8 bluetoothd 0x1043da09b 0x1043b0000 + 172187
9 dyld 0x7ff81ca4041f start + 1903
Thread 1:
0 libsystem_pthread.dylib 0x7ff81cd95bb0 start_wqthread + 0
Thread 2 Crashed:
0 libsystem_kernel.dylib 0x7ff81cd66a5a os_fault_with_payload + 10
1 bluetoothd 0x104499888 0x1043b0000 + 956552
2 bluetoothd 0x104442383 0x1043b0000 + 598915
3 bluetoothd 0x1047782c7 0x1043b0000 + 3965639
4 bluetoothd 0x1047796bf 0x1043b0000 + 3970751
5 bluetoothd 0x104757959 0x1043b0000 + 3832153
6 bluetoothd 0x104757583 0x1043b0000 + 3831171
7 libdispatch.dylib 0x7ff81cbf7d91 _dispatch_call_block_and_release + 12
8 libdispatch.dylib 0x7ff81cbf9033 _dispatch_client_callout + 8
9 libdispatch.dylib 0x7ff81cbff200 _dispatch_lane_serial_drain + 769
10 libdispatch.dylib 0x7ff81cbffd6c _dispatch_lane_invoke + 417
11 libdispatch.dylib 0x7ff81cc0a3fc _dispatch_workloop_worker_thread + 765
12 libsystem_pthread.dylib 0x7ff81cd96c55 _pthread_wqthread + 327
13 libsystem_pthread.dylib 0x7ff81cd95bbf start_wqthread + 15
BTW thank you for all of your efforts supporting the NUC. Your releases are well thought out and well crafted and I appreciate the time and effort you put into them and generously share with the community.
You're using an Apple combo card so if all is well you're not loading any bt/wifi related kexts and have disabled the Intel combo card in the bios. Which would rule out any changes in bluetooth kexts in the EFI. Nothing else really changes other than the OpenCore related kexts. I can't think of anything that changed recently that would explain it. Besides the card should be natively supported.
Can you confirm sleep works when using the previous 4.2 release and breaks in 4.3?
The only thing I can find with the same error code as yours is an issue related to unlocking macOS using an Apple Watch. Do you use that feature?
Crash does not occur in previous 4.2 release. I don't use proximity wake or Apple Watch. I did not have the built in wifi disabled in bios but that did not effect previous releases. I'm checking my config.plist for errors and I'll retest with the intel wifi disabled.
I don't know if you were lucky or not that things worked fine without disabling those. It's been a while since I tested that but when I initially started with this project sleep and wake and even usb itself would behave very buggy when using a Broadcom card in the m.2 slow and leaving wifi/bt enabled in the bios. Also the internal usb hub has to be removed from the usb port map kext for sleep to function properly when not using the onboard wifi/bt.
The only changes in the config between 4.2 ands 4.3 is this:
<key>InitialMode</key>
<string>Auto</string>
Which is completely unrelated to your issue, so then it must be caused by one of the kexts. Which is out of my control. Something in one of them must have changed that causes it for you.
I did try to produce it but I can't. I even tried pairing a bunch of bluetooth devices just to see and sleep/wake still functions as expected. Really no clue what's happening on your side but you can just use the "old" release as nothing really changes other than the kext versions and the changes inside those. You can use any release version that support Ventura for that matter. It is not like some kext updates improver performance or something. I just like to stay up-to-date. But it is by no means required.
You could look at the EFI like bios, don't update if you have no issues and by the time the next macOS gets released that might needs an update (rarely needed) you can come back and update to latest version I published. Maybe the bug you run into now has been fixed or has become a non-issue by then.
I can also understand you want to get to the bottom of it just for the sake of it. To do that you're likely going to spend a few reboots to pin down which kext is the culprit. You can use either the latest release and swap back older kexts until it works or use the older one and swap out to new kexts until it breaks. I really do wish I could reproduce it as I'm curious. The only relevant info I could find on your crash log was something to do with Apple Watch lol.
I do both here myself, on some systems I keep the EFI in sync with the repo and on some I haven't updated the EFI in ages, Ventura runs fine, updates install fine; there is no need to update the EFI as long as everything works.
Updating within the same macOS version rarely requires OpenCore or kext updates. Even major releases are usually fine unless Apple changes something big like they did when going from Catalina to Big Sur. So you should be fine using 4.2 until some update or a new macOS breaks it. But I do get wanting to know why you have this issue and how to fix it.
One more thing that makes it more complicated is that you said it doesn't always happen. So even for you it is not a 100% reproducible. Which is crucial when trying to solve these kind of things. The same steps should lead to same result every time. Intermittent issues are the worst.