Contribute
Register

HP OMEN 15-ax202na

Status
Not open for further replies.
The HP G6 2221ss patch seems like the correct patch.

Keep in mind slow boot due to HDD may require tweaked abm_firstpolldelay.
Read here:
https://www.tonymacx86.com/threads/readme-common-problems-in-10-13-high-sierra.233582/

macOS is installed on my M.2 SSD in HFS+J. I went ahead and rebooted with abm_firstpolldelay=16000 anyway, and now the laptop doesn't even notice when I unplug it - the battery icon stays the same - perhaps it would if I kept it unplugged for longer, but the battery might die if I do. I've uploaded another gen_debug zip incase that's necessary (abm_firstpolldelay=16000 isn't included in config.plist because I added the boot arg in the Clover GUI before boot).

Edit: decided to unplug the laptop and see how long it stays on for until it dies. Will report back once it dies and I plug it back in.
Edit 2: battery died almost immediately after, plugged it back in and booted with abm_firstpolldelay=16000.
Edit 3: battery behaviour was the same as prior to the battery dying
 

Attachments

  • debug_194.zip
    2.6 MB · Views: 93
Last edited:
macOS is installed on my M.2 SSD in HFS+J. I went ahead and rebooted with abm_firstpolldelay=16000 anyway, and now the laptop doesn't even notice when I unplug it - the battery icon stays the same - perhaps it would if I kept it unplugged for longer, but the battery might die if I do. I've uploaded another gen_debug zip incase that's necessary (abm_firstpolldelay=16000 isn't included in config.plist because I added the boot arg in the Clover GUI before boot).

Edit: decided to unplug the laptop and see how long it stays on for until it dies. Will report back once it dies and I plug it back in.
Edit 2: battery died almost immediately after, plugged it back in and booted with abm_firstpolldelay=16000.
Edit 3: battery behaviour was the same as prior to the battery dying

Your DSDT is not patched correctly for battery status.
For example, this 16-bit field is not patched:
Code:
            Field (ERAM, ByteAcc, NoLock, Preserve)
            {
                Offset (0x04), 
                SMW0,   16
            }

Refer to the guide:
https://www.tonymacx86.com/threads/guide-how-to-patch-dsdt-for-working-battery-status.116102/
 
Your DSDT is not patched correctly for battery status.
For example, this 16-bit field is not patched:
Code:
            Field (ERAM, ByteAcc, NoLock, Preserve)
            {
                Offset (0x04),
                SMW0,   16
            }

Refer to the guide:
https://www.tonymacx86.com/threads/guide-how-to-patch-dsdt-for-working-battery-status.116102/

I applied the HP G6 2221ss patch and checked for any non 8-bit fields within ERAM - I couldn't see any. After a reboot with the new DSDT applied, the battery still won't charge. After this, I also added the Windows 10 OS Check Fix patch - this was also no help.

Checking my battery status via terminal, I get this (the first output was after a fresh boot, the second output was after unplugging and replugging the AC cable for my laptop).
Code:
Kierans-MacBook-Pro:~ fazeilluminati$ pmset -g batt

Now drawing from 'AC Power'

 -InternalBattery-0 (id=3473507)    0%; charging; (no estimate) present: true

Kierans-MacBook-Pro:~ fazeilluminati$ pmset -g batt

Now drawing from 'AC Power'

 -InternalBattery-0 (id=3473507)    0%; AC attached; not charging present: true

My latest debug.zip is attached.

Thanks.
 

Attachments

  • debug_23197.zip
    2.7 MB · Views: 85
I applied the HP G6 2221ss patch and checked for any non 8-bit fields within ERAM - I couldn't see any. After a reboot with the new DSDT applied, the battery still won't charge. After this, I also added the Windows 10 OS Check Fix patch - this was also no help.

Checking my battery status via terminal, I get this (the first output was after a fresh boot, the second output was after unplugging and replugging the AC cable for my laptop).
Code:
Kierans-MacBook-Pro:~ fazeilluminati$ pmset -g batt

Now drawing from 'AC Power'

 -InternalBattery-0 (id=3473507)    0%; charging; (no estimate) present: true

Kierans-MacBook-Pro:~ fazeilluminati$ pmset -g batt

Now drawing from 'AC Power'

 -InternalBattery-0 (id=3473507)    0%; AC attached; not charging present: true

My latest debug.zip is attached.

Thanks.

Your ioreg shows current capacity read as zero.
Obviously, your ACPI patching for battery is not working, or your battery is defective.
Check in Windows.
 
Battery is not defective, windows detects it just fine (see attached images).

After the first boot while plugged in:
Code:
Kierans-MacBook-Pro:~ fazeilluminati$ pmset -g batt

Now drawing from 'AC Power'

 -InternalBattery-0 (id=3473507)    21%; charging; (no estimate) present: true
After unplugging:
Code:
Kierans-MacBook-Pro:~ fazeilluminati$ pmset -g batt

Now drawing from 'Battery Power'

 -InternalBattery-0 (id=3473507)    21%; discharging; (no estimate) present: true
After plugging back in:
Code:
Kierans-MacBook-Pro:~ fazeilluminati$ pmset -g batt

Now drawing from 'AC Power'

 -InternalBattery-0 (id=3473507)    21%; AC attached; not charging present: true

It seems that macOS can read the battery state but not write to it properly? Latest gen_debug is attached. Thanks.

Edit: after booting windows again after having the battery detected in macOS, the battery won’t charge. This will persist until the machines existing battery depletes entirely and windows is booted again.
 

Attachments

  • 073AEA73-FB34-4013-80A1-ACABAFE8F98C.jpeg
    073AEA73-FB34-4013-80A1-ACABAFE8F98C.jpeg
    3.4 MB · Views: 98
  • F8F716CC-2236-4135-B067-E3FDE64FBB8A.jpeg
    F8F716CC-2236-4135-B067-E3FDE64FBB8A.jpeg
    3.3 MB · Views: 96
  • E7065373-7D51-4B60-9515-40AFFD1EF837.jpeg
    E7065373-7D51-4B60-9515-40AFFD1EF837.jpeg
    3.3 MB · Views: 129
  • debug_3285.zip
    2.7 MB · Views: 96
  • B8FC87B8-4636-4689-8883-D3326FDC9CF3.jpeg
    B8FC87B8-4636-4689-8883-D3326FDC9CF3.jpeg
    3.1 MB · Views: 109
  • 114678A1-8E67-4C14-9343-1BC311E8FAFD.jpeg
    114678A1-8E67-4C14-9343-1BC311E8FAFD.jpeg
    2.9 MB · Views: 112
  • 7844ECCC-465D-4CD3-B5A4-F773F5753568.jpeg
    7844ECCC-465D-4CD3-B5A4-F773F5753568.jpeg
    2.9 MB · Views: 122
Last edited:
It seems that macOS can read the battery state but not write to it properly?

Battery status is NEVER "written".
It is a pure read/status function in ACPI only.
You may need to debug your ACPI battery methods (_BIF, _BST) with ACPIDebug.kext and debug version of ACPIBatteryManager.kext.

If you have run the laptop with incorrect ACPI patches, make sure you do EC reset.

Latest gen_debug is attached.

Edit: after booting windows again after having the battery detected in macOS, the battery won’t charge. This will persist until the machines existing battery depletes entirely and windows is booted again.

OsxAptioFix3 not recommended.
Refer to the guide:
https://www.tonymacx86.com/threads/guide-booting-the-os-x-installer-on-laptops-with-clover.148093/
 
You may need to debug your ACPI battery methods (_BIF, _BST) with ACPIDebug.kext and debug version of ACPIBatteryManager.kext.
Installed both specified kexts.
If you have run the laptop with incorrect ACPI patches, make sure you do EC reset.
EC reset performed based on these instructions: https://support.hp.com/ph-en/document/c01684768#c01684768_nonremovablebatt
OsxAptioFix3 not recommended.
Replaced OsxAptioFix3.efi with AptioMemoryFix.efi.

Latest gen_debug attached.

Thanks.
 

Attachments

  • debug_9620.zip
    2.8 MB · Views: 90
You will need to read about ACPIDebug.kext (ACPIDebug README), then instrument your ACPI methods accordingly.

I've added a bunch of RMDT.PUSH() calls to _BIF and _BST. The calls are appearing in kernel_log.txt (both _BIF and _BST are starting and ending correctly). Is there anywhere else in my DSDT I need to add RMDT.PUSH() calls to help debug this issue?

This is what I've got so far:
Code:
            Method (_BIF, 0, NotSerialized)  // _BIF: Battery Information
            {
                \RMDT.PUSH ("Entering _BIF")
                If (LEqual (^^PCI0.LPCB.EC0.ECOK, One))
                {
                    \RMDT.PUSH ("_BIF: First if statement")
                    If (^^PCI0.LPCB.EC0.MBTS)
                    {
                        \RMDT.PUSH ("_BIF: Second if statement")
                        UPBI ()
                    }
                    Else
                    {
                        \RMDT.PUSH ("_BIF: First else statement")
                        IVBI ()
                    }
                }
                Else
                {
                    \RMDT.PUSH ("_BIF: Second else statement")
                    IVBI ()
                }

                \RMDT.PUSH ("Exiting _BIF")
                Return (PBIF)
            }

            Method (_BST, 0, NotSerialized)  // _BST: Battery Status
            {
                \RMDT.PUSH ("Entering _BST")
                If (LEqual (^^PCI0.LPCB.EC0.ECOK, One))
                {
                    \RMDT.PUSH ("_BST: First if statement")
                    If (^^PCI0.LPCB.EC0.MBTS)
                    {
                        \RMDT.PUSH ("_BST: Second if statement")
                        UPBS ()
                    }
                    Else
                    {
                        \RMDT.PUSH ("_BST: First else statement")
                        IVBS ()
                    }
                }
                Else
                {
                    \RMDT.PUSH ("_BST: Second else statement")
                    IVBS ()
                }

                If (LEqual (BRTE, Zero))
                {
                    \RMDT.PUSH ("_BST: Third if statement")
                    Store (0xFFFFFFFF, Index (PBST, One))
                }

                \RMDT.PUSH ("Exiting _BST")
                Return (PBST)
            }

Latest gen_debug attached.
 

Attachments

  • debug_5330.zip
    2.8 MB · Views: 88
I've added a bunch of RMDT.PUSH() calls to _BIF and _BST. The calls are appearing in kernel_log.txt (both _BIF and _BST are starting and ending correctly). Is there anywhere else in my DSDT I need to add RMDT.PUSH() calls to help debug this issue?

This is what I've got so far:
Code:
            Method (_BIF, 0, NotSerialized)  // _BIF: Battery Information
            {
                \RMDT.PUSH ("Entering _BIF")
                If (LEqual (^^PCI0.LPCB.EC0.ECOK, One))
                {
                    \RMDT.PUSH ("_BIF: First if statement")
                    If (^^PCI0.LPCB.EC0.MBTS)
                    {
                        \RMDT.PUSH ("_BIF: Second if statement")
                        UPBI ()
                    }
                    Else
                    {
                        \RMDT.PUSH ("_BIF: First else statement")
                        IVBI ()
                    }
                }
                Else
                {
                    \RMDT.PUSH ("_BIF: Second else statement")
                    IVBI ()
                }

                \RMDT.PUSH ("Exiting _BIF")
                Return (PBIF)
            }

            Method (_BST, 0, NotSerialized)  // _BST: Battery Status
            {
                \RMDT.PUSH ("Entering _BST")
                If (LEqual (^^PCI0.LPCB.EC0.ECOK, One))
                {
                    \RMDT.PUSH ("_BST: First if statement")
                    If (^^PCI0.LPCB.EC0.MBTS)
                    {
                        \RMDT.PUSH ("_BST: Second if statement")
                        UPBS ()
                    }
                    Else
                    {
                        \RMDT.PUSH ("_BST: First else statement")
                        IVBS ()
                    }
                }
                Else
                {
                    \RMDT.PUSH ("_BST: Second else statement")
                    IVBS ()
                }

                If (LEqual (BRTE, Zero))
                {
                    \RMDT.PUSH ("_BST: Third if statement")
                    Store (0xFFFFFFFF, Index (PBST, One))
                }

                \RMDT.PUSH ("Exiting _BST")
                Return (PBST)
            }

Latest gen_debug attached.

You will need to read the ACPI spec so that you have an understanding of how the battery methods are supposed to work.
Then analyze the code, debug output you may add, and debug output from ACPIBatteryManager.kext to determine the source of the problem.
 
Status
Not open for further replies.
Back
Top