Need Help Fixing Wake on the HP Elitebook 850 G7

[deeveedee]

This thread might be short (hopefully) or may never conclude (hopefully not).  I have an HP Elitebook 850 G7 running Sequoia.  Everything that I have configured / tested works except for waking from sleep as described below.  Things I haven't yet configured / tested are listed below.  I won't address these until wake is fixed.

 

The hack boots quickly and sleeps flawlessly.  I have read posts in other forums stating that the HP Elitebook G7 series does not properly implement  Power State S3, but I'm hoping that's not the case.  I have inspected ACPI and don't find any evidence that S3 isn't handled properly in ACPI.  I'm considering a brute force debugging effort that inserts debugging statements in ACPI, but I'm hoping to avoid that tedious process.

 

My partial Open Core OC folder is attached (containing only the config.plist and ACPI patches).  Note that the attached OC folder is old and is missing many of my latest updates for full functionality.

 

Sleep / Wake behavior

• laptop sleeps normally when idle, when lid closes and when manually put to sleep
• On wake, laptop spends what seems like several minutes (haven't timed it) waking, where USB devices eventually wake and then the internal screen eventually wakes, but internal PS2 keyboard does not work after wake.  IORegistry appears to show normal entries for ApplePS2Controller after wake.  Keyboard backlight does work when a key is pressed after sleep.
• If I connect a USB keyboard, everything (except internal PS2 keyboard) appears to be working normally after waking from sleep.
• Internal I2C Trackpad works fine after wake

 

I suspect that the long wake time prevents VoodooPS2Controller from re-initializing PS2.  There is a 'WakeDelay' parameter in VoodooPS2Controller's Info.plist, but I haven't experimented with it and think the real problem is that the laptop just takes soooooo long to wake.

 

My system specs are as follows

• HP Elitebook 850 G7
• Intel i7-10610U
• 32 GB RAM
• Western Digital WD Black SN750 NVMe SSD

 

Test status

• Wake not working because EC is not available before _WAK method is called.  Currently have sleep disabled until I figure this out (sudo pmset -a disablesleep 1)
• Brightness keys work perfectly (without pressing Function key) with a simple ACPI patch (no additional kexts).
• Battery status works perfectly with ECEnabler.kext (no ACPI patches required)
• Thunderbolt not yet configure/ tested
• internal, HDMI-connected and USB-C-connected displays work simultaneously (or internal display alone).  External displays are hot-pluggable.  HDMI audio works well in Monterey and Sequoia.
• I read somewhere that internal trackpad buttons do not work without VoodooRMI.kext, but I haven't tested.
• Internal Mic does not work
• Headset / Mic jack works fine and is a very acceptable alternative to the internal Mic in Monterey and Sequoia.
• Intel Wi-Fi works well with OpenWireless itlwm / Heliport
• Intel Bluetooth works well with OpenWireless IntelBluetooth kexts (including Bluetooth audio)
• Power management is outstanding with long battery life and silent fan
• Working touchscreen

 

EDIT: There's another InsanelyMac thread here which appears to be attempting to solve the same problem.  I didn't find that thread in my initial searches.

OC.zip

Edited November 23, 2025 by deeveedee

[deeveedee]

*** Reserved ***

Edited October 10, 2025 by deeveedee

[deeveedee]

*** Reserved ***

[deeveedee]

EDIT: Using debug tracing in ACPI, I have confirmed that the problem I observed below was caused by MaciASL and not by Open Core (not surprised).  The GPRW->XPRW ACPI patch works, but when MaciASL is use to view the patched DSDT (using MaciASL: File > New from ACPI), MaciASL displays the patch incorrectly.  I am leaving my current patch which replaces each _PRW with XPRW, but GPRW -> XPRW would have worked fine, too.

 

----------------------------------------------------------------------------------------------

 

Some who have experience with ACPI patches for this and other laptop hacks will noticed that my "GPRW" ACPI patch does not rename Method \GPRW to XPRW.  Instead, my patches rename each of the affected _PRW (0x6D, ...)  methods to XPRW.  This is because when I implemented the GPRW -> XPRW patch, the patch was "breaking" the DSDT.  The new GPRW method that I added was being referenced in the DSDT as External IntObj (not External MethodObj).  I didn't know if this was an actual problem with the patched DSDT or a problem with MaciASL.  To be safe, I just took the brute force approach and abandoned the GPRW -> XPRW rename in favor of patching the individual _PRW methods.

 

Also, note that I have a separate ACPI patch for XHC._PRW.  This is because XHC._PRW does not use method GPRW.

Edited November 11, 2025 by deeveedee

[deeveedee]

I have isolated the cause of the wake problem with the HP EliteBook 850 G7.   I'm currently examining one line of ACPI code.  Since it appears that no one else is interested in this solution, I'm going to examine and attempt to fix this myself, since it will be faster for me instead of documenting my debugging steps here.

 

Based on what I'm seeing, I'm not surprised that this hasn't been solved (not because it's not solvable, but because I'd never have found the problem without Rehabman's ACPI Debug tool).  I doubt many still use it (a very valuable tool).

 

