Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hibernation Issues with OpenCore #72

Open
khronokernel opened this issue Mar 2, 2021 · 150 comments
Open

Hibernation Issues with OpenCore #72

khronokernel opened this issue Mar 2, 2021 · 150 comments
Labels
back-end Core functionality bug Something isn't working help wanted Extra attention is needed

Comments

@khronokernel
Copy link
Member

khronokernel commented Mar 2, 2021

For some machines, hibernation is broken resulting in Sleep Wake Failure when waking. Currently we recommend users disable hibernation until a more suitable solution is found:

sudo pmset -a hibernatemode 0

Note: Please only reply with possible solutions. This issue is not a discussion thread

@khronokernel khronokernel added the bug Something isn't working label Mar 2, 2021
khronokernel added a commit that referenced this issue Mar 4, 2021
@houser42
Copy link

houser42 commented Mar 4, 2021

I hope this is helpful. This post by @traviswparker indicates there was a fix in a custom plist:
#19 (comment)
I am using an adopted version of that config on a Macbook Pro 10,2 with no hibernation issues AFAIK. Many thanks

@khronokernel
Copy link
Member Author

@houser42 Their configuration breaks OpenCore spec and removes a lot of what the patcher uses to ensure a stable system when SMBIOS is changed such as WhateverGreen and AirportFixup. They haven't responded to the thread about what they actually changed and diffing between it and the patcher's plist is more confusing than anything.

Assuming logically what could've fixed hibernation with their build is the removal of OpenRuntime.efi. Problem is we require this driver for RequestBootVarRouting functionality to ensure macOS doesn't try to boot without OpenCore when blessing an update volume. Additionally this is only a theory, so we're unsure if their other changes had any logical affects on the setup

@houser42
Copy link

houser42 commented Mar 4, 2021

I see, appreciate the heads-up. I guess I should really go back to the main config.plist and wait for a real fix.
Many thanks!

@khronokernel
Copy link
Member Author

@houser42 To test this theory, can you try to see if this branch works with hibernation?:

https://github.com/dortania/Opencore-Legacy-Patcher/tree/hibernation

@houser42
Copy link

houser42 commented Mar 4, 2021

@khronokernel
Yes, in fact, I just updated to that versions, and it appears so, so far. YMMV.
At least short sessions. Meaning close the lid, or select sleep and wait for 30 secs and open again.
No issues so far at least.

@khronokernel
Copy link
Member Author

Awesome, can you test if it wakes correctly after setting sudo pmset -a hibernatemode 25. This will make the Mac enter hibernation directly when told to sleep

@houser42
Copy link

houser42 commented Mar 4, 2021

Sure.
You mean just run sudo pmset -a hibernatemode 25 in the terminal and then invoke start again manually?

@khronokernel
Copy link
Member Author

Yeah

@houser42
Copy link

houser42 commented Mar 4, 2021

Yes, that appears to work. BTW. I am on Big Sur 11.2.2 if that matters.

@khronokernel
Copy link
Member Author

Awesome, I actually have 1 more test I just pushed to that branch. It re-enables OpenRuntime as well as DiscardHibernateMap. I'm curious if that last quirk is what we're missing for hibernation support

@houser42
Copy link

houser42 commented Mar 4, 2021

Ok. You mean load same link: https://github.com/dortania/Opencore-Legacy-Patcher/archive/hibernation.zip again now and just run the patcher again?

@khronokernel
Copy link
Member Author

Yeah

@houser42
Copy link

houser42 commented Mar 4, 2021

Yes, still appears to work as expected. No issues so far..

@khronokernel
Copy link
Member Author

Awesome! I'm going to merge the changes however will keep this issue open for the day. If there aren't any reports of it still being broken then I'll close it. Thanks so much for your help!

@houser42
Copy link

houser42 commented Mar 4, 2021

My pleasure. I just hope I am doing it right then ..;)
Possibly unrelated, but tried removing the verbose boot and got some errors:
It looks like I need to update something python. Would appreciate a comment if you have a sec?
This was quick so did not check the docs properly...
Many thanks for any hints

