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 <noreply@anthropic.com>

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,