Sequoia 15.5 | Sleep

danfq

New member
AMD OS X Member
Jun 5, 2025
18
1
0
1
CPU:
Ryzen 5 5600X
Hi all!


This is my first post here, so please bear with me.

I've just finished fixing some other issues I had with my Ryzentosh (all details are on my Git Repo - in my Signature).
However, there's one that remains unsolved, no matter how hard I try.

I can't, by any means, get Sleep to work.
I've already tried BIOS options, different SMBios', extra Kexts - you name it. Nothing worked, so far.
The thing is - Sleep used to work just fine in Sonoma.

Is this a known issue, that I'm just not aware of?
Any insight would be appreciated.

Below are my ACPI folder and Kexts folder.
My config.plist is attached.

1749389136994.png1749389148834.png

Please help me lol.


Thanks,
DanFQ
 

Attachments

Solution
Hello, whoever ends up finding this Post.


I've figured out a way to make everything work flawlessly.
It may be messy, and I may change it in the future - if I find a better way to do this.

But, in short, I needed a few patches.
One SSDT, a few DeviceProperties entries, and an ACPI Patch.

The SSDT is attached to this reply, and the other patches are below:

SSDT-DGPU
-------------

This SSDT is a joint effort by me, T3 Chat, and @Edhawk.
It references the PCI bridge (BRG0) and disables all levels of the PCI path by overriding their _STA methods to return Zero:
  • GPP8 - The PCI bus.
  • X161 - The PCI slot.
  • BRG0 - The PCI...
Hi all!


This is my first post here, so please bear with me.

I've just finished fixing some other issues I had with my Ryzentosh (all details are on my Git Repo - in my Signature).
However, there's one that remains unsolved, no matter how hard I try.

I can't, by any means, get Sleep to work.
I've already tried BIOS options, different SMBios', extra Kexts - you name it. Nothing worked, so far.
The thing is - Sleep used to work just fine in Sonoma.

Is this a known issue, that I'm just not aware of?
Any insight would be appreciated.

Below are my ACPI folder and Kexts folder.
My config.plist is attached.

View attachment 17104View attachment 17105

Please help me lol.


Thanks,
DanFQ
There are an incredible amount of posts here, and on other Hackintosh sites, stating about the same thing as your post. Put another way it a vary very common issue and the fix is almost always the same. Sleep/ Wake problems are almost always caused by improper USB Port Mapping.
I downloaded your current EFI and checked your USB Port mapping in your UTBMap.kext and noticed you have all ports set to USB3 or type 3.
Asus says you have the following ports which shows a mixture of USBc (type 9) various USB3 types (all type 3) and several USB 2 (Type 0).

1 x USB 3.1 Gen 1 port(s) (1 at back panel, , USB Type-C®
2 x USB 3.1 Gen 1 port(s) (2 at back panel, , Type-A)
2 x USB 3.1 Gen 1 port(s) (2 at mid-board)
2 x USB 3.1 Gen 2 port(s) (2 at back panel, , Type-A),
6 x USB 2.0 port(s) (2 at back panel, , 4 at mid-board)

I'd suggest remapping your ports paying more attention to the type of port you are mapping.

EDIT: I stole this from Ed Hawk as these guidelines tend to be helpful

How to set USB Port Status

  1. USB2 (0) - Physical USB2 ports on rear I/O plate, these ports always have a Black coloured tang.
  2. USB3 (3) - Physical USB3 ports on rear I/O plate, these ports can have a Red, Blue, Cyan or Yellow coloured tang.
    1. Virtual USB2 ports - served from physical USB3 ports) should be set with the same connector type as the physical port
  3. USB3 (3) - Motherboard Header, usually serving the case front USB3 ports.
    1. Virtual USB2 ports - served from physical USB3 ports) should be set the same as the physical port
  4. Internal (255) - Motherboard USB2 header, this will be any device served from a header port, such as Bluetooth module, case front USB2 ports, case front card reader etc.
    1. Internal connector type should also be used for any Bluetooth USB connection from a built-in M.2 connector (on the Rear I/O plate).
  5. Type-c+sw (9) - Type-C connector on Rear I/O plate, will only show two ports being available,
    1. when the Type-C device is inserted, removed, flipped 180° and reinserted, 1 x Physical Type-C and 1 x virtual USB2 port.
  6. Type-c (10) - Type-C (E) motherboard header, will show four ports being available from a single Type-C connector,
    1. when the Type-C device is inserted, removed, flipped 180° and reinserted, 2 x Type-C and 2 x USB2.
 
Last edited:
  • Like
