BIOS F.38 — Recurring ACPI AML errors (AE_AML_BUFFER_LIMIT) on HP Laptop 15-ef2xxx under Linux

[ismatov]

BIOS F.38 — Recurring ACPI AML errors (AE_AML_BUFFER_LIMIT) on HP Laptop 15-ef2xxx under Linux

Model: HP Laptop 15-ef2xxx
BIOS version: AMI F.38
EC firmware: 59.25
OS: Arch Linux, kernel 7.1.5 (also present across recent kernel versions with newer ACPICA)

Description:

Since updating to BIOS F.38, the kernel's ACPI interpreter (ACPICA) reports consistent errors on every boot when evaluating WMI-related ACPI methods under the _SB.WMID and _SB.ACDC namespaces. These appear to stem from malformed AML bytecode in the DSDT/SSDT tables shipped in this BIOS revision.

Exact errors (from journalctl -b 0):

ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x000000032) is beyond end of object (length 0x32) (exoparg2-393)
ACPI Error: Aborting method \_SB.WMID.WQBZ due to previous error (AE_AML_BUFFER_LIMIT) (psparse-529)
ACPI Error: Aborting method \_SB.WMID.WQBE due to previous error (AE_AML_BUFFER_LIMIT) (psparse-529)
ACPI Error: Aborting method \_SB.ACDC._GRT due to previous error (AE_NOT_EXIST) (psparse-529)
ACPI Error: Aborting method \_SB.ACDC.RTWT due to previous error (AE_NOT_EXIST) (psparse-529)
ACPI Error: Region SystemCMOS (ID=5) has no handler (exfldio-261)
ACPI Error: No handler for Region [VRTC] (SystemCMOS) (evregion-131)

Analysis:

• AE_AML_BUFFER_LIMIT indicates the AML code in WQBE/WQBZ (WMI query methods) is indexing into a buffer object beyond its declared length (0x32) — a bytecode-level bug in the table itself, not a driver issue.
• AE_NOT_EXIST on _SB.ACDC._GRT/RTWT suggests these AC-adapter-related methods reference an object that doesn't exist in the current table scope.
• The SystemCMOS/VRTC region has no registered OperationRegion handler, which may affect RTC/CMOS access via ACPI.

These errors are consistently reproducible on every cold boot and do not appear to depend on OS configuration — I've confirmed they're unrelated to power-management tooling (TLP), kernel modules (hp_wmi, hp_bioscfg both loaded, no causal correlation found via timestamp analysis), or Bluetooth stack timing.

Ask: Could HP firmware engineering review the DSDT/SSDT tables in F.38 for this model against these method names? Happy to provide a full acpidump or dmesg output if useful for debugging.

Thanks in advance.
Here are ACPI dumps:
https://drive.proton.me/urls/V1AZF1T1KR#gfbplKNJcjJN