From de75be273b4bc2957137293acdf5f5e96a3fe80a Mon Sep 17 00:00:00 2001 From: Bernardo Magri Date: Fri, 24 Jul 2026 19:14:17 +0100 Subject: [PATCH] docs(backlog): file #155 amdgpu/TTM hibernate crash + #156 fingerprint reset Root-caused the dev-box (T14s Gen 4, Ryzen 7 PRO 7840U APU) hibernate crashes to an upstream amdgpu/TTM use-after-free in the S4 GPU-eviction path (ttm_device_prepare_hibernation -> swapout LRU walk -> ttm_resource_manager_next); oops=panic escalates the oops to a session-losing reboot. #155 records root cause, kernel-source audit (both shipped kernels 6.18.39 + 7.1.4 carry the unguarded path), who's-affected scope (AMD APU + hibernate), and the fail-soft mitigation. #156 records the unrelated Synaptics 06cb:00f9 5-min USB reset. Reported upstream by email to amd-gfx 2026-07-24. Co-Authored-By: Claude Opus 4.8 --- agent/BACKLOG.md | 74 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/agent/BACKLOG.md b/agent/BACKLOG.md index a176b3a..c936af0 100644 --- a/agent/BACKLOG.md +++ b/agent/BACKLOG.md @@ -126,6 +126,80 @@ better. Cost: moderate (engine spike + palette bridge + 2–3 widget layouts; start with the exclusive pairs only, not all 28 themes). Value: v1+ polish, not a v1 blocker. +### 155. Hibernate can crash on AMD APUs (amdgpu/TTM NULL deref) — and `oops=panic` makes it catastrophic + +Filed 2026-07-24 from a root-caused investigation on the dev box (TuringMachine, +T14s Gen 4, AMD APU). Hibernate crashes **intermittently on entry**: a kernel +NULL-pointer deref in amdgpu/TTM's hibernation GPU-eviction path +(`ttm_resource_manager_next` ← `ttm_bo_swapout` ← `ttm_device_prepare_hibernation` +← `amdgpu_pmops_freeze`), captured in pstore for the 2026-07-23 22:49 crash +(`Kernel panic - not syncing: Fatal exception`). It is **intermittent** (07-19..07-23: +three clean `hibernation exit` successes vs two entry crashes, on both kernel 7.1.3 +and 7.1.4) because it depends on which GPU buffers are resident at freeze time — so +**not** a misconfig (offset/`resume=`/swapfile are correct), **not** hardware, **not** +the fingerprint reader (see #156; absent from the trace). Confirmed a **known upstream +bug class**: uninitialized TTM resource manager on APUs with no dedicated VRAM +(`ttm_device_prepare_hibernation()` is a young 2025 AMD API; NULL-check fixes are +landing on amd-gfx/dri-devel, but for the *sysfs* `_usage` sibling, not yet +confirmed for this hibernation `_next` site → reportable). **Kernel-source audit +(2026-07-24, vanilla 7.1.4 from the store):** 7.1.4 already carries the mid-2025 +"move swapped objects off the LRU" rework (`ttm_resource_is_swapped`, the +`unevictable` list) — so that known bug is *not* the cause — but it **lacks the later +NULL-guard hardening**: `ttm_resource_manager_next()` has no `!man` guard (its sibling +`_first()` does), and the swapout walk `__ttm_bo_lru_cursor_next()` deliberately drops ++ re-acquires `lru_lock` (its own comment warns the resource "may have been freed and +allocated again" in that window) before calling the unguarded `_next` → a TOCTOU +NULL/UAF deref. So the fix is **not** in 7.1.4 — and there is **no in-pin kernel +escape**: the dev box is already on `latestKernel` (7.1.4 = newest in the 26.05 pin; +default = 6.18.39), and a 2026-07-24 source check shows the **default 6.18.39 carries the +same unguarded path** (`ttm_device_prepare_hibernation`, unguarded +`ttm_resource_manager_next`, the same drop/re-lock race) — so downgrading off +`latestKernel` does **not** help. Only a future *patched* release (lock advance) or a +local kernel patch fixes it kernel-side. + +**Two separable problems.** (1) *The kernel bug* — not Nomarchy-fixable; track +upstream, report with the pstore trace + DMI (**filed upstream by email to amd-gfx, +2026-07-24**), and re-test only when a *patched* release lands via a lock advance (both +shipped kernels are affected — see above). (2) *The blast radius, which IS ours* — Nomarchy's +`panic=10 oops=panic` boot default turns a **recoverable** suspend-time driver oops +(kernel would abort hibernation and thaw back to a live session) into a **guaranteed +reboot + total session loss**. That penalty is inherited by every machine's +suspend/hibernate, not just this APU. Nomarchy-actionable slice: make the sleep path +**fail-soft** — scope/relax `oops=panic` so a device-suspend oops aborts the sleep and +keeps the session, while `panic=10` still auto-reboots genuine panics; weigh against +the deliberate stability posture of `oops=panic` (don't remove it blindly). Fits +**VISION § Theme C** (hibernate/sleep confidence); consider a doctor caveat for APU +hibernate. Immediate per-host mitigation (separate from the distro fix): disabling +`suspend-then-hibernate` on affected APU hosts stops the *auto-triggered* crash. +Cost: fail-soft is a `boot.kernelParams` scoping decision (care needed); upstream +report is cheap. + +**Scope (who's affected).** Not machine-specific and not hardware failure — a kernel +software bug, so any host running the affected code is exposed. The class is **AMD GPU +(esp. APUs / no discrete VRAM) + hibernation (S4) + a kernel in this new-TTM-eviction +window**; Intel/Nvidia users and users who never hibernate are unaffected. **Both** +shipped kernels carry it (default 6.18.39 and latest 7.1.4), so it is *not* limited to +`latestKernel` opt-ins. Nomarchy's own defaults steer the exposed class straight into +it: the installer sets up a hibernate swapfile + **suspend-then-hibernate** on laptops +(auto-hibernate after 1h on battery) and `oops=panic` turns each hit into a reboot — and +that intersects the **VISION north-star user** on the AMD side (modern AMD laptop = APU). +So this is broad product exposure, not a one-off. Caveats: the exact affected +kernel-version *range* is not mapped, and the APU-vs-discrete split is from the upstream +discussion, not reproduced on other hardware. + +### 156. Synaptics fingerprint reader (`06cb:00f9`) resets every ~5 min + +Filed 2026-07-24, noticed while diagnosing #155 (unrelated to those crashes — nowhere +in the trace). On the dev box the fingerprint reader (USB `1-5`, Synaptics +`06cb:00f9`) logs `usb 1-5: reset full-speed USB device number 3 using xhci_hcd` +every ~5 minutes for hours, and `fprintd.service` is started→`Deactivated +successfully` on the same 5-min cadence — i.e. *something polls fprintd every 5 min* +and the device needs a reset each time. Cosmetic-ish, but it is needless +wakeups/power draw and a flaky device that won't quiesce is a latent suspend-hang +risk. Look into: what polls fprintd on that interval (hyprlock fingerprint backend +from `nomarchy.idle.fingerprint`? a geoclue/other watcher?), and whether the reset is +avoidable (autosuspend quirk, or gating the poll). Cost: investigation only; low. + ### 146. `[watch]` hypridle hangs instead of exiting when its compositor vanishes **Re-measured 2026-07-20 (dev box; user journal is persistent back to 2026-05-01,