Contribute
Register

Display doesn't turn back on when waking from sleep on macOS 13.1

Joined
May 25, 2010
Messages
17
Motherboard
Gigabyte Z390 Aorus Pro Wifi
CPU
i9-9900K
Graphics
RX 580
Mac
  1. MacBook Pro
I upgraded from Monterey to Ventura, and after a while realized that my installed version of WhateverGreen was too old (I had 1.5.8) to be loaded when running Ventura. Surprisingly to me, the machine still booted and everything worked except hardware accelerated JPEG decoding. I tried a couple "AppleGVA" (?) preference entries which didn't help, but the issue was fixed by eventually upgrading to the newest WhateverGreen (1.6.3 at time of writing). After that, everything works except the issue in the title of the post: the screen won't turn back on after sleep, I have to power down the machine with the power button.
I believe the only special setting I have that relates to GPU/WhateverGreen is a device properties entry, which is taken from the OpenCore install guide: AAPL,ig-platform-id <0300913E>. I am using the iMac19,1 SMBIOS
 
Hi - Remove your personal data from the config.plist, zip and post your EFI Folder and I will take a look for you. I had the same board and Graphics card apart from the CPU whereas mine was an i7 which shouldn't matter too much in the scheme of things.
 
Thanks @esafeddie, I attached my zipped OC directory here. I disabled automatically sleeping (I think) with
Code:
sudo pmset displaysleep 0
sudo pmset sleep 0
and shut it down last night. Today when I started it up in the morning, the issue seems not to happen. I am going to put those settings back to non-zero to re-enable sleep, and see if the problem mysteriously went away. I will keep the thread updated as to whether the issue resurfaces.
 

Attachments

  • ocbackup.zip
    983.6 KB · Views: 28
Hi - I had a look at the EFI Folder you posted, no offence but I do not understand how you manage to Bootup let alone reach the Desktop to have Sleep/Wake problems.

The OC Folder structure is all wrong. How on earth is this machine booting if this is a true representation of how it is on your machine?

Attached is a true representation of how your OC Folder should be, this is a sample by @miliuco, albeit with a few edits to suit your machine and SmBIOS. take a look and make a comparison to your own.

I f you decide to try it, make a backup of your own, place this on spare USB Drive, clean the NvRAM and boot off it and see the results, if there is a problem we can work off it from there. If @miliuco comes across this post, he or another member can offer aid.

All files and kexts are of the latest OC versions.
 

Attachments

  • EFI.zip
    5.2 MB · Views: 51
I only zipped the OC directory, and excluded the "Tools" and "Drivers" since those do not seem relevant here, they are exactly what's in the OpenCore 0.8.7 DEBUG zip file. I figured that would be pretty obvious but I apologize for the confusion.
 
I only zipped the OC directory, and excluded the "Tools" and "Drivers" since those do not seem relevant here, they are exactly what's in the OpenCore 0.8.7 DEBUG zip file. I figured that would be pretty obvious but I apologize for the confusion.
Ok I understand, no worries.
 
I got around my display sleep issue, but not by using the EFI directory posted in this thread. I will try to summarize the steps I took here.
I get an early boot failure when trying to boot using the EFI directory posted in this thread, when booted from a USB stick. I used a previously working bootable USB and just replaced the EFI directory. There are some differences in the ACPI section: slightly different SSDTs are used, when compared with my working one.
I was then unpleasantly surprised to find my existing, working, OpenCore install no longer working. I reset my NVRAM using the OpenCore hidden menu option, and then reinstalled just the BOOTX64.efi binary. I normally load OpenCore.efi directly from systemd-boot, the default arch linux boot loader, so I reinstalled OpenCore the normal way (copying BOOTX64.efi from the opencore zip file to /<efi partition>/EFI/BOOT/BOOTX64.efi) and everything worked again.
Bafflingly, I restored my previous bootloader setup, by copying systemd-bootx64.efi to /BOOT/BOOTX64.efi, and everything still works. It seems like this systemd-boot -> OpenCore configuration works really well until the EFI variables get messed with, and then I have to reset it like this.
What remains unclear is whether or not an NVRAM reset would have solved the initial issue (display not waking back up after it was put to sleep) or why trying to boot from this better EFI cause my existing install to hang on IONVMEController::start. I've had enough of messing around with it for now, so perhaps it will go unsolved. Thank you @esafeddie for the help
 
for anyone else who encounters a similar issue, the way I finally fixed it was to switch from iMac19,1 to iMacPro1,1 SMBIOS. I looked at the kernel logs after the issue happened, and each time I saw a message about "IGPU hang" from IOAcceleratorFamily2. Unfortunately, I don't think I saved the log output anywhere, but the message was prominently shown. I was not optimistic about being able to debug the problem, so I just disabled the iGPU in the UEFI settings and switched to an SMBIOS that doesn't expect it to be present. The issue mentioned in the first post never happened again and I was able to exceed a month of uptime on the machine, with automatic sleep enabled and working.
 
Back
Top