https://bugzilla.kernel.org/show_bug.cgi?id=221847
Bug ID: 221847
Summary: Oops in acpi_ns_build_normalized_path during boot-time
WMI enumeration when vendor AML contains a
Device/Integer namespace collision (HP Pavilion TG01,
AE_AML_OPERAND_TYPE in _SB.PC00.SOD3)
Product: ACPI
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: ACPICA-Core
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Created attachment 310596
--> https://bugzilla.kernel.org/attachment.cgi?id=310596&action=edit
Archive with files referenced in the description.
Hardware: HP Pavilion TG01-xxxx Rocket Lake, BIOS F.24 (also reproduced on
F.21)
Kernel: [7.1.6-arch1-1 / uname -r], Arch Linux, ACPICA 20251212
Reproduces on multiple kernel versions and on archiso live environments;
survives OS reinstalls.
Not hardware: memtest and NVMe self-test clean, failure signature is
deterministic.
The firmware ships two 96-byte SSDTs (OEM ID "HPQOEM", table ID "SLIC-CPC", OEM
rev 1) that define Device (IC03) and Device (IC04) with vendor HIDs
HPIC0003/HPIC0004 in _SB.PC00 is colliding with integer field elements
IC00–IC07 (64-bit, Serial IO controller config offsets) declared in the DSDT's
NVS OperationRegion field block. Both SSDTs attached in full below; they
contain nothing else.
Because single-segment name resolution walks up the scope chain, inside
_SB.PC00.I2C3._PS3 the name IC03 resolves to the SSDT's Device instead of the
DSDT's Integer. That Device is passed to _SB.PC00.SOD3, which uses Arg0
arithmetically in an OperationRegion address expression:
Method (SOD3, 3, Serialized)
{
OperationRegion (ICB1, SystemMemory, (GPCB () + Arg0), 0x88)
...
}
The interpreter correctly raises AE_AML_OPERAND_TYPE on every boot:
ACPI Error: Needed [Integer/String/Buffer], found [Device] ... (exresop-388)
ACPI Error: AE_AML_OPERAND_TYPE, While resolving operands for [Add]
(dswexec-433)
ACPI Error: Aborting method \_SB.PC00.SOD3 due to previous error (psparse-529)
ACPI Error: Aborting method \_SB.PC00.I2C3._PS3 due to previous error
(psparse-529)
The bug being reported: intermittently (~every other boot), instead of the
clean method abort, the kernel oopses in acpi_ns_build_normalized_path in a
kworker during boot-time WMI/ACPI device enumeration (trace attached). The dead
kworker leaves the boot in a degraded state observed downstream effects include
systemd mount units hanging until their 90 s timeout (a trivial vfat /boot
mount killed with result 'timeout') and full boot lockups. The same
intermittent hang affects unmodified archiso installer media on this machine.
The firmware data is unquestionably broken (HP's defect, present in at least
F.21 and F.24), but the interpreter should fail the method and continue, not
oops. It already does exactly that on the boots where the race is not lost the
clean-abort path exists and works.
Reproduction / isolation
Deterministic trigger, probabilistic crash: the AE_AML_OPERAND_TYPE errors
appear at ~1.3 s on every boot of the stock tables; the oops/hang follows on
roughly half of boots.
module_blacklist=wmi,wmi_bmof,hp_wmi fully suppresses the oops and the hangs
(at the cost of everything depending on the wmi core so this is not viable as a
fix, but a clean one-parameter A/B toggle).
Overriding the DSDT (initrd table upgrade) with a 4-line type guard at the top
of SOD3 eliminates the errors and the hangs entirely; the machine has since
passed repeated boot cycles clean:
If ((ObjectType (Arg0) != One)) { Return (Zero) }
This guard is effectively what the reporter suggests the interpreter/
evaluation path should guarantee implicitly: a type mismatch in an
OperationRegion address expression during method evaluation must not be able to
take down the executing kworker.
Both boot paths (stock table vs. override) are selectable side-by-side on the
affected machine; happy to run patches or diagnostics against either.
Attachments
dmesg-stock-crash.txt (full kernel log of a crashed boot incl. the oops in
acpi_ns_build_normalized_path)
dmesg-override-boot.txt (same machine booting the guarded DSDT, for contrast
(no SOD3/I2C3 errors; pre-existing unrelated _SB.WMID.WQBZ/ WQBE
AE_AML_BUFFER_LIMIT aborts remain and are survivable))
acpi.dat (full acpidump of the stock F.24 tables
ssdt2.dsl / ssdt8.dsl which is the two colliding vendor SSDTs, disassembled
(complete contents))
Notes
The colliding SSDTs load after the DSDT; the collision is only visible when the
namespace is assembled, which may be why AE_ALREADY_EXISTS is not raised at
table load (the objects differ in type and the SSDTs declare theirs under
Scope, not by re-declaring the field).
Vendor fix is unlikely (consumer desktop, defect spans multiple BIOS releases);
interpreter hardening is the realistic path for other owners of this platform.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