Edited October 14, 2025 by deeveedee

[deeveedee]

Solving wake is going to require expertise from others more knowledgeable than me.

 

After reviewing ACPI and detailed ACPI debug tracing (using Rehabman's RMDT), I have concluded that the Embedded Controller (EC) is not waking after sleep and before calling the _WAK method.  _WAK expects EC to be available and _WAK hangs when EC is not available.  Apparently, Windows and Linux are waking EC with a driver call before _WAK.

 

One possible fix might be a kext that "tickles" EC on wake, so that EC is available for _WAK.

 

I'm open to any suggestions.  For now, I'll use this laptop with 'sudo pmset -a disablesleep 1'

 

EDIT: _WAK hangs with a call to HWAK which makes other calls that eventually attempt to read/write EC FieldUnitObjects.  It is the first access of EC FieldUnitObjects that hangs (because EC is not available).  _WAK execution halts and never completes.  The laptop eventually "wakes" after a few minutes without ever completing / exiting _WAK and without a working EC.  After wake, display, USB ports and trackpad all work (so laptop is perfectly usable with an external USB keyboard).  Internal PS2 keyboard is not available after wake.

 

Note that I performed a test that bypassed the call to HWAK in _WAK (to allow _WAK to complete and exit), but the laptop reboots instead of waking. I also unsuccessfully  attempted to wake EC with a Notify (EC, 0x80) call at the beginning of _WAK, but EC did not respond.

 

Pinging @Slice @laobamac_yyds @etorix @joevt @Avery B @mhaeuser @headkaze who have been helpful with advanced topics before in case you have suggestions.  Thank you.

 

EDIT2: The unpatched DSDT is attached.

DSDT.aml.zip

Edited November 15, 2025 by deeveedee

[Avery B]

I don't have any fixes off the top of my head - I know there are various acpi_layer and acpi_level bootargs you can play around with. First call is probably grabbing logs to see if the EC is dying/erroring out. 

FYI, your ACPI has a bunch of prints already. "acpi_layer=0x08 acpi_level=0x02" should allow Debug = "" statements in the ACPI to print out to the console/dmesg/log command. Some examples being:

External (\OSYS, IntObj)

Method (_INI, 0, NotSerialized)
{
  Debug = "Entering \_INI!" // Prints "Entering \INI!" // Prints "[ACPI Debug] Entering \INI!"
  Debug = "Hello World!" // Prints "Hello World!" // Prints "[ACPI Debug] Hello World!"
  Debug = Concatenate ("OSYS is equal to: ", \OSYS) // Prints "[ACPI Debug] OSYS is equal to: 0x7DC"
}

// I noticed that your ACPI has calls to ADGB which eventually calls into MDBG. Could do something like this to get those all to print out:
Method (MDGB, 1, NotSerialized)
{
  Debug = Arg0
  Return (Zero)
}

I know there were acpi_level and acpi_layer values that tells AppleAcpiEc to spam out logs for every transaction. If I can find those again, I'll post them in this thread.

[deeveedee]

Thank you, @Avery B.  I'm using Rehabman's RMDT kext and ACPI functions to create detailed ACPI traces.  By placing RMDT trace statements in ACPI, I'm following ACPI function entry and exit, milestones, variable values, etc.  Very detailed.  I could post trace logs, but they would simply show that the _WAK method halts at the first attempt to access EC FieldUnitObjects.

 

EDIT: @Avery B Here's a trace during laptop startup just to give you an idea.  I run the traces in macOS Monterey 12.7.6 with SIP fully disabled.

 

Spoiler

2025-10-22 22:55:00.243449-0400 0x62e      kernel: (ACPIDebug) ACPIDebug::init: Initializing
2025-10-22 22:55:00.243461-0400 0x62e      kernel: (ACPIDebug) ACPIDebug::probe: Probing
2025-10-22 22:55:00.243483-0400 0x62e      kernel: (ACPIDebug) ACPIDebug::start: called
2025-10-22 22:55:00.243487-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: Version 0.1.4 starting on OS X Darwin 21.6.
2025-10-22 22:55:00.243698-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0._REG. Arg0:", 0x0, "  Arg1: ", 0x1, }
2025-10-22 22:55:00.243856-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Exiting EC0._REG"
2025-10-22 22:55:00.244011-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0._REG. Arg0:", 0x0, "  Arg1: ", 0x1, }
2025-10-22 22:55:00.244162-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Exiting EC0._REG"
2025-10-22 22:55:00.244308-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0._REG. Arg0:", 0x1, "  Arg1: ", 0x1, }
2025-10-22 22:55:00.244405-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Exiting EC0._REG"
2025-10-22 22:55:00.244501-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0._STA"
2025-10-22 22:55:00.244595-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0._INI"
2025-10-22 22:55:00.244697-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Exiting EC0._INI"
2025-10-22 22:55:00.244793-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0._STA"
2025-10-22 22:55:00.244918-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "EC0._PRW (Return 0x6F, 0x04)"
2025-10-22 22:55:00.245060-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0._STA"
2025-10-22 22:55:00.245175-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0._CRS"
2025-10-22 22:55:00.245259-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering Fake EC._STA"
2025-10-22 22:55:00.245342-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering Fake EC._STA"
2025-10-22 22:55:00.245425-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "XHC._PRW"
2025-10-22 22:55:00.245516-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "XDCI._PRW"
2025-10-22 22:55:00.245611-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "HDAS._PRW"
2025-10-22 22:55:00.245756-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering GPI0._STA.  GPHD = ", 0x0, }
2025-10-22 22:55:00.245934-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering GPI0._HID.  GPHD = ", 0x0, }
2025-10-22 22:55:00.246097-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering GPI0._STA.  GPHD = ", 0x0, }
2025-10-22 22:55:00.246247-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "CNVW._PRW"
2025-10-22 22:55:00.246400-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0._GPE"
2025-10-22 22:55:00.246681-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0._REG. Arg0:", 0x3, "  Arg1: ", 0x1, }
2025-10-22 22:55:00.246852-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0.EC0RI"
2025-10-22 22:55:00.247014-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0.PWUP. Arg0:", 0x7, ",  Arg1: ", 0xff, }
2025-10-22 22:55:00.247174-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Leaving EC0.PWUP. Arg0:", 0x7, ",  Arg1: ", 0xff, }
2025-10-22 22:55:00.247337-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0.ITLB"
2025-10-22 22:55:00.247511-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "EC0.ITLB: Waiting 200ms (100ms not enough during initial startup)"
2025-10-22 22:55:00.247655-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Leaving EC0.ITLB"
2025-10-22 22:55:00.247837-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Leaving EC0.EC0RI"
2025-10-22 22:55:00.248005-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Exiting EC0._REG"
2025-10-22 22:55:00.248154-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0._REG. Arg0:", 0x3, "  Arg1: ", 0x1, }
2025-10-22 22:55:00.248297-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0.EC0RI"
2025-10-22 22:55:00.248441-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0.PWUP. Arg0:", 0x7, ",  Arg1: ", 0xff, }
2025-10-22 22:55:00.248557-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Leaving EC0.PWUP. Arg0:", 0x7, ",  Arg1: ", 0xff, }
2025-10-22 22:55:00.248684-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0.ITLB"
2025-10-22 22:55:00.248903-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "EC0.ITLB: Waiting 200ms (100ms not enough during initial startup)"
2025-10-22 22:55:00.249020-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Leaving EC0.ITLB"
2025-10-22 22:55:00.249144-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Leaving EC0.EC0RI"
2025-10-22 22:55:00.249285-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Exiting EC0._REG"
2025-10-22 22:55:00.249411-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0._REG. Arg0:", 0x3, "  Arg1: ", 0x1, }
2025-10-22 22:55:00.249522-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0.EC0RI"
2025-10-22 22:55:00.249631-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0.PWUP. Arg0:", 0x7, ",  Arg1: ", 0xff, }
2025-10-22 22:55:00.249745-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: { "Leaving EC0.PWUP. Arg0:", 0x7, ",  Arg1: ", 0xff, }
2025-10-22 22:55:00.249877-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Entering EC0.ITLB"
2025-10-22 22:55:00.249984-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "EC0.ITLB: Waiting 200ms (100ms not enough during initial startup)"
2025-10-22 22:55:00.250097-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Leaving EC0.ITLB"
2025-10-22 22:55:00.250198-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Leaving EC0.EC0RI"
2025-10-22 22:55:00.250301-0400 0x62e      kernel: (ACPIDebug) ACPIDebug: "Exiting EC0._REG"
2025-10-22 22:55:07.397992-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:55:07.398175-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: "_Q09: Battery Level Change"
2025-10-22 22:55:07.398343-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:55:07.398499-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Leaving EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:55:07.398532-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:55:07.398562-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:55:32.023711-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:55:32.023857-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: "_Q09: Battery Level Change"
2025-10-22 22:55:32.024074-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:55:32.024290-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Leaving EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:55:32.024349-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:55:32.024376-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:55:34.411783-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:55:34.412036-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: "_Q09: Battery Level Change"
2025-10-22 22:55:34.412236-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:55:34.412443-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Leaving EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:55:34.412497-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:55:34.412534-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:56:01.605410-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:56:01.606016-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: "_Q09: Battery Level Change"
2025-10-22 22:56:01.606696-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:56:01.607188-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Leaving EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:56:01.607277-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:56:01.607345-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:57:23.178127-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:57:23.178743-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: "_Q09: Battery Level Change"
2025-10-22 22:57:23.179310-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Entering EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:57:23.179751-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug: { "Leaving EC0.PWUP. Arg0:", 0x4, ",  Arg1: ", 0x1, }
2025-10-22 22:57:23.179859-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 22:57:23.179931-0400 0x7a7      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)

 

 

