HP ProBook x360 435 G8 — Recurring Hard Freeze Crash

[nightweave]

HP ProBook x360 435 G8 — Recurring Hard Freeze / Crash Investigation

System

• Model: HP ProBook x360 435 G8 Notebook PC
• BIOS: T80 Ver. 01.24.02, dated 05/07/2026 (current as of investigation; no newer version found via fwupdmgr or public HP records)
• CPU/APU: AMD Ryzen (Renoir, Cezanne-class), board 8886
• OS: Ubuntu 26.04
• Kernel: 7.0.0-30-generic (also reproduced under 7.0.0-29-generic)
• WiFi/BT combo: Realtek RTL8822CE (rtw88_8822ce in-tree driver; also reproduced under the rtw88-dkms out-of-tree package)

Symptom

Intermittent hard freeze/hang under normal desktop use, most frequently correlated with sustained WiFi + disk I/O load (e.g. torrenting). Onset is abrupt — seconds of visible glitching (frozen cursor, unresponsive UI) followed by total unresponsiveness (no keyboard/mouse, no network, no visible activity). No consistent trigger identified beyond "sustained load," and it has recurred across multiple distinct mitigation attempts (see below). Occasionally recurs in rapid, back-to-back cycles (system re-freezing within 1–2 minutes of a fresh boot under the same workload).

Root cause candidate: BIOS ACPI thermal-zone bug

Every single boot — regardless of workload, kernel version, or driver configuration — logs the same malformed AML error from the BIOS's DSDT thermal zone method, at boot time, before any user activity:

ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x000000005) is beyond end of object (length 0x5) (20251212/exoparg2-393)
ACPI Error: Aborting method \_TZ.GTTP due to previous error (AE_AML_PACKAGE_LIMIT) (20251212/psparse-529)
ACPI Error: Aborting method \_TZ.CHGZ._TMP due to previous error (AE_AML_PACKAGE_LIMIT) (20251212/psparse-529)

This indicates the BIOS's _TZ.GTTP (Get Trip Points) method references a package object with an index (5) that exceeds the object's actual length (5, i.e. valid indices 0–4), causing the ACPI interpreter to abort the method every time it is invoked. This is present in the current shipping BIOS (01.24.02) and appears to be an HP firmware defect, not a Linux/kernel issue — the malformed AML table ships from the factory.

Alongside this, every boot also logs a fan-control failure via HP's WMI interface:

hp_wmi: query 0x4 returned error 0x5
hp-wmi hp-wmi: Failed to apply initial fan settings: -22

This is consistent with the OS's inability to reliably interact with thermal/fan management on this platform, likely downstream of the same firmware defect.

Investigation timeline and eliminated causes

Extensive diagnostics were performed to isolate the cause, in this order:

1. Hardware watchdog (sp5100_tco + watchdog/wd_keepalive) was configured to force a reboot on true system hang. Confirmed working via wd_keepalive heartbeat and a live SysRq panic test — the watchdog reliably recovers the system after a hang, but does not explain or fix the underlying cause.

2. Thermal/heat ruled out. A continuous background logger (sensors output every 5s) was run for days across multiple crash events. In every case, CPU/GPU temperatures immediately preceding a crash were in the mid-40s–50s °C — well below thermal throttling thresholds (NVMe critical: 79.8°C) — and load average was unremarkable (<1.0). No correlation between temperature and crash timing was found.

3. CPU idle/C-state transitions ruled out. An initial kernel WARNING was observed repeatedly across multiple CPUs:

   WARNING: kernel/workqueue.c:2351 at __queue_work.part.0+0x190/0x390, CPU#N: swapper/N/0

   fired from delayed_work_timer_fn → call_timer_fn → __run_timers, on idle-thread context across several CPUs within seconds of each other. Hypothesis: CPU C-state entry/exit racing with timer-queued work. Tested via processor.max_cstate=1 boot parameter — crashes continued at the same frequency under identical load, disconfirming this as the primary cause.

