Public bug reported:
# 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
ProblemType: Bug
DistroRelease: Ubuntu 26.04
Package: linux-image-7.0.0-30-generic 7.0.0-30.30
ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12
Uname: Linux 7.0.0-30-generic x86_64
ApportVersion: 2.34.1-0ubuntu0.1
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: user 2439 F.... wireplumber
/dev/snd/controlC0: user 2439 F.... wireplumber
/dev/snd/seq: user 2408 F.... pipewire
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Tue Aug 25 18:02:12 2026
InstallationDate: Installed on 2026-07-22 (34 days ago)
InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1)
MachineType: HP HP ProBook x360 435 G8 Notebook PC
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-30-generic
root=UUID=0f4e9813-352a-4b48-a23f-e0a88c3524d7 ro quiet splash pcie_aspm=off
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/07/2026
dmi.bios.release: 24.2
dmi.bios.vendor: HP
dmi.bios.version: T80 Ver. 01.24.02
dmi.board.name: 8886
dmi.board.vendor: HP
dmi.board.version: KBC Version 45.38.00
dmi.chassis.type: 31
dmi.chassis.vendor: HP
dmi.ec.firmware.release: 69.56
dmi.modalias:
dmi:bvnHP:bvrT80Ver.01.24.02:bd05/07/2026:br24.2:efr69.56:svnHP:pnHPProBookx360435G8NotebookPC:pvrSBKPFV3:rvnHP:rn8886:rvrKBCVersion45.38.00:cvnHP:ct31:cvr:sku4V8H3PA#ABG:pfa103C_5336ANHPProBookx360:
dmi.product.family: 103C_5336AN HP ProBook x360
dmi.product.name: HP ProBook x360 435 G8 Notebook PC
dmi.product.sku: 4V8H3PA#ABG
dmi.product.version: SBKPFV3
dmi.sys.vendor: HP
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug resolute wayland-session
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2165013
Title:
HP ProBook x360 435 G8 — Recurring Hard Freeze / Crash Investigation
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165013/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