Reactions: Edhawk and keef247
There are an incredible amount of posts here, and on other Hackintosh sites, stating about the same thing as your post. Put another way it a vary very common issue and the fix is almost always the same. Sleep/ Wake problems are almost always caused by improper USB Port Mapping.
I downloaded your current EFI and checked your USB Port mapping in your UTBMap.kext and noticed you have all ports set to USB3 or type 3.
Asus says you have the following ports which shows a mixture of USBc (type 9) various USB3 types (all type 3) and several USB 2 (Type 0).

1 x USB 3.1 Gen 1 port(s) (1 at back panel, , USB Type-C®
2 x USB 3.1 Gen 1 port(s) (2 at back panel, , Type-A)
2 x USB 3.1 Gen 1 port(s) (2 at mid-board)
2 x USB 3.1 Gen 2 port(s) (2 at back panel, , Type-A),
6 x USB 2.0 port(s) (2 at back panel, , 4 at mid-board)

I'd suggest remapping your ports paying more attention to the type of port you are mapping.

EDIT: I stole this from Ed Hawk as these guidelines tend to be helpful

How to set USB Port Status

  1. USB2 (0) - Physical USB2 ports on rear I/O plate, these ports always have a Black coloured tang.
  2. USB3 (3) - Physical USB3 ports on rear I/O plate, these ports can have a Red, Blue, Cyan or Yellow coloured tang.
    1. Virtual USB2 ports - served from physical USB3 ports) should be set with the same connector type as the physical port
  3. USB3 (3) - Motherboard Header, usually serving the case front USB3 ports.
    1. Virtual USB2 ports - served from physical USB3 ports) should be set the same as the physical port
  4. Internal (255) - Motherboard USB2 header, this will be any device served from a header port, such as Bluetooth module, case front USB2 ports, case front card reader etc.
    1. Internal connector type should also be used for any Bluetooth USB connection from a built-in M.2 connector (on the Rear I/O plate).
  5. Type-c+sw (9) - Type-C connector on Rear I/O plate, will only show two ports being available,
    1. when the Type-C device is inserted, removed, flipped 180° and reinserted, 1 x Physical Type-C and 1 x virtual USB2 port.
  6. Type-c (10) - Type-C (E) motherboard header, will show four ports being available from a single Type-C connector,
    1. when the Type-C device is inserted, removed, flipped 180° and reinserted, 2 x Type-C and 2 x USB2.

Thanks for your prompt reply!

I'm well aware that USB Mapping is the main cause for Sleep issues.
Unfortunately, still no luck.

The EFI you downloaded was (if you got it from the Releases section) the last one I used with Sonoma.
That EFI used to work just fine (Sleep included) on Sonoma - but didn't work with Sequoia.

I therefore re-built the EFI from scratch for Sequoia, and everything is working except Sleep.
As per your suggestion, I re-mapped all my USBs and triple-checked their types, to make sure everything was correct:

1749464474496.jpeg1749464493209.jpeg
(Left - Discovery | Right - After Setting Types)

Even after re-mapping, and applying the BIOS settings suggested in another Post (below), Sleep still doesn't work.
The displays go to sleep (besides an Apple Logo output - below) and the system never fully goes to sleep.

1749464870569.pngIMG_6998.jpeg

After the progress bar reaches a certain point, it switches to the other display, where the progress bar completes and the Login screen appears. But this output remains, on my main display.

The display initializes (my main display) in the way I described, outputting via HDMI.
The Login screen is then outputted on the same display, via DisplayPort.
The secondary display uses HDMI to output.

I'm thinking maybe this is the reason why the system can't Sleep?
Because there's this output still?
Not sure if that's a thing, or not.

(EDIT: Tested this theory by removing the offending GPU - no luck).

My OC folder is attached (anonymized).
Thanks for all your help!


DanFQ
 

Attachments

Last edited:
Thanks for your prompt reply!

I'm well aware that USB Mapping is the main cause for Sleep issues.
Unfortunately, still no luck.

The EFI you downloaded was (if you got it from the Releases section) the last one I used with Sonoma.
That EFI used to work just fine (Sleep included) on Sonoma - but didn't work with Sequoia.

I therefore re-built the EFI from scratch for Sequoia, and everything is working except Sleep.
As per your suggestion, I re-mapped all my USBs and triple-checked their types, to make sure everything was correct:

View attachment 17109View attachment 17110
(Left - Discovery | Right - After Setting Types)

Even after re-mapping, and applying the BIOS settings suggested in another Post (below), Sleep still doesn't work.
The displays go to sleep (besides an Apple Logo output - below) and the system never fully goes to sleep.

