Ghost Reboot / Restart instead of Shutdown - ASRock B650E Steel Legend WiFi

[errevi]

Hardware​

• Motherboard: ASRock B650E Steel Legend WiFi
• BIOS: 4.10 (AGESA ComboAM5 PI 1.3.0.0a) — tested also on 3.50, same issue
• CPU: AMD Ryzen 7 7800X3D
• OS: macOS Tahoe 26.3 / Sequoia (same issue on both)
• Bootloader: OpenCore 1.0.6
• OCLP laobamac 3.5.1

Problem​

The system shuts down for a second and then immediately restarts instead of staying powered off. The issue is present on every BIOS version from 3.08 onwards (AGESA 1.2.x and 1.3.x). AGESA 1.1.x was not tested.

Sleep/Wake works fine, I just need a second click after keyboard/mouse has been waked up.

Investigation​

pmset logs confirm:

• SMC shutdown cause: 5 → macOS correctly sends S5 shutdown signal
• Dark Wake Count: 3 → system wakes immediately 3 times after every shutdown
• The system enters S5 correctly, but something triggers an immediate wake at hardware level

Root cause identified in DSDT:

In Method (SPTS), when Arg0 == 0x05 (S5 shutdown):

asl
If ((Arg0 == 0x05))
{
PWDE = One // This is the problem!
}

PWDE is bit 6 at offset 0x3BB of OperationRegion (GSMM, SystemMemory, 0xFED80000, 0x1000).

Setting PWDE = 1 during S5 appears to trigger an AGESA-level wake event, causing the immediate reboot. This behavior is identical across BIOS 3.08 through 4.10.

_S5 is correct: {0x05, 0, 0, 0} — macOS knows S5 properly.

What has been tried (all failed)​

1. Binary patches — _PRW S4→S3 for 0x02 and 0x08 wake sources (DSDT has 76 static Name (_PRW) declarations)
2. SSDT-PRWFIX — override all 76 static _PRW with Method returning {0x00, 0x00} → fails with AE_ALREADY_EXISTS
3. SSDT-SPTSFIX — rename SPTS→XPTS, redefine SPTS to call XPTS then set PWDE = Zero after S5 → SSDT loads correctly but reboot persists
4. SSDT-DisableXHC — disable _STA of XHC0/XHC1/XHC2 via Darwin-only _STA = 0 → loads correctly but reboot persists
5. HibernationFixup with hbfx-ahbm=129 → no effect
6. FadtEnableReset = true → no effect
7. BIOS settings — Deep Sleep disabled, USB Device Power On disabled, PCIE Devices Power On disabled, RTC Alarm Power On disabled, USB Power delivery in S5 disabled — all already disabled
8. pmset — powernap=0, womp=0, tcpkeepalive=0 — no effect on shutdown behavior

Key observation​

The SSDT-SPTSFIX approach correctly loads and executes — the rename SPTS→XPTS works, the new SPTS calls XPTSand then sets PWDE = Zero. However the reboot still occurs, suggesting that PWDE is either not the sole trigger, or the AGESA acts on it before our ACPI override can clear it, or the wake event is triggered at a lower level than ACPI can reach.

Question​

Has anyone found a working solution for this specific issue on B650/X670 with AGESA 1.2.x or 1.3.x?

Is this truly only fixable via BIOS mod patching the AGESA binary directly?

Any help appreciated!

 

[Jumper981]

I also have this problem on my X670 after BIOS 1.30, did you find the cause?

 

[errevi]

I also have this problem on my X670 after BIOS 1.30, did you find the cause?

The evidence indicates that macOS is successfully requesting S5 and entering shutdown, but the AMD firmware/AGESA immediately asserts a wake or power-on event afterward. The fact that Windows and Linux shut down correctly strongly suggests they are following a different firmware path, setting different PMC/SMU state, or triggering different ACPI branches. At this point the problem looks much more like an AGESA/firmware incompatibility exposed by macOS than a macOS shutdown failure itself.
I have just updated BIOS to version 4.41 with new AGESA 1.3.0.1b, same problem, furthermore after BIOS update isn't waking from sleep properly and I need to investigate why (maybe USB ports or MMIO addresses have changed)

 

[Jumper981]

This is everything i’ve tried so far.

 

[etorix]

@errevi You have posted the ACPI tables but not the EFI folder you're using. In the spirit of the International Journal of Negative Results, even failed SSDTs could be interesting to analyse.