4. WiFi driver (rtw88) implicated by a genuine use-after-free — since fixed, but not the whole story. Kernel crash dumps (via kdump/apport, see below) captured a real kernel Oops:

   Oops: general protection fault, probably for non-canonical address 0xdead00000000012a: 0000 [#1] SMP NOPTI
   RIP: 0010:__run_timers+0x1e0/0x2c0
   RAX: dead000000000122   R12: dead000000000122

   0xdead000000000122 is the kernel's LIST_POISON2 sentinel — this is a genuine use-after-free in the timer/workqueue subsystem: a list node was dereferenced after being freed. All three captured Oops dumps were tainted (OE) (out-of-tree, unsigned module), with rtw_8822ce(OE), rtw_core(OE), rtw_pci(OE) in the loaded module list — identifying the out-of-tree rtw88-dkms package, not the in-tree kernel driver, as the module active at time of crash.

   Mitigation applied: removed rtw88-dkms entirely (dkms remove rtw88/0.6 --all), reverted to the in-tree rtw88_8822ce/rtw88_core/rtw88_pci modules bundled with the kernel. Additionally applied, as defense in depth:

   • disable_lps_deep=Y module parameter (deep power-save disabled)
   • iw dev wlp1s0 set power_save off + persisted via NetworkManager
   • pcie_aspm=off kernel boot parameter

   Result: the specific use-after-free signature has not recurred since. However, hard freezes continued to occur afterward under the same load pattern, indicating this fixed a real, independent bug but was not the sole cause of the reported symptom.

5. hung_task_panic=1 / softlockup_panic=1 enabled to force any future scheduler-visible hang into a full kernel panic + kdump capture, for better diagnostics. On the most recent recurrences of the freeze, neither trigger fired — no hung-task warning, no softlockup warning, no Oops, nothing abnormal in the kernel log beyond the standing _TZ.GTTP ACPI error — the log simply stops mid-routine-activity with no further entries until the next boot. This indicates the freeze is occurring below the level the kernel's own scheduler-based hang detection can observe (consistent with an EC/firmware-level deadlock rather than a kernel-level stall).

6. Manual kdump capture test also fails to complete. A deliberate echo c | sudo tee /proc/sysrq-trigger panic was triggered on a working system (confirmed kexec_crash_loaded=1, kdump-tools.service active and enabled, valid /var/crash target with ample free space) and left for 5+ minutes with no recovery — required a manual power cycle. This suggests that even a deliberately-triggered kernel panic cannot reliably hand off to the crash kernel on this specific hardware, which is consistent with (though not conclusive proof of) a firmware/EC-level fault interfering with the kexec handoff itself.

Current assessment

The most likely root cause is a BIOS/EC firmware defect centered on the malformed _TZ.GTTP ACPI thermal method (confirmed present in BIOS 01.24.02, the latest available version). This firmware bug:

• Fires on every single boot, unconditionally
• Correlates with a fan-control failure via hp-wmi
• Cannot be worked around from the OS side (C-states, WiFi driver, ASPM, power-save were all eliminated as primary causes)
• Appears able to wedge the system at a level below the kernel's own panic/hang detection, given that hung_task_panic/softlockup_panic/manual kdump triggers have all failed to produce a normal recovery during or after the actual freeze

The only reliable recovery mechanism found is the AMD chipset-level hardware watchdog (sp5100_tco), which operates independently of the OS/kernel scheduler and forces a hardware reboot regardless of what is wedged above it.

Requests

To HP: Please investigate and correct the malformed _TZ.GTTP AML method in the DSDT for the ProBook x360 435 G8 (board 8886), as reported in BIOS 01.24.02. The specific ACPI error is:

AE_AML_PACKAGE_LIMIT, Index (0x000000005) is beyond end of object (length 0x5)

in the \_TZ.GTTP method (and its caller \_TZ.CHGZ._TMP). This appears to be a straightforward off-by-one or incorrectly sized package object in the DSDT thermal zone table.

To Ubuntu/kernel maintainers: Investigating why hung_task_panic=1/softlockup_panic=1 and a manually-triggered SysRq panic both fail to produce a completed kdump capture on this hardware would help future diagnosis of firmware-adjacent freezes of this kind — ideally kdump should be robust even when the underlying fault is outside the kernel's control.

Supporting evidence available on request

• Full journalctl -k output from multiple affected boots
• Three decompressed VmCoreDmesg crash dumps (Aug 24, 2026, boots at 20:19, 20:44, 20:57) showing the LIST_POISON2 use-after-free Oops, including full register state and stack traces
• Continuous thermal/load logs spanning multiple crash events, showing no thermal correlation
• dmidecode hardware/BIOS identification output