View attachment 17111View attachment 17112

After the progress bar reaches a certain point, it switches to the other display, where the progress bar completes and the Login screen appears. But this output remains, on my main display.

The display initializes (my main display) in the way I described, outputting via HDMI.
The Login screen is then outputted on the same display, via DisplayPort.
The secondary display uses HDMI to output.

I'm thinking maybe this is the reason why the system can't Sleep?
Because there's this output still?
Not sure if that's a thing, or not.

(EDIT: Tested this theory by removing the offending GPU - no luck).

My OC folder is attached (anonymized).
Thanks for all your help!


DanFQ
To be frank your EFI is overly complex for the system you have, the new port mapping looks good but prior to it how your computer ever was able to sleep is beyond me. You are loading 24 kexts some of which must conflict and potentially cause issues, a quick example would be using both "HibernationFixup.kext" and USBWakeFixup.kext when you really should not need either.

I'm not sure what you are trying to do with SSDT-HDEF.aml or SSDT-PTXH.aml, really neither should be needed.

I assume you are using OCLP to allow your Broadcom WIFI/ Bluetooth to work but you are loading a crazy amount of kexts to supposedly support it that are not needed, you are also loading BlueToolFixup.kext which should only be needed for intel WIFI solutions.

Also in my opinion AMDRyzenCPUPowerManagement.kext is junk and adds more overhead than its worth.

Remove only the supported graphics card and par down your EFI so its only loading the kexts needed to boot, then find a guide for OCLP as there are a bunch of them, and only add the minimum kexts to allow it to work.

Once you get that sorted test your USB Port map and see if sleep works, if it does you can start to add back to you EFI to customize it hopefully without breaking sleep
 
  • Like
Reactions: Edhawk
You should also look at the Systemwide Power settings in use on your hack.

Sequoia introduced a number of different sleep/wake issue related to event alerts, waking the system, and other USB issues. Which required people to generate a new USBMap.kext or UTBMap.kext for their system.

Look at and post a screenshot of the Hackintool > Power tab. As some power settings may need editing.
 
  • Like
Reactions: leesurone
You should also look at the Systemwide Power settings in use on your hack.

Sequoia introduced a number of different sleep/wake issue related to event alerts, waking the system, and other USB issues. Which required people to generate a new USBMap.kext or UTBMap.kext for their system.

Look at and post a screenshot of the Hackintool > Power tab. As some power settings may need editing.
1749657512367.png

Here are my current Power settings.
I've experimented with a few others - such as "hibernatemode = 0" and "hibernatemode = 25" - to no avail.


DanFQ
 
Hibernatemode should be '0' not '3', as this is a desktop system not a laptop.

Use the screwdriver icon below the Power options window, to change the Hibernatemode setting for you. Reboot, use ResetNvram option from the OC boot screen and try sleep from Apple dropdown menu to see if it will work.
 
To be frank your EFI is overly complex for the system you have, the new port mapping looks good but prior to it how your computer ever was able to sleep is beyond me. You are loading 24 kexts some of which must conflict and potentially cause issues, a quick example would be using both "HibernationFixup.kext" and USBWakeFixup.kext when you really should not need either.

I'm not sure what you are trying to do with SSDT-HDEF.aml or SSDT-PTXH.aml, really neither should be needed.

I assume you are using OCLP to allow your Broadcom WIFI/ Bluetooth to work but you are loading a crazy amount of kexts to supposedly support it that are not needed, you are also loading BlueToolFixup.kext which should only be needed for intel WIFI solutions.

Also in my opinion AMDRyzenCPUPowerManagement.kext is junk and adds more overhead than its worth.

Remove only the supported graphics card and par down your EFI so its only loading the kexts needed to boot, then find a guide for OCLP as there are a bunch of them, and only add the minimum kexts to allow it to work.

Once you get that sorted test your USB Port map and see if sleep works, if it does you can start to add back to you EFI to customize it hopefully without breaking sleep

I totally understand where you're coming from.
However, the EFI I attached had been quite altered, from my experiments to try and make Sleep and Wi-Fi/Bluetooth work.

Right now, I've cleaned up the EFI and it looks like this:

1749657660073.png1749657678055.png

I've removed "BlueToolFixup", as you said, and Bluetooth is working fine - despite a slight delay in boot time, because of:
"AppleKeyStore:7690:74: unexpected session uid: -1 requested by: bluetoothd"

I decided to keep "AMDRyzenCPUPowerManagement" because it allows me to use PowerGadget, to look at my CPU Stats.
If you know of a better alternative, please do enlighten me!