Are you using custom ACPI patches, such as those provided on request by CorpGhost? If not, you may try this set of three patches to (re)enable a few conditional ACPI devices which are not properly created under macOS.

 

[errevi]

@errevi You have posted the ACPI tables but not the EFI folder you're using. In the spirit of the International Journal of Negative Results, even failed SSDTs could be interesting to analyse.

Are you using custom ACPI patches, such as those provided on request by CorpGhost? If not, you may try this set of three patches to (re)enable a few conditional ACPI devices which are not properly created under macOS.

@etorix Thanks for your interest in the matter, here's my EFI if you want to take a look

 

[etorix]

You're welcome. So I see you are not using motherboard-specific patches for the conditional device declarations, so you may try my almost-generic patches above ("MSI" version).
I don't know if that alone will fix the ghost reboot issue, but it should improve how macOS sees the USB controllers and other devices hanging from the B650. Windows and Linux are not affected because these OSes correctly read operational values (G0xx), correctly parse the conditional declarations and correctly initialises the devices thereunder.

 

[errevi]

@etorix I have just tested your patches, after cleaning nvram, but unfortunately it still restart instead of shutdown.
At this point i do not know what else to try, thanks for your time, appreciated!

 

[etorix]

OK. At least, I infer that it still boots with my patches. And this has provided two more motherboards to my records, which has eventually prompted me to write a better explanation.

Do the patches affect USB behaviour, or other devices? (@Jumper981 reported that he had to modify the RTL812x kext…)
Is this with or without the acpi-wake properties and GPRW/PWDE patches?

 

[errevi]

@etorix usb or other device seems to be unaffected, regarding your patches I have just added them to my configuration without touching anything else

 

[etorix]

Browsing through your configuration (keep in mind I'm no expert…) I wonder what the GPRW and PWDE patches are doing, as there's no SSDT which use the renamed functions.
Based on the comments, the USB map appears to feature logical HS ports with type 0 and SS ports with type 3 for the same physical ports. These should all be 3. 0 is for pure USB 2 ports.

 

[errevi]

@etorix: sorry for very late reply, I've finally had some time to check your suggestions and :

• removed the 2 patches (GPRW and PWDE), you are right, they were actually doing nothing
• reverted to BIOS 4.20, sleep and wake work again now
• added your 3 patches
• changed the logical HS ports with type 0 to type 3
• nvram reset
• tested a shutdown from opencore picker: it works correctly
• tested a shutdown from recovery: same restart instead of shutdown
• tested a shutdown from os: same restart instead of shutdown

I think I have now try everything I could imagine

 

[leesurone]

@etorix: sorry for very late reply, I've finally had some time to check your suggestions and :

• removed the 2 patches (GPRW and PWDE), you are right, they were actually doing nothing
• reverted to BIOS 4.20, sleep and wake work again now
• added your 3 patches
• changed the logical HS ports with type 0 to type 3
• nvram reset
• tested a shutdown from opencore picker: it works correctly
• tested a shutdown from recovery: same restart instead of shutdown
• tested a shutdown from os: same restart instead of shutdown

I think I have now try everything I could imagine

Hi @errevi . Glad you got your ACPI SSDTs files worked out. Now that you have that settled you need to take another run at USB Port Mapping which is usually the cause of a reboot on shutdown. I have lost count on how many times that same issue has been reported, not just here but on other Hackintosh sites, and how many times I’ve seen an answer like this posted to resolve the issue.

The solution is to first understand how various types of USB ports should be mapped. You can use the guide below, I stole from Ed Hawk, to work off of being aware that each USB 3 and each USBc port has two ports to identify. Both have an HS0 port and an S0 port and both need to be mapped as the same type. If it is a USB3 then both the HS0 and S0 ports are labeled as type 3. If it is a USBc then both are labeled as type 9 or sometimes, and less commonly, as type 10.

Starting there then it’s necessary to spend time to correctly identify which ports you want, what type they are before you create the kext. Once that’s done then you will have trouble shoot the end result to make sure your devices work as anticipated, the machine sleeps and waked properly and it shuts down instead of reboot. It’s rare a first effort is 100% correct and tweaks to the kext often need to be made. I usually use a plist editor to open the kext and make changes.

I can see from your port map labeling you seem to have USB3 ports mapped as both type 0 and type 3, that is incorrect. You also seem to be missing the HS0 part of your USBc ports which is also incorrect. If you can straighten that out its very likely your reboot issue will be corrected. Good Luck!


Courtesy of Ed Hawk



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.