surenmunoo Posted January 27, 2023 Share Posted January 27, 2023 Hey Guys, Anyone on here have an Z690 Aero D latest EFI. I have sleep issues where my Hack sleeps but does not wake via usb and when I press the power button once to wake it, it reboots. Not sure if IOReg would help identify what I have on this system but my case is an iCue 5000T with commander core that is connected to an internal usb header, the front usb ports on the case is connected to the 2 x usb 3.2 headers at the front of the MB. Link of my case if it helps as well. Sleep works both in Monterey and Ventura but same issue on wake. https://www.pbtech.co.nz/product/CHACOR05031/Corsair-iCUE-5000T-RGB-White-ATX-Mid-Tower-Gaming?qr=GShopping&gclid=Cj0KCQiAic6eBhCoARIsANlox871X3HOt8D-2c76MwB9WLzoJHcNknWB07-NBbyzH0yiWDwQQKKcWWMaAoeXEALw_wcB Efi attached EFI.zip IOReg attached 1711243789_MacPro.ioreg Link to comment Share on other sites More sharing options...
eSaF Posted January 27, 2023 Share Posted January 27, 2023 @surenmunoo - Bro that is possibly a USB issue. Plug out all your non essential USB's one at a time and test to find the culprit. I would hazard a guess it is the iCue module that is causing the problem. I have the Cooler Master equivalent and it behaves exactly the same way on the OS X side but fine on Windows and since I spend more time on OS X, once it was setup on Windows, I removed the USB connection and lived with it as such. I don't know about yours, but you can't control it inside OS X anyway, I let the motherboard control the fan speeds and pretty lights. I dare say you can cater the SSDT and hunt down a fix but I can't be a$$ed to be faffing around for something as trivial when another easier option is available, maybe one day when I am bored I will have a tinker but not a priority at the moment. 1 Link to comment Share on other sites More sharing options...
surenmunoo Posted January 27, 2023 Author Share Posted January 27, 2023 7 hours ago, eSaF said: @surenmunoo - Bro that is possibly a USB issue. Plug out all your non essential USB's one at a time and test to find the culprit. I would hazard a guess it is the iCue module that is causing the problem. I have the Cooler Master equivalent and it behaves exactly the same way on the OS X side but fine on Windows and since I spend more time on OS X, once it was setup on Windows, I removed the USB connection and lived with it as such. I don't know about yours, but you can't control it inside OS X anyway, I let the motherboard control the fan speeds and pretty lights. I dare say you can cater the SSDT and hunt down a fix but I can't be a$$ed to be faffing around for something as trivial when another easier option is available, maybe one day when I am bored I will have a tinker but not a priority at the moment. Thanks eSaF, I am also guessing it is the iCue causing the issue. My fan pins are different to the MB RGB pins and I cannot find converters so I have to use the Commander to set RGB lights. 1 Link to comment Share on other sites More sharing options...
surenmunoo Posted January 29, 2023 Author Share Posted January 29, 2023 On 1/27/2023 at 11:34 PM, eSaF said: @surenmunoo - Bro that is possibly a USB issue. Plug out all your non essential USB's one at a time and test to find the culprit. I would hazard a guess it is the iCue module that is causing the problem. I have the Cooler Master equivalent and it behaves exactly the same way on the OS X side but fine on Windows and since I spend more time on OS X, once it was setup on Windows, I removed the USB connection and lived with it as such. I don't know about yours, but you can't control it inside OS X anyway, I let the motherboard control the fan speeds and pretty lights. I dare say you can cater the SSDT and hunt down a fix but I can't be a$$ed to be faffing around for something as trivial when another easier option is available, maybe one day when I am bored I will have a tinker but not a priority at the moment. So I removed all usb devices connected to internal usb headers and the system goes to sleep but cannot wake from usb keyboard and when I press the power button once to wake it, it reboots the PC. Link to comment Share on other sites More sharing options...
eSaF Posted January 29, 2023 Share Posted January 29, 2023 On all my previous Gigabyte boards when the machine went into Sleep mode, all it took to wake it was a keyboard input or mouse movement. On this MSI board when it goes into Sleep Mode, the aRGB led goes off and the power button continuously blinks, no amount of keyboard or mouse input will induce Wake. Wake is activated by a push of the Power Button and goes back to the Desktop or the last open Window not a reboot as you described. I have tried to induce the same Sleep behaviour as the Gigabyte boards but couldn't, I noticed the various Wake Event Settings in the BIOS that includes keyboard/Mouse Wake options is greyed out, why I don't know so at the moment the only way to wake the machine is via the Power Button. I have tried different methods like adding the wake kext along with an SSDT entry but the result remains unchanged. 1 Link to comment Share on other sites More sharing options...
deeveedee Posted January 29, 2023 Share Posted January 29, 2023 (edited) @surenmunoo You have an ACPI patch that renames _PRW -> XPRW. You also have SSDT-USBW.aml that redefines USBW._PRW to Return (\_SB.PC00.XHCI._PRW ()). I'm not familiar with. your rig's ACPI, so forgive a possible mistaken conclusion, but are you certain that this patch strategy is correct? OC performs ACPI > Patches before ACPI > Adds, so your _PRW->XPRW rename occurs before your SSDT-USBW is loaded (and it renames ALL occurrences of _PRW in your rig's ACPI). Where is defined \_SB.PC00.XHCI._PRW () that you reference in SSDT-USBW? If you rename the USB _PRW methods and don't define new ones, this could definitely affect your rig's ability to wake on a USB event. Edited January 29, 2023 by deeveedee Link to comment Share on other sites More sharing options...
surenmunoo Posted January 29, 2023 Author Share Posted January 29, 2023 1 hour ago, deeveedee said: @surenmunoo You have an ACPI patch that renames _PRW -> XPRW. You also have SSDT-USBW.aml that redefines USBW._PRW to Return (\_SB.PC00.XHCI._PRW ()). I'm not familiar with. your rig's ACPI, so forgive a possible mistaken conclusion, but are you certain that this patch strategy is correct? OC performs ACPI > Patches before ACPI > Adds, so your _PRW->XPRW rename occurs before your SSDT-USBW is loaded (and it renames ALL occurrences of _PRW in your rig's ACPI). Where is defined \_SB.PC00.XHCI._PRW () that you reference in SSDT-USBW? If you rename the USB _PRW methods and don't define new ones, this could definitely affect your rig's ability to wake on a USB event. Should I remove that rename in ACPI? I just keep copying my settings as I progressed to upgrade OC. Link to comment Share on other sites More sharing options...
deeveedee Posted January 29, 2023 Share Posted January 29, 2023 (edited) I don't have your original ACPI, so I can't really advise. If you can extract and post your original ACPI (probably only need the original, unpatched DSDT), I can be more helpful. EDIT: You have other _PRW definitions that may result in an ACPI patching conflict if you remove the XPRW rename patch. When you post your original ACPI, it would also help if you can explain your ACPI patching strategy for USB. Edited January 29, 2023 by deeveedee Link to comment Share on other sites More sharing options...
surenmunoo Posted January 29, 2023 Author Share Posted January 29, 2023 (edited) 20 minutes ago, deeveedee said: I don't have your original ACPI, so I can't really advise. If you can extract and post your original ACPI (probably only need the original, unpatched DSDT), I can be more helpful. Will this be it, I rebooted again and generated a fresh report, I use a USBPort.kext which I generated from Hackintool after mapping the usb ports. SysReport.zip Edited January 29, 2023 by surenmunoo Link to comment Share on other sites More sharing options...
deeveedee Posted January 30, 2023 Share Posted January 30, 2023 @surenmunoo I was referring to your USB ACPI patching strategy (your ACPI Patches and Adds in your config.plist), not your USBPorts.kext strategy, but that's ok. I was just curious how you determined that you needed the USB ACPI patches in your OC config.plist. If you correctly extracted your original ACPI and you are certain that you need your SSDT-USBW patch, then in order for you to make that patch work, remember that your _PRW->XPRW rename (in your OC config.plist) applies to ALL instances of _PRW in your original (unpatched) ACPI. This means that if you want to reference the original XHCI._PRW, you need to reference it as XHCI.XPRW in your SSDT-USBW. I don't know whether you actually need the patch and I have no way of determining that without studying and experimenting with your rig (which I don't have), but I can tell you that if you really do need SSDT-USBW, then change _PRW to XPRW in your SSDT-USBW: External (_SB_.PC00.XHCI._PRW, MethodObj) External (_SB_.PC00.XHCI.XPRW, MethodObj) Device (\_SB.USBW) { Name (_HID, "PNP0D10" /* XHCI USB Controller with debug */) // _HID: Hardware ID Name (_UID, "WAKE") // _UID: Unique ID Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake { Return (\_SB.PC00.XHCI._PRW ()) Return (\_SB.PC00.XHCI.XPRW ()) } } Link to comment Share on other sites More sharing options...
deeveedee Posted January 30, 2023 Share Posted January 30, 2023 @surenmunoo If you want to see why you need to reference the renamed XPRW, run MaciASL and select File > New from ACPI > DSDT as shown below. This will load your patched DSDT to show you how Open Core has applied your ACPI renames (the ACPI > Patches in your config.plist). Search for Device (XHCI) and observe that XHCI._PRW has been renamed to XHCI.XPRW. MaciASL: File > New from ACPI > DSDT Spoiler Link to comment Share on other sites More sharing options...
surenmunoo Posted January 30, 2023 Author Share Posted January 30, 2023 1 hour ago, deeveedee said: @surenmunoo I was referring to your USB ACPI patching strategy (your ACPI Patches and Adds in your config.plist), not your USBPorts.kext strategy, but that's ok. I was just curious how you determined that you needed the USB ACPI patches in your OC config.plist. If you correctly extracted your original ACPI and you are certain that you need your SSDT-USBW patch, then in order for you to make that patch work, remember that your _PRW->XPRW rename (in your OC config.plist) applies to ALL instances of _PRW in your original (unpatched) ACPI. This means that if you want to reference the original XHCI._PRW, you need to reference it as XHCI.XPRW in your SSDT-USBW. I don't know whether you actually need the patch and I have no way of determining that without studying and experimenting with your rig (which I don't have), but I can tell you that if you really do need SSDT-USBW, then change _PRW to XPRW in your SSDT-USBW: External (_SB_.PC00.XHCI._PRW, MethodObj) External (_SB_.PC00.XHCI.XPRW, MethodObj) Device (\_SB.USBW) { Name (_HID, "PNP0D10" /* XHCI USB Controller with debug */) // _HID: Hardware ID Name (_UID, "WAKE") // _UID: Unique ID Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake { Return (\_SB.PC00.XHCI._PRW ()) Return (\_SB.PC00.XHCI.XPRW ()) } } Not sure if I really need it, I only put it in because I was told on another forum that it helps with wake from sleep via USB but it does not seem to help. Link to comment Share on other sites More sharing options...
deeveedee Posted January 30, 2023 Share Posted January 30, 2023 @surenmunoo Your current SSDT-USBW patch is not doing anything. You need to make the changes that I indicated (use XPRW) and then test to know whether the patch helps you. Link to comment Share on other sites More sharing options...
surenmunoo Posted January 30, 2023 Author Share Posted January 30, 2023 59 minutes ago, deeveedee said: @surenmunoo Your current SSDT-USBW patch is not doing anything. You need to make the changes that I indicated (use XPRW) and then test to know whether the patch helps you. Will try that, thanks Link to comment Share on other sites More sharing options...
surenmunoo Posted January 30, 2023 Author Share Posted January 30, 2023 1 hour ago, deeveedee said: @surenmunoo Your current SSDT-USBW patch is not doing anything. You need to make the changes that I indicated (use XPRW) and then test to know whether the patch helps you. I have done the changes, now to test Link to comment Share on other sites More sharing options...
surenmunoo Posted January 30, 2023 Author Share Posted January 30, 2023 1 hour ago, deeveedee said: @surenmunoo Your current SSDT-USBW patch is not doing anything. You need to make the changes that I indicated (use XPRW) and then test to know whether the patch helps you. It goes to sleep but wakes on its own after 2 seconds to a full PC reboot. I get this error when it logs back into MacOS. panic(cpu 1 caller 0xffffff7f8fa61098): "[3:0:0][PPLIB] Failed Power Play Resume. Shutting back down. " @AmdRadeonController.cpp:2010 Panicked task 0xffffff9049841208: 315 threads: pid 0: kernel_task Backtrace (CPU 1), panicked thread: 0xffffff9513b0a0c8, Frame : Return Address 0xffffffe84985b820 : 0xffffff80029eb38d mach_kernel : _handle_debugger_trap + 0x4ad 0xffffffe84985b870 : 0xffffff8002b58ed6 mach_kernel : _kdp_i386_trap + 0x116 0xffffffe84985b8b0 : 0xffffff8002b48120 mach_kernel : _kernel_trap + 0x3e0 0xffffffe84985b900 : 0xffffff8002985951 mach_kernel : _return_from_trap + 0xc1 0xffffffe84985b920 : 0xffffff80029eb66d mach_kernel : _DebuggerTrapWithState + 0x5d 0xffffffe84985ba10 : 0xffffff80029ead19 mach_kernel : _panic_trap_to_debugger + 0x1a9 0xffffffe84985ba70 : 0xffffff80031e072b mach_kernel : _panic + 0x84 0xffffffe84985bb60 : 0xffffff7f8fa61098 com.apple.kext.AMDRadeonX6000Framebuffer : __ZN34AMDRadeonX6000_AmdRadeonController10doGPUPanicEPKcz + 0x1c0 0xffffffe84985bc70 : 0xffffff7f8fa2364c com.apple.kext.AMDRadeonX6000Framebuffer : __ZN33AMDRadeonX6000_AmdPowerPlayHelper4wakeEv + 0xc0 0xffffffe84985bcb0 : 0xffffff7f8fa608ca com.apple.kext.AMDRadeonX6000Framebuffer : __ZN34AMDRadeonX6000_AmdRadeonController4wakeEv + 0xa4 0xffffffe84985bce0 : 0xffffff7f8fa43993 com.apple.kext.AMDRadeonX6000Framebuffer : __ZN35AMDRadeonX6000_AmdRadeonFramebuffer6doWakeEv + 0x5b 0xffffffe84985bd00 : 0xffffff7f8fa438cf com.apple.kext.AMDRadeonX6000Framebuffer : __ZN35AMDRadeonX6000_AmdRadeonFramebuffer19setSystemPowerStateENS_15AmdFbPowerStateE + 0x1f 0xffffffe84985bd20 : 0xffffff7f8fa436d1 com.apple.kext.AMDRadeonX6000Framebuffer : __ZN35AMDRadeonX6000_AmdRadeonFramebuffer18doPowerStateChangeENS_15AmdFbPowerStateE + 0x43 0xffffffe84985bd50 : 0xffffff7f988871ff com.apple.iokit.IOGraphicsFamily : __ZN13IOFramebuffer14checkPowerWorkEj + 0x27d 0xffffffe84985bdf0 : 0xffffff7f98886f64 com.apple.iokit.IOGraphicsFamily : __ZN14IOFBController14checkPowerWorkEj + 0xa0 0xffffffe84985be20 : 0xffffff7f9888e0d0 com.apple.iokit.IOGraphicsFamily : __ZN13IOFramebuffer10systemWorkEP8OSObjectP22IOInterruptEventSourcei + 0x124 0xffffffe84985bed0 : 0xffffff80031144b4 mach_kernel : __ZN22IOInterruptEventSource12checkForWorkEv + 0x114 0xffffffe84985bf20 : 0xffffff8003112dae mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x12e 0xffffffe84985bf60 : 0xffffff80031123e7 mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x37 0xffffffe84985bfa0 : 0xffffff800298519e mach_kernel : _call_continuation + 0x2e Kernel Extensions in backtrace: com.apple.iokit.IOGraphicsFamily(597.0)[5ABF1ED9-18B9-3062-8621-5ED1B70959BD]@0xffffff7f9887b000->0xffffff7f988a9fff dependency: com.apple.iokit.IOPCIFamily(2.9)[9367C7B9-149B-329D-B085-39BC7D39EF03]@0xffffff8005459000->0xffffff8005488fff com.apple.kext.AMDRadeonX6000Framebuffer(4.0.9)[C4AE7C14-A015-374F-9FA6-5BBB16E599BD]@0xffffff7f8fa12000->0xffffff7f8fc9bfff dependency: com.apple.AppleGraphicsDeviceControl(7.1.18)[DB321B04-5254-3878-8C56-730905ADB792]@0xffffff7f977c6000->0xffffff7f977c9fff dependency: com.apple.iokit.IOACPIFamily(1.4)[7B82417D-1B41-324A-8B06-22FD04EB13ED]@0xffffff8004fea000->0xffffff8004febfff dependency: com.apple.iokit.IOGraphicsFamily(597)[5ABF1ED9-18B9-3062-8621-5ED1B70959BD]@0xffffff7f9887b000->0xffffff7f988a9fff dependency: com.apple.iokit.IOPCIFamily(2.9)[9367C7B9-149B-329D-B085-39BC7D39EF03]@0xffffff8005459000->0xffffff8005488fff Process name corresponding to current thread (0xffffff9513b0a0c8): kernel_task Boot args: -v alcid=12 watchdog=0 agdpmod=pikera dk.e1000=0 e1000=0 swd_panic=1 keepsyms=1 revpatch=auto,sbvmm,asset Mac OS version: 22D49 Kernel version: Darwin Kernel Version 22.3.0: Thu Jan 5 20:53:49 PST 2023; root:xnu-8792.81.2~2/RELEASE_X86_64 Kernel UUID: 4AD8D60C-F454-330F-B4A6-1CB012B5D0D3 roots installed: 0 KernelCache slide: 0x0000000002600000 KernelCache base: 0xffffff8002800000 Kernel slide: 0x00000000026dc000 Kernel text base: 0xffffff80028dc000 __HIB text base: 0xffffff8002700000 System model name: MacPro7,1 (Mac-27AD2F918AE68F61) System shutdown begun: NO Panic diags file available: YES (0x0) Hibernation exit count: 0 System uptime in nanoseconds: 180429767728 Last Sleep: absolute base_tsc base_nano Uptime : 0x0000002a0273c598 Sleep : 0x00000029ce7f0599 0x0000001d821a79f9 0x0000000000000000 Wake : 0x00000029fd4d56c5 0x00000002c9f69048 0x00000029f6821052 Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space Zone info: Zone map: 0xffffff80458f8000 - 0xffffffa0458f8000 . PGZ : 0xffffff80458f8000 - 0xffffff804d8f9000 . VM : 0xffffff804d8f9000 - 0xffffff8519292000 . RO : 0xffffff8519292000 - 0xffffff86b25c5000 . GEN0 : 0xffffff86b25c5000 - 0xffffff8b7df5e000 . GEN1 : 0xffffff8b7df5e000 - 0xffffff90498f7000 . GEN2 : 0xffffff90498f7000 - 0xffffff9515290000 . GEN3 : 0xffffff9515290000 - 0xffffff99e0c2a000 . DATA : 0xffffff99e0c2a000 - 0xffffffa0458f8000 Metadata: 0xfffffff019266000 - 0xfffffff039266000 Bitmaps : 0xfffffff039266000 - 0xfffffff051266000 Link to comment Share on other sites More sharing options...
deeveedee Posted January 30, 2023 Share Posted January 30, 2023 (edited) I don't know why the change would result in a graphics kernel panic - possibly because the instant wake happens while graphics is still trying to sleep. I don't know your ACPI patching strategy, so I don't understand why you're renaming all _PRW -> XPRW and I don't know why someone would suggest that you need to define Device USBW. If I were hacking your board from scratch, I would remove your _PRW->XPRW rename and I would remove your SSDT-USBW and I would follow this to address the "instant wake." If you don't want to determine your required ACPI patches, I would suggest finding someone who has successfully hacked your motherboard with working sleep / wake and ask them for their EFI. Good luck with your hack. Sorry I wasn't able to help you. EDIT: I did find this which explains the use of USBW. It looks to me that USBW is solving a different problem than what you have. From the description, defining Device USBW is necessary when your system requires more than one keyboard/mouse event to wake the display. Edited January 30, 2023 by deeveedee Link to comment Share on other sites More sharing options...
surenmunoo Posted January 30, 2023 Author Share Posted January 30, 2023 4 hours ago, deeveedee said: I don't know why the change would result in a graphics kernel panic - possibly because the instant wake happens while graphics is still trying to sleep. I don't know your ACPI patching strategy, so I don't understand why you're renaming all _PRW -> XPRW and I don't know why someone would suggest that you need to define Device USBW. If I were hacking your board from scratch, I would remove your _PRW->XPRW rename and I would remove your SSDT-USBW and I would follow this to address the "instant wake." If you don't want to determine your required ACPI patches, I would suggest finding someone who has successfully hacked your motherboard with working sleep / wake and ask them for their EFI. Good luck with your hack. Sorry I wasn't able to help you. EDIT: I did find this which explains the use of USBW. It looks to me that USBW is solving a different problem than what you have. From the description, defining Device USBW is necessary when your system requires more than one keyboard/mouse event to wake the display. Thanks for your efforts mate Link to comment Share on other sites More sharing options...
Recommended Posts