I'm using "IO80211FamilyLegacy" and "IOSkywalkFamily" because, supposedly, they're necessary to allow my BCM4360 to work on modern versions of macOS. I also have a Block entry to allow this downgrade:

1749658157318.png

I'm keeping "SSDT-PTXH" because, for some reason, my USBs only work with it.
This wasn't the case in Sonoma - but Sequoia is refusing to let me use my USBs without it.

I generated "SSDT-EC-USBX-DESKTOP" with SSDTTime, in Windows.

Sleep still refuses to work, unfortunately.

Any more suggestions?
Always ready to learn!


DanFQ
 
Hibernatemode should be '0' not '3', as this is a desktop system not a laptop.

Use the screwdriver icon below the Power options window, to change the Hibernatemode setting for you. Reboot, use ResetNvram option from the OC boot screen and try sleep from Apple dropdown menu to see if it will work.

As I said, I had already tried setting it to 0, with no luck.
Regardless, I set it to 0 again and cleared NVRAM - still not working.

I think you'll get more information out of my Assertions than I am, so here you go:

1749659727277.png

Maybe this can help narrow it down.
It's also noteworthy that the "log show --style syslog | grep "Wake reason"" and "pmset -g log | grep "Entering sleep"" commands both return no output.

Please let me know what other logs you may need, to help me out.
And really, thanks a lot for your time.


DanFQ
 
@Edhawk

I figured it out.
The issue is my unsupported - supposedly disabled - GPU!

Once I removed it completely from the system, Sleep worked flawlessly.
The thing is - I'm trying to find a way to completely power it off via SSDT, but can't figure it out.

Can you help me out?
My current SSDT and DSDT are attached.


Thanks in advance,
DanFQ
 

Attachments

Post a screenshot showing the fully extended PCIe tab from Hackintool, example from my X570 system is attached below.

Screenshot 2025-06-13 at 14.55.19.png Hackintool > PCIe tab fully expanded

I need to see all the IOReg Name and Device Path entries for all the components in your system.

As GFX1 part of the IOReg Name used for your disabled GPU isn't present in your system DSDT.aml table.
 
Post a screenshot showing the fully extended PCIe tab from Hackintool, example from my X570 system is attached below.

View attachment 17198 Hackintool > PCIe tab fully expanded

I need to see all the IOReg Name and Device Path entries for all the components in your system.

As GFX1 part of the IOReg Name used for your disabled GPU isn't present in your system DSDT.aml table.

Yeah, that was quite puzzling for me as well.

However, specifying GFX1 in my SSDT was the only way the SSDT would work.
If I don't specify GFX1, the SSDT doesn't work and I end up with an extra Ghost Display.

The paths (IOReg and PCI) for this GPU are:
  • IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/GPP8@3,1/IOPP/X161@0/IOPP/pci-bridge@0/IOPP/GFX1@0
  • PciRoot(0x0)/Pci(0x3,0x1)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)

Here's a screenshot of the entire PCIe tab (divided because there are quite a lot of Devices in here):

1749832772349.png
1749832940248.png

The offending GPU is highlighted.


Thanks!
DanFQ
 
OK, the 'pic-bridge' section of the GPU's IOReg Name means your SSDT won't work. As the name is missing at least one section.

You need an SSDT-Bridge.aml created using your system DSDT.aml, Corpnewt's SSDTTime script and the Device Path for the dGPU.

When this SSDT-Bridge is added to your OC ACPI folder, with a companion entry in the config.plist the dGPU will be provided with a full name.

Once this is in place, the original SSDT you are using to disable the dGPU can be edited to use the full name/path and should fully disable the dGPU.

See the attached folder named 'Results' which contains the SSDT-Bridge.aml table you need to add to your OC setup.
  1. Add the SSDT-Bridge.aml to your setup.
  2. Reboot your system,
  3. Use the Reset Nvram entry from the OC boot screen.
  4. Boot in to macOS
  5. Post another screenshot of the Hackintool > PCIE tab, so we can see if the dGPU IOReg Name has been fixed.
 

Attachments

Here is a revised SSDT-GHOST-GPU-FIX.aml table with the missing pic-bridge part of the name replaced with BRG0, which is the name generated by Corpnewt's SSDTTime for your system.

Don't use this SSDT until we are sure the rename has taken to the dGPU.
 

Attachments

OK, the 'pic-bridge' section of the GPU's IOReg Name means your SSDT won't work. As the name is missing at least one section.