####################
# Copying OpenCore #
####################
- Coping OpenCore onto EFI partition
Removing preexisting EFI folder
Traceback (most recent call last):
  File "/Users/user/Desktop/Opencore-Legacy-Patcher-hibernation/OpenCore-Patcher.command", line 93, in <module>
    OpenCoreLegacyPatcher().main_menu()
  File "/Users/user/Desktop/Opencore-Legacy-Patcher-hibernation/OpenCore-Patcher.command", line 87, in main_menu
    response = menu.start()
  File "/Users/user/Desktop/Opencore-Legacy-Patcher-hibernation/Resources/utilities.py", line 102, in start
    self.options[keys.index(selected.upper())][3]() if self.options[keys.index(selected.upper())][3] else None
  File "/Users/user/Desktop/Opencore-Legacy-Patcher-hibernation/OpenCore-Patcher.command", line 26, in install_opencore
    build.BuildOpenCore(self.constants.custom_model or self.current_model, self.constants).copy_efi()
  File "/Users/user/Desktop/Opencore-Legacy-Patcher-hibernation/Resources/build.py", line 466, in copy_efi
    shutil.copytree(self.constants.opencore_release_folder / Path("EFI"), mount_path / Path("EFI"))
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/shutil.py", line 557, in copytree
    return _copytree(entries=entries, src=src, dst=dst, symlinks=symlinks,
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/shutil.py", line 513, in _copytree
    raise Error(errors)
shutil.Error: [('/Users/user/Desktop/Opencore-Legacy-Patcher-hibernation/Build-Folder/OpenCore-v0.6.7/EFI/OC/config.plist', '/Volumes/EFI/EFI/OC/config.plist', "[Errno 22] Invalid argument: '/Volumes/EFI/EFI/OC/config.plist'")]

@khronokernel
Copy link
Member Author

Can you try using the binary? We actually converted the patcher to a .app on releases. Here's the latest binary:

https://github.com/dortania/Opencore-Legacy-Patcher/suites/2179614486/artifacts/44846509

This doesn't require any python installs or updates

@houser42
Copy link

houser42 commented Mar 4, 2021

Both the command file and the binary work fine with regards to the install and the actual hibernation issue.
It just will not allow me to edit out the -v from line 859 after boot-args.
But I can live with that for now.

@khronokernel
Copy link
Member Author

We're planning to add DEBUG toggles for the patcher, however our current plan will take some work. So as a work around, you can simply set self.verbose_debug to false as a work-around till we implement it in user-menu:

https://github.com/dortania/Opencore-Legacy-Patcher/blob/main/Resources/Constants.py#L43

@houser42
Copy link

houser42 commented Mar 4, 2021

Ok. I will test longer hibernation over night also. Thanks again.

@family1232009
Copy link

family1232009 commented Mar 4, 2021

I still getting Sleep Wake Failure on my MacBookPro9,2 when ThirdPartyDrives quirk is enabled. Even when hibernation is disabled (hibernatemode 0), my Mac restarts when waking and I still getting this error. When I disable this quirk in the config.plist, the issue goes away.

P.S. Apple broke hibernation on old Macs with third-party SATA SSDs on 10.15+ and now we need the ThirdPartyDrives quirk.
More details acidanthera/bugtracker#484 (comment)

@khronokernel
Copy link
Member Author

@family1232009 Sorry a bit confused, we don't enable ThirdPartyDrives in our patcher. Are you trying to say you need ThirdPartyDrives for hibernation? Confused how you'd get sleep issues with the patcher currently otherwise

@traviswparker
Copy link

traviswparker commented Mar 4, 2021

still seeing hibernation issues on MacBookPro10,1. When waking from hibernate I see the backlight come on, then go off, then come on and reboot.

to ensure the Mac actually hibernates and attempts to wake from EFI, you need to do the following:

sudo pmset -a hibernatemode 25
sudo pmset -a standby 1
sudo pmset -a standbydelaylow 1
sudo pmset -a standbydelayhigh 1

then pmset sleepnow or close the lid and wait at least 1 minute before waking the machine.

@khronokernel
Copy link
Member Author

@family1232009
Copy link

Are you trying to say you need ThirdPartyDrives for hibernation?

Yes, I need ThirdPartyDrives for working hibernation (Safe Sleep) on my MBP9,2. Otherwise, hibernation behaves like normal sleep and I get battery drains.

@houser42
Copy link

houser42 commented Mar 4, 2021

FWIW, using the commands @traviswparker gave, my Macbook Pro 10,2 also crashes at wake using that build. Assuming that is the best way to test this, I am sorry to report that my reports of success were probably incorrect and premature.., but there it is...:(

@mav2010
Copy link

mav2010 commented Oct 2, 2021

ConnectDrivers is the issue!

I can confirm this. I have a MacBook Pro 10,1 (Retina 15" MacBook Pro Mid-2012) and per se everything was working (except for an issue because of my upgraded WiFi card, see here).

But: when the Mac woke up, it sometimes took like 20 seconds or so before the picture appeared (backlight was on from the start). By disabling ConnectDrivers, it is now instant on like it was before on Catalina. Thanks for the find!

@traviswparker
Copy link

Isn't setting ConnectDrivers to false the same as disabling all drivers? In other words, hibernation won't go through OC but neither will BootVarRouting, so installs/upgrades will die with the prohibited symbol until you option-boot and select OC.

@mav2010
Copy link

mav2010 commented Oct 5, 2021

I don‘t think so. The configuration guide states the following. Sounds to like this is only for specific drivers.

And why would an install/upgrade fail even then? If the machine reboots, OC is run anyway again.

ConnectDrivers
Type: plist boolean
Failsafe: false
Description: Perform UEFI controller connection after driver loading.
This option is useful for loading drivers following UEFI driver model as they may not start by themselves. Examples of such drivers are filesystem or audio drivers. While effective, this option may not be necessary for drivers performing automatic connection, and may slightly slowdown the boot.
Note: Some types of firmware, particularly those made by Apple, only connect the boot drive to speed up the boot process. Enable this option to be able to see all the boot options when running multiple drives.

@traviswparker
Copy link

Ok, I might have the low-level details wrong here, but:

When macOS performs an install/upgrade, it sets the boot config in NVRAM to the temporary installer data. This bypasses OC in the EFI partition and you'll get the prohibited symbol on an unsupported Mac. One of the things the OpenRuntime driver does is RequestBootVarRouting, which allows it to intercept that change. It keeps NVRAM pointed at EFI/OC and changes its own boot config to the installer data.

@mav2010
Copy link

mav2010 commented Oct 5, 2021

I cannot judge if that is the case. And since I am on the latest version of Big Sur already, I cannot easily test it.

What I did test is to shut down the MacBook, start it again with an NVRAM reset. Everything booted completely fine. But that is also expected right?

As far as I know (but I might be completely wrong) the Mac does a normal reboot, just with the boot volume pointing to somewhere else. At least when installing Big Sur, it does it like that. I always saw the OC menu and could have selected a different boot volume, if I wanted to. So I would guess, that it is the same for the updates.

@khronokernel: can you maybe enlighten us what exactly BootVarRouting and ConnectDrivers do?

@mayankk2308
Copy link

@mav2010 ConnectDrivers should not affect OpenRuntime.efi and therefore RequestBootVarRouting. Using a debug build, one can see OpenRuntime.efi will load even with ConnectDrivers -> false. Another quick way to test is:

  1. First setup OC to display a boot picker.
  2. Boot into macOS via OC.
  3. Go to System Preferences > Startup Disk and choose your macOS boot volume (or different disk) and restart from there (essentially blessing said disk).

If RequestBootVarRouting is not working as expected, this would override OC and you would not see the boot picker. If it's working, you should still see the OC boot picker (i.e., OC will always boot first).

@sox5404
Copy link

sox5404 commented Oct 21, 2021

Hello all;

I am having issues with Wake on lan on both windows 10 and Mac OS. (MacBook Pro 2011 8,1 13 inch)

If i access the MBP within an hour of entring sleep mode, it works fine. but if i wait longer it doesn't wake up on both windows 10 & big sur.

I have noticed also something in Big Sur when i access via screen sharing app from another mac it wakes up, but not via VNC viewer (which is the important because i am trying to access from ios or windows machine).

I believe it is waking up via screen share app because it has something to do with Bonjour services; not sure though.

I checked on windows the supported Sleep states via "powercfg /availablesleepstates" command and the supported sleep modes were ( Standby S3 , hibernate & Hybrid sleep) , I disabled hibernate via "powercfg.exe /h off" command but also the same issue is still happening not able to wake the w10 installation after an hour.

I believe that there is some setting in the EFI that is overruling the Mac & W10 sleep mode configuration.

Any suggestions?

@lumosideas
Copy link

Hello all;

I am having issues with Wake on lan on both windows 10 and Mac OS. (MacBook Pro 2011 8,1 13 inch)

If i access the MBP within an hour of entring sleep mode, it works fine. but if i wait longer it doesn't wake up on both windows 10 & big sur.

I have noticed also something in Big Sur when i access via screen sharing app from another mac it wakes up, but not via VNC viewer (which is the important because i am trying to access from ios or windows machine).

I believe it is waking up via screen share app because it has something to do with Bonjour services; not sure though.

I checked on windows the supported Sleep states via "powercfg /availablesleepstates" command and the supported sleep modes were ( Standby S3 , hibernate & Hybrid sleep) , I disabled hibernate via "powercfg.exe /h off" command but also the same issue is still happening not able to wake the w10 installation after an hour.

I believe that there is some setting in the EFI that is overruling the Mac & W10 sleep mode configuration.

Any suggestions?

I use a Mac Pro with a remote VNC connection and I have the same issue.
I need the Mac Pro go to sleep and I wake up it remotely when I need to use it
I'm able to connect to it but I see the report log message every time that mean the Mac Pro crashed and restart.

@WashJotson
Copy link

WashJotson commented Oct 27, 2021

Hi, I've got a couple of MacbookPro9,1 on 11.6 which were having frequent hibernate/WakeFromSleep issues and also the backlit black screen for 10-20 seconds on start. I've applied the ConnectDrivers config change and can confirm this fixes the issue on 2 machines, so looks like a platform issue. I've just successfully patched a machine from 11.6 to 11.6.1, which worked with no interaction needed. Now going to patch the other up to Monterey.

Both machines are more or less stock apart from ac Wireless upgrades, and RAM/SSD upgrades.

@Shaun-R
Copy link

Shaun-R commented Nov 8, 2021

Hi there, I'm running macOS Monterey on a MacBook Pro 11,1.

I am encountering this same issue where, if my MBP goes to sleep for a short period, it wakes fine.

However, if sleeping for a long period, it won't wake when I open the lid: I have to press the Power key and wait for it to boot. It appears to be resuming not booting, as it's much faster than booting, but it does mean that Unlock with Apple Watch functionality is broken.

@nikrosa
Copy link

nikrosa commented Nov 9, 2021

Hello. I believe this to be related to this discussion. I have a MacBookPro11,2. While pretty much everything works with the upgrade to Monterey (from Big Sur) with OpenCore, when I leave the machine for long periods and it has gone to sleep for long periods, when I come back I see the following:

  1. Screen turns on, white apple logo
  2. Machine appears to show the post-restart login screen (not the login screen I normally see from sleep), which suggests a restart

Looking at system logs for the most recent instance of the issue:

log show --predicate 'eventMessage contains "Previous shutdown cause"' --last 24h
Filtering the log data using "composedMessage CONTAINS "Previous shutdown cause""
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp Thread Type Activity PID TTL
2021-11-09 10:11:29.009939-0500 0x64a Default 0x0 0 0 kernel: (AppleSMC) Previous shutdown cause: -128

Cause 128 seems pretty nebulous. But looking back further at each instance where this behavior occurred, that same 128 is the cause. Not sure if this is somehow helpful, but if this is the same as what has been encountered by others, it doesn't appear the current build has fixed the issue for all devices. I'm wary of setting hibernatemode 0 given the battery implications. Would appreciate some suggestions. Thanks.

@jbinder6342
Copy link

I have the same issue on a MPB11,1 but if I wait long enough (30m or so it did wake up) it finally gave me the desktop and then I received the hash error on system volume error message -- maybe they are related.

@satmandu
Copy link
Contributor

satmandu commented Nov 9, 2021

MBP11,3 here running Monterey with OpenCore, primary boot volume is NVME...

I'm having an issue where sometimes when coming back from hibernate the keyboard is inaccessible. I can ssh into the machine and tell it to reboot, but until reboot occurs, the keyboard is inaccessible.

Is there a way to kick the keyboard on resume?

@WashJotson
Copy link

Hi, I've got a couple of MacbookPro9,1 on 11.6 which were having frequent hibernate/WakeFromSleep issues and also the backlit black screen for 10-20 seconds on start. I've applied the ConnectDrivers config change and can confirm this fixes the issue on 2 machines, so looks like a platform issue. I've just successfully patched a machine from 11.6 to 11.6.1, which worked with no interaction needed. Now going to patch the other up to Monterey.

Both machines are more or less stock apart from ac Wireless upgrades, and RAM/SSD upgrades.

Just to confirm that both systems are working perfectly on 11.6.1. Monterey upgrade failed, however.

@nikrosa
Copy link

nikrosa commented Nov 10, 2021

@WashJotson @blahdy @mav2010 are you able to provide some direction regarding how to enable the ConnectDriver config change?

@nikrosa
Copy link

nikrosa commented Nov 11, 2021

Hi folks. I actually tried hibernatemode 0 and it had no effect. After a longer period of sleep (14 hours this time), I see a white apple logo, then login screen indicating a restart happened, but when I log in everything is exactly as I left it, it doesn't take time to load up the apps. Is this possibly safe sleep somehow, even though safe sleep is disabled? Any thoughts would be appreciated.

@WashJotson
Copy link

@WashJotson @blahdy @mav2010 are you able to provide some direction regarding how to enable the ConnectDriver config change?

Yep.

If you have OpenCore installed:

  • Mount your EFI volume: sudo diskutil mount /dev/disk0s1. This is assuming OCLP is installed on disk0 (you can check in Disk Utility). This should mount as /Volumes/EFI
  • The setting is in the OCLP config.plist at /Volumes/EFI/EFI/OC/config.plist (substitute the first EFI if your EFI didn't mount there)
  • Edit that with your text editor of choice - search for ConnectDrivers (there is only one) and change the next line from true to false as below:
                <key>ConnectDrivers</key>
                <false/>
  • If you corrupt the file OCLP isn't going to boot, so make sure you get it right!
  • Now unmount your EFI sudo diskutil unmount /dev/disk0s1 and reboot your Mac.

If you don't have OpenCore installed, build OpenCore using the patcher UI. When you get the path for the temporary build, apply the same change to EFI/OC/config.plist in that path and then install it.

@satmandu
Copy link
Contributor

@WashJotson's process dramatically sped up wake from hibernation for me on a MacBookPro11,3.

@nikrosa
Copy link

nikrosa commented Nov 12, 2021

Thanks @WashJotson! What exactly is this changing and what potential side effects might there be? It’s unclear from prior comments.

@WashJotson
Copy link

Thanks @WashJotson! What exactly is this changing and what potential side effects might there be? It’s unclear from prior comments.

From @mav2010 's link to the OpenCore manual, I think it stops OpenCore from force loading all the bundled drivers every time that the system is rebooted. My guess would be when all the drivers are loading it slows down reboots/wake from hibernate sufficiently to fail a macOS check, so it thinks the wake from sleep has failed.

The documentation indicates side effects could be devices or filesystems being disconnected on reboot, but haven't encountered this yet. I will try and let one of my systems hibernate whilst hooked up to a bunch of external devices but doubt this will break anything as those drivers will be in macOS

@nikrosa
Copy link

nikrosa commented Nov 13, 2021

I tried the workaround to set ConnectDrivers to false and rebooted after and everything was fine. I came to my laptop this morning and tried to start it and the same issue occurred.

To be clear, I have two external displays and power connected to my laptop, and the clamshell is closed. The flow is as follows:

  1. I click my external trackpad
  2. The external displays wake up
  3. The main external display shows a white apple logo briefly
  4. The screen seen on restart is shown, with a note below the password suggesting a restart has occurred "unlock with apple watch requires your password when mac restarts" and for some reason at that point I can't use the trackpad or the external keyboard — I have to open the clamshell to use the keyboard to enter my password and login
  5. As soon as I log in everything is already open, as though the restart hadn't occurred — there's no loading period.

This definitely all began right after the upgrade to Monterey using OpenCore.

Looking at the logs I see this:

2021-11-13 09:00:01.014515-0500 0x175bc Default 0x0 0 0 kernel: (AppleSMC) Previous shutdown cause: 5

So the shutdown cause now shows 5 which seems to be a normal restart, but I didn't restart it.

Honestly my main issue with this is that while I can wake up the machine with a click on the external trackpad, I can't use the trackpad after that and I can't use the external keyboard until I log in — I have to open the clamshell to enter my password which was never the case in the past.

Does any of this make any sense to anyone, and does anyone have any suggestions? Also should I switch the ConnectDrivers back to true since this didn't make a difference?

@SemoTech
Copy link

Not sure if relevant here, but I could not get my cMP 5,1 (using OCLP v0.3.1 and Monterey 12.0.1) to sleep, and tried everything. Since it worked fine in Bootcamp Win10, I assumed this was an OCLP issue. Turns out my Logitech BCC950 USB webcam was waking it as soon as it entered sleep.

I got the below, issuing: pmset -g log | grep -e "Sleep.*due to" -e "Wake.*due to"

DarkWake from Normal Sleep [CDN] : due to HDEF EHC1 EHC2/ Using AC (Charge:0%)

My fix was to move the BCC950 from one of the rear internal USB 2.0 ports, to a PCIe USB 3.1 card I had installed by daisy-chaining it to the USB 3.0 hub on the back of my monitor. Now my cMP5,1 sleep and stays asleep like a champ.

Hope this is of help to someone...

@Ausdauersportler
Copy link
Collaborator

This is about legacy macs, only. Please discuss PC laptop issues here.

@lumosideas
Copy link

Hi, the hibernation reprise to work perfectly on my Mac Pro 3.1 (with a UPS connected) after disabling the connection drivers.

@blahdy
Copy link

blahdy commented Jan 10, 2022

Hi, the hibernation reprise to work perfectly on my Mac Pro 3.1 (with a UPS connected) after disabling the connection drivers.

yeah, but that breaks updates. to update you must reenable cooncetdrivers and reboot, or manually hold alt and choose OC during update reboots

@traviswparker
Copy link

yeah, but that breaks updates. to update you must reenable cooncetdrivers and reboot, or manually hold alt and choose OC during update reboots

You're thinking of RequestBootVarRouting, which requires OpenRuntime. Disabling OpenRuntime will prevent routing of resume through OC but also break updating boot-vars. Setting ConnectDrivers false doesn't affect RequestBootVarRouting.

@ilia3101
Copy link

I'm on an iMac 13,2 running Monterey, and it randomly restarts in sleep mode. One time in the middle of the night, with chime and all, and just now it happened about a minute after putting it to sleep.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
back-end Core functionality bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests