Re: [Bug 221842] ACPI: EC/battery AML deadlock also on HP ZBook Fury 16 G11; triggered at the end of a battery recharge

[Jeremy Rutman <jeremy.rutman@rutmanip.com>]

Hello,

A follow-up with the root cause, found in the DSDT. It is the same in
BIOS W96 01.05.01 and in the new W96 01.06.00 (06/15/2026, EC 9.70),
which still hangs: the first boot on it deadlocked within minutes.

Root cause
----------
\_SB.PC00.LPCB.EC0.GBAP is Serialized and takes ECMX inside it:

    Method (GBAP, 0, Serialized)
    {
        Acquire (BTMX, 0xFFFF)
        If ((GACP & 0x02))
        {
            GACP &= 0x05
            Release (BTMX)
            Acquire (ECMX, 0xFFFF)
            If (ECRG)
            {
                NBAP = BATP
            }
            Release (ECMX)
        }
        Else
        {
            Release (BTMX)
        }
        Return (NBAP)
    }

_Q09, and the second half of _Q08, take ECMX first and then call it:

    Method (_Q09, 0, NotSerialized)
    {
        PWUP (0x04, One)
        If (BTDR (0x02))
        {
            Notify (BAT0, 0x80)
        }
        Acquire (ECMX, 0xFFFF)
        Local0 = GBAP ()
        ...
        Release (ECMX)

Every other caller enters GBAP without ECMX: the battery methods
through BSTA (_STA; _BIX -> BTIX; _BST -> BTST), the first half of
_Q08, _Q18, _REG -> ECRI, and \HWAK. So:

  A: _Q09 holds ECMX and waits for GBAP's method mutex
     (acpi_ds_begin_method_execution)
  B: a thread inside GBAP waits in Acquire (ECMX)
     (acpi_ex_acquire_mutex)

That matches both shapes in my traces:

- Battery: _Q09 sends Notify(BAT0, 0x80) just before it takes ECMX,
  and the battery driver's notify handler evaluates _STA/_BST/_BIX ->
  BSTA -> GBAP in parallel. This is the shape of six of my hangs and
  of the #221842 report.
- EC against EC: on 2026-10-23 at 15:10, with the ACPI battery driver
  unbound, the cycle was two kec_query workers, one holding ECMX in
  acpi_ds_begin_method_execution and one in Acquire() inside GBAP
  (from a sysrq-w dump; NVIDIA's NVPCF notify workers and thermald
  were queued behind it). So unbinding the battery driver is not
  enough, and this half needs _Q08/_Q09/_Q18 to run at the same time.

Every Mutex in this DSDT is SyncLevel 0, so ACPICA's
AE_AML_MUTEX_ORDER checks cannot catch the inversion. The same
pattern appears once more, so far not seen in a trace:
\_TZ.GFVE (Serialized, takes ECMX) is called by GTMD with ECMX held,
and by GTMS and WQBI without.

Fix
---
Firmware (HP): make GBAP and GFVE NotSerialized. Neither creates
named objects; ECMX and BTMX still guard what they touch, and an AML
Mutex is re-entrant for its owner, so the ECMX holder can enter them.
Alternatively, in _Q08/_Q09, call GBAP before Acquire (ECMX).

On this machine: an initrd DSDT override with exactly that change. It
touches two MethodFlags bytes, bumps the OEM revision from 0 to 1 and
fixes the checksum; the disassembly differs in those three lines only.
I am installing it now and will report back after a few weeks. A
caution for anyone copying it: HP ships the DSDT with OEM revision 0
in both BIOS versions, so a revision-1 override would also replace a
future BIOS's DSDT; tie it to the BIOS version.

Kernel side: the EC-against-EC half needs concurrent _Qxx
evaluation, so acpi.ec_max_queries=1 should block it for users who
cannot override the DSDT (Secure Boot, lockdown). The battery half
needs the battery methods not to run while _Q08/_Q09 does: unbinding
the battery driver, or the acpi_ec_flush_work() idea in my first
mail. Whether a DMI quirk for these HP models is acceptable is your
call; the real fix is HP's.

A correction to my first mail: the trigger is a battery status change
at either end of a recharge. The 8th hang, on 2026-10-22, came at the
start of one.

The ZBook Firefly 14 G10 in #221842 probably shares this EC code; its
reporter could look for GBAP in their DSDT.

Analysis prepared with the help of an AI assistant (Claude,
Anthropic), from this machine's tables and logs.

Thanks,
Jeremy Rutman