inc-0004
blocked
citable URL: https://halobench.com/records/inc-0004/ — this address never moves; the anchor /records/#inc-0004 keeps resolving
Unified-memory OOM cascade to kernel panic, then a wedged boot
detected
2026-07-21 · window 09:51+01:00 → 12:41+01:00 · by smart-plug-power-flat-at-45W · lag 46m
signature: Smart plug flat at 45 W with no network response; power draw that had been dynamic all morning stopped varying.
should have caught it
The box was OOM-crash-looping for 46 minutes before the panic — three llama-server kills between 09:05 and 09:51 — and nothing surfaced any of them. Worse, the morning brief had flagged "does cache-ram 3072 hold?" as a watch item that same day: the risk was identified and then left unmonitored. A process-restart counter or a free-memory alarm would have caught it with most of an hour to spare.
diagnosis
initial: a single OOM kill, expected to self-heal via the restart
actual: Kernel OOM deadlock. An amdgpu svm_range_restore_work worker needed pages; the OOM killer had already swept the process table; llama-server's memory is GTT-pinned and unreclaimable so killing it freed nothing ("oom_reaper: unable to reap"). With no killable processes the kernel panicked with "System is deadlocked on memory". The post-kdump reboot then wedged at a flat 45 W with NPU SMU init errors, a state only an AC pull clears.
false-path cost: none material
falsified by: kdump vmcore dmesg (dmesg.202607210951)
actual: Kernel OOM deadlock. An amdgpu svm_range_restore_work worker needed pages; the OOM killer had already swept the process table; llama-server's memory is GTT-pinned and unreclaimable so killing it freed nothing ("oom_reaper: unable to reap"). With no killable processes the kernel panicked with "System is deadlocked on memory". The post-kdump reboot then wedged at a flat 45 W with NPU SMU init errors, a state only an AC pull clears.
false-path cost: none material
falsified by: kdump vmcore dmesg (dmesg.202607210951)
blast radius
configs affected: cfg-0002
lesson
On unified memory an OOM is a recovery problem, not a performance problem — it takes the whole box down and needs physical or out-of-band access to clear. Headroom is therefore a stability metric. Mitigations applied: --ctx-checkpoints capped at 4 (was defaulting to 32), desktop stack removed, swap raised to 16G, llama-swap/slotpin restart pairing installed. The ratio at failure was 83.8% of pool, which is the first real calibration point for the OOM warn line.
state
resolved · class hardware
Cited by — computed at build time, never stored
claims clm-0001