You need an SSDT-Bridge.aml created using your system DSDT.aml, Corpnewt's SSDTTime script and the Device Path for the dGPU.

When this SSDT-Bridge is added to your OC ACPI folder, with a companion entry in the config.plist the dGPU will be provided with a full name.

Once this is in place, the original SSDT you are using to disable the dGPU can be edited to use the full name/path and should fully disable the dGPU.

See the attached folder named 'Results' which contains the SSDT-Bridge.aml table you need to add to your OC setup.
  1. Add the SSDT-Bridge.aml to your setup.
  2. Reboot your system,
  3. Use the Reset Nvram entry from the OC boot screen.
  4. Boot in to macOS
  5. Post another screenshot of the Hackintool > PCIE tab, so we can see if the dGPU IOReg Name has been fixed.

Here is a revised SSDT-GHOST-GPU-FIX.aml table with the missing pic-bridge part of the name replaced with BRG0, which is the name generated by Corpnewt's SSDTTime for your system.

Don't use this SSDT until we are sure the rename has taken to the dGPU.


Interesting results:
  • Hackintool no longer shows GFX1 at all.
  • Sleep works fine.
  • Audio died (Boot Chime works but that's it - no Internal Speakers anymore).

Here's Hackintool's PCIe tab:

1749839188448.png

Bridges appear to be fixed!
I think I see what used to be GFX1, under:
IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/GPP8@3,1/IOPP/X161@0/IOPP/BRG0@0/IOPP/BRG0@0.

The IOReg path matches (GPP8@3,1 & X161).

I also see that the HD Audio Controller is now at:
IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/GP13@8,1/IOPP/AZAL@0,4

Do I need an SSDT to rename this?

I haven't added the revised SSDT-GHOST-GPU-FIX.aml yet though - just SSDT-Bridge.aml.
Should I replace my SSDT with yours now, and see if everything works well?


Thanks!
DanFQ
 
Last edited:
No, as I needed to see if the name changed more than I expected, which it did. So I have revised the SSDT again to reflect the correct/changed name, see attached.
 

Attachments

No, as I needed to see if the name changed more than I expected, which it did. So I have revised the SSDT again to reflect the correct/changed name, see attached.

Replaced the SSDT.
However, "Internal Speakers" is still gone.

I added a DeviceProperties entry, to set the Layout ID, to match the one I set in boot-args (alcid=11):

1749843673281.png
 
You shouldn't use both options to set the Audio codec layout-id for your system.
While troubleshooting and testing use alcid=xx when you have the correct id use the Device Properties option.
It is easy to get them out of sync and the boot arg will always override the DeviceProperties entry.

Your system uses ALC887-VD28 Audio codec. There may be an alternative id that works better with your system.

I would try layout-id=50 as this custom layout was created for a different Asus Prime motherboard using the ALC887-VD codec.
 
You shouldn't use both options to set the Audio codec layout-id for your system.
While troubleshooting and testing use alcid=xx when you have the correct id use the Device Properties option.
It is easy to get them out of sync and the boot arg will always override the DeviceProperties entry.

Your system uses ALC887-VD28 Audio codec. There may be an alternative id that works better with your system.

I would try layout-id=50 as this custom layout was created for a different Asus Prime motherboard using the ALC887-VD codec.

On-board Audio used to work just fine, with Layout ID 11 - that shouldn't have changed, right?
Also, I checked Hackintool again, and it appears that my HD Audio Controller is now named AZAL instead of HDEF:

1749847496299.png

I do, however, see HDEF in IORegistryExplorer, under the disabled GPU's node:

1749847548182.png
 
@Edhawk


Can you help me out, real quick?

It's literally the only thing not working on this Hack, right now :(
My current snippet for attempting to disable the GPU's HDEF component:

Code:
Scope (\_SB.PCI0.GPP8.X161.BRG0.HDEF)
    {
        Method (_ADR, 0, NotSerialized)  // _ADR: Address
        {
            If (_OSI ("Darwin"))
            {
                Return (0xFFFFFFFF)
            }
            Else
            {
                Return (0x00010000)
            }
        }

        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (_OSI ("Darwin"))
            {
                Return (Zero)
            }
            Else
            {
                Return (0x0F)
            }
        }
    }

I also added this snippet to my config.plist, to no avail:

1750096661032.png

This isn't working.
HDEF is still under the GPU's node, and AZAL still isn't renamed.


DanFQ
 
  AdBlock Detected
Sure, ad-blocking software does a great job at blocking ads, but it also blocks some useful and important features of our website. For the best possible site experience please take a moment to disable your AdBlocker.