Edited October 23, 2025 by deeveedee
Updated with the correct trace. I had accidentally inserted the wrong trace.

[Andres ZeroCross]

Just for test, how about Rename EC device to EX in from config.plist then create new EC device with SSDT. And give it a try

[deeveedee]

@Andres ZeroCross Thank you for the suggestion.  My OC EFI adds Fake Device (EC) in addition to the real Device (EC0).  If I force real EC0._STA to return zero, _WAK still hangs at the same location (the first attempt to access EC0 FieldUnitObjects:

 

2025-10-22 21:15:17.067586-0400 0x1238     kernel: (ACPIDebug) ACPIDebug: { "Entering _PTS.  Arg0: ", 0x3, }
2025-10-22 21:15:33.138603-0400 0x1238     kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 21:15:33.138954-0400 0x1238     kernel: (ACPIDebug) ACPIDebug: { "Entering _WAK.  Arg0: ", 0x3, }
2025-10-22 21:15:33.139243-0400 0x1238     kernel: (ACPIDebug) ACPIDebug: { "Entering HWAK.  Arg0: ", 0x3, }
2025-10-22 21:15:33.139449-0400 0x1238     kernel: (ACPIDebug) ACPIDebug: "Entering EC0.ITLB"

The result is that laptop wake is delayed (with black screen) for several minutes until the laptop finally wakes without PS2 keyboard functionality.

 

Instead of forcing EC0._STA = 0, I'll rename EC0 and report additional findings with an edit to this post.

 

EDIT: Note that with EC0._STA = 0x0F, _PTS finishes.  See the trace above to observe that with EC0._STA = 0, _PTS does not finish.

 

EDIT2: I altered _WAK to skip the call to HWAK (leaving EC0._STA = 0).  Now _WAK finishes (but without rebooting as is the case if I skip HWAK with EC0._STA=0x0F), but wake is still delayed (with black screen) and after waking, internal PS2 keyboard is still not functional).

Spoiler

2025-10-22 21:38:37.521677-0400 0x198      kernel: (ACPIDebug) ACPIDebug: { "Entering _PTS.  Arg0: ", 0x3, }
2025-10-22 21:38:53.596287-0400 0x198      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 21:38:53.596525-0400 0x198      kernel: (ACPIDebug) ACPIDebug: { "Entering _WAK.  Arg0: ", 0x3, }
2025-10-22 21:38:53.596749-0400 0x198      kernel: (ACPIDebug) ACPIDebug: { "Entering HWAK.  Arg0: ", 0x3, }
2025-10-22 21:38:53.596963-0400 0x198      kernel: (ACPIDebug) ACPIDebug: { "Exiting HWAK.  Arg0: ", 0x3, }
2025-10-22 21:38:53.597032-0400 0x198      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 21:38:53.597096-0400 0x198      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 21:38:53.665542-0400 0x198      kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 21:38:53.665788-0400 0x219      kernel: (ACPIDebug) ACPIDebug: { "Exiting _WAK.  Arg0: ", 0x3, }

 

 

EDIT3: @Andres ZeroCross I think you probably meant for me to set EC0._STA = 0 (as I did above).  Renaming EC0 -> ECX simply changes the device name without changing functionality.  Maybe I misunderstood your request to rename EC0 -> ECX.

 

EDIT4: Debug trace of sleep / wake after renaming EC0 -> ECX and ECX._STA=0x0F.  ECX continues to operate with same functionality as EC0.

Spoiler

2025-10-22 23:28:02.476369-0400 0x175c     kernel: (ACPIDebug) ACPIDebug: { "Entering _PTS.  Arg0: ", 0x3, }
2025-10-22 23:28:08.007239-0400 0x175c     kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 23:28:08.007827-0400 0x175c     kernel: (ACPIDebug) ACPIDebug: { "Leaving _PTS.  Arg0: ", 0x3, }
2025-10-22 23:28:24.015166-0400 0x175c     kernel: (ACPIDebug) ACPIDebug::message(-536707056, <private>, <private>)
2025-10-22 23:28:24.015490-0400 0x175c     kernel: (ACPIDebug) ACPIDebug: { "Entering _WAK.  Arg0: ", 0x3, }
2025-10-22 23:28:24.015800-0400 0x175c     kernel: (ACPIDebug) ACPIDebug: { "Entering HWAK.  Arg0: ", 0x3, }
2025-10-22 23:28:24.016101-0400 0x175c     kernel: (ACPIDebug) ACPIDebug: "Entering ECX.ITLB"

 

 

EDIT 5: @Andres ZeroCross I realized that I misread your EX rename suggestion, so I just tested it.  Renaming EC0 -> EX behaves the same as setting EC0._STA = 0 (as would be expected).  No change in wake behavior.  Thanks again for patiently suggesting options.

Edited October 26, 2025 by deeveedee

[Andres ZeroCross]

I found many hackintosher with cometlake-U notebook like 1xxxxU series got wake problem in hackintosh (Black screen when wake the notebook, Indicator LED and other is ON). Several people fix it by change SMBIOS model and add certain boot argument. I don't know if this will help.

[Andres ZeroCross]

8 hours ago, deeveedee said:

After reviewing ACPI and detailed ACPI debug tracing (using Rehabman's RMDT), I have concluded that the Embedded Controller (EC) is not waking after sleep and before calling the _WAK method.  _WAK expects EC to be available and _WAK hangs when EC is not available.  Apparently, Windows and Linux are waking EC with a driver call before _WAK.

Can you check "EC0" in IOREG after wake from Sleep?? in normally, you should see EC0 and EC (Fake Device form SSDT). If your statement above is true, then you should not see "EC0" in IOREG after wake

Edited October 23, 2025 by Andres ZeroCross

[deeveedee]

@Andres ZeroCross I can experiment with different SMBIOS (currently using MBP16,2).  Maybe a "Desktop" SMBIOS that isn't expecting function EC.

44 minutes ago, Andres ZeroCross said:

Can you check "EC0" in IOREG after wake from Sleep?? in normally, you should see EC0 and EC (Fake Device form SSDT). If your statement above is true, then you should not see "EC0" in IOREG after wake

I do see EC0 in IOReg after wake.  That's what's confusing.  EC0 is simply non-responsive after wake, but it does appear in IORegistry.

 

EDIT: Just to be clear, I see EC0 in IOReg after wake when I leave EC0._STA=0x0F.

 

EDIT2: The appearance of EC0 in IORegisty after wake might not be as strange as it appears.  EC0._STA always returns 0x0F.

Edited October 23, 2025 by deeveedee

[Andres ZeroCross]

How about your keyboard / touchpad in IOREG?? Like PS2K / KBD0. is it available too after wake from sleep?

AFAIK, battery percentage code is depend EC0 too. If you see in DSDT.aml, BAT0 or BAT1 have many codes to EC0. So if EC0 not responsive, then your battery percentage should be problem too

Edited October 23, 2025 by Andres ZeroCross

[deeveedee]

@Andres ZeroCross I'm collecting data / screenshots... Good questions.   I'll update this post with answers.  Note that I can use the laptop after wake if I have a USB keyboard attached.

 

EDIT: @Andres ZeroCross 

• Keyboard (ACPI Device PS2K) is in IOReg after wake, but the keyboard is not responsive.  I can use an external USB keyboard after wake.  Using VoodooPS2 2.3.7
• Touchpad is in IOReg after wake and is functional after wake.  Using VoodooI2C 2.9.1
• Battery status (and percentage) are available in Menu Bar after wake, but I don't see evidence that the percentage is updating (it's not decreasing while on battery).  Using ECEnabler 1.0.6.

 

The fact that battery percentage is not changing after wake suggests that EC0 battery functions are not responding (consistent with observed failed _WAK access to EC0 FieldUnitObjects).

 

Thank you for your excellent questions. Note that the ACPI path for PS2K is _SB.PCI0.LPCB.PS2K.  Device PS2K is not under EC0.  I'm not certain, but I believe it's possible that the non-functioning PS2 Keyboard has nothing to do with non-functioning EC0 and is simply because the laptop takes so long to wake that VoodooPS2 does not reinitialize the keyboard after wake.

Edited October 23, 2025 by deeveedee

[Andres ZeroCross]

Maybe you can upload IOREG Output before and after wake.

[Andres ZeroCross]

Long ago, i made config for "HP EliteBook 840 G7". It's cometlake Notebook with I2C Touchpad. The processor is Intel Core i7-10610U.

It has similar problems, got black screen after wake from sleep. But system wake normally if you plug HDMI Monitor after system wake. Maybe you can try it. Is it same behaviour or not.

[deeveedee]

9 hours ago, Andres ZeroCross said:

Maybe you can upload IOREG Output before and after wake.

Attached are IOReg dumps before sleep and after wake.  I diff'd the two and don't see anything that offers any clues.

 

9 hours ago, Andres ZeroCross said:

It has similar problems, got black screen after wake from sleep. But system wake normally if you plug HDMI Monitor after system wake. Maybe you can try it. Is it same behaviour or not.

I haven't been focused on the HDMI port. I'll try it and report back if it offers any clues.

ioreg-beforesleep.txt.zip ioreg-afterwake.txt.zip

[deeveedee]

@Andres ZeroCross Thanks for motivating me to patch my laptop framebuffer for working internal display and HDMI display.  The Framebuffer patch required a lot of trial and error and currently breaks the brightness control when HDMI is connected, but at least both displays work.

 

Unfortunately, sleep/wake behavior did not change with the HDMI-connected display.  Both the internal and HDMI displays wake properly (eventually, after several minutes), but ACPI debug trace showing that _WAK halts due to non-available EC is still the same.

[Andres ZeroCross]

5 hours ago, deeveedee said:

@Andres ZeroCross Thanks for motivating me to patch my laptop framebuffer for working internal display and HDMI display.  The Framebuffer patch required a lot of trial and error and currently breaks the brightness control when HDMI is connected, but at least both displays work.

 

Unfortunately, sleep/wake behavior did not change with the HDMI-connected display.  Both the internal and HDMI displays wake properly (eventually, after several minutes), but ACPI debug trace showing that _WAK halts due to non-available EC is still the same.

Like i said above, after you wake the notebook and got black screen then plug HDMI cable monitor. Not plug HDMI cable before sleep. 

Plug the HDMI monitor after wake from sleep (when black screen happens)

[deeveedee]

@Andres ZeroCross I'm sorry that I wasn't more clear with my response.  I did try various sequences of sleeping/waking with HDMI connected/disconnected.  I could not cause the laptop to wake normally no matter what I did with HDMI.  I tried the following:

• HDMI connected before sleep and after wake
• HDMI disconnected before sleep and connected immediately after attempting to wake
• HDMI disconnected before sleep and connected 10 seconds after attempting wake
• HDMI disconnected before sleep and connected 20 seconds after attempting wake
• HDMI disconnected before sleep and connected, disconnected, connected after attempting wake

In all cases, laptop sleeps fine but screens remain black for several minutes before waking.  Both screens do eventually wake normally and are fully operational after the delayed wake, but internal PS2 keyboard is not functional after wake, trackpad is functional after wake.  

 

In summary, I am not observing any difference in the sleep/wake problem regardless of how I connect HDMI.  Based on what I see in the ACPI debug trace, I am not surprised by these results.

Edited October 24, 2025 by deeveedee

[deeveedee]

I found some things in ACPI that I'm experimenting with for working sleep (not working, yet).  While experimenting, I found an issue in HP's ACPI:

 

In Method (ITLB), adding a 200ms delay at the beginning of the method fixes a problem where EC FieldUnitObjects were not available at macOS startup (causing Method ITLB to hang).  This is similar to what's being observed during _WAK.

Edited October 29, 2025 by deeveedee

[deeveedee]

After detailed investigation of the wake problem, I believe that those claiming that this laptop lacks support for S3 suspend (used by macOS for sleep/wake on Intel platforms) are correct.  When this HP Elitebook 850 G7 sleeps, it is designed to enter S0 Idle (Modern Standby) power state and NOT S3 suspend.  While this laptop's ACPI includes S3 code, it's probably not tested and doesn't matter, because firmware never wakes EC before _WAK.  Windows manages EC with a driver that reinits EC upon wake.  Variants of Linux that properly handle sleep / wake on this laptop also do so with an EC driver.

 

I don't yet fully understand the inner workings, so forgive what may be a naive proposal of potential solutions:

• Poke EC command/status ports with SystemIO operations from AML (a custom SSDT).  This requires knowing the EC OperationRegion and the EC Command/Status registers within the OperationRegion.  Poke EC command/status ports at the beginning of _WAK and then Sleep until EC is available.
• Create a Lilu kext that detects macOS wake and: a) invokes macOS EC reinit or resume -OR- b) mimics EC resume operation in Linux EC driver.

 

Both of these are beyond anything I've done with macOS.  If anyone has suggested approaches, I welcome your input.  Thank you.

[FirstCustomac]

If S3 is not stable, would you be able enable S0 idle on macOS? Hibernatemode 25 is also an option?

[deeveedee]

@FirstCustomac Thank you for trying to help.  I tested hibernatemode 25, but that made no difference in wake behavior.  _WAK still hangs because EC is not available.  

 

Since macOS does not support S0 Idle for Intel, the only way I believe to fix wake is with the two options I listed previously. I have successfully read the EC status / control and data registers in AML and can see how the EC registers change with various laptop states.  So far, I am unable to write EC control from AML.  This may not be possible, which means that a kext would be required.

 

This might be an interesting project, where someone is enabling S0 on MacBooks for running Windows.  I wonder if it would be possible to create an efi driver (loaded by Open Core) that enables S3 for running macOS.

Edited November 1, 2025 by deeveedee