System
- Framework Desktop, AMD Ryzen AI MAX+ 395 w/ Radeon 8060S
- BIOS/firmware updated via
fwupd/LVFS: 0.0.3.2 → 0.0.3.5, completed 2026-07-14 13:57:24 (High urgency update) - OS: NixOS, kernel
7.1.0-NixOS(#1-NixOS SMP PREEMPT_DYNAMIC, built 2026-06-14) - Wi-Fi: MediaTek MT7925 (RZ717), Wi-Fi 7,
mt7925edriver
What happened
About a day and a half after updating to BIOS 3.05, the machine hard-locked overnight (2026-07-16, 01:06:17 local) while completely unattended. When I came back to it: chassis power LED and keyboard backlight were both on, fans presumably still spinning, but zero video output on any monitor, and it was fully unresponsive to keyboard/mouse. Had to hold the power button to force a reset.
I was able to confirm from the systemd journal of the previous boot that this was a genuine kernel-level lockup, not a sleep/power issue — the machine was mid-task (several background processes actively running, one of them making live SSH calls to a second machine over Thunderbolt networking) right up to the exact second logging stopped, with no orderly shutdown sequence. A second machine on the same LAN independently logged its link to this one dropping at the identical timestamp, confirming this box went totally unresponsive network-wide, instantaneously — not a partial GPU/display-only fault, and not a mains power cut (a real power loss would have taken the LEDs down too).
The trigger, right before the freeze — a routine same-SSID band-steering roam (2.4GHz AP → 5GHz AP on my own router, nothing unusual):
kernel: wlp192s0: disconnect from AP 68:a3:78:d3:41:f4 for new auth to 8c:97:ea:fe:fa:e0
kernel: wlp192s0: authenticate with 8c:97:ea:fe:fa:e0 (local address=ac:f2:3c:35:1e:d1)
kernel: wlp192s0: send auth to 8c:97:ea:fe:fa:e0 (try 1/3)
kernel: slab kmalloc-rnd-08-8k start ffff89f338cca000 pointer offset 4176 size 8192
kernel: list_add corruption. prev->next should be next (ffff89e125138908), but was ffff89f338ccb050. (prev=ffff89f338ccb050).
kernel: ------------[ cut here ]------------
kernel: kernel BUG at lib/list_debug.c:32!
That kernel BUG line is the last thing the journal has — no register dump, no call trace, nothing after it. It looks like the list_add corruption check fired inside a locked context (list operations here are typically under rtnl_lock), and the BUG trap froze the kernel outright rather than completing a clean oops/panic — which matches the “on but dead” symptom exactly.
What I’ve ruled out:
- Mains power loss — LEDs stayed lit, no UPS involved, doesn’t fit
- A scheduled OS update job — it was scheduled for later and never got the chance to run
- Any suspend/sleep action on my end — nothing suspend-related was in flight, just a routine display-off hotkey earlier in the evening (compositor-level monitor blanking only, no networking interaction, and it wasn’t even active at time of crash)
What I don’t know, and am asking here: is this a known issue with the MT7925/RZ717 (mt7925e) roaming path on Strix Halo boards? Did 3.05 touch anything WiFi-adjacent — PCIe ASPM/power states, USB4/TB, or power delivery timing that could make an existing upstream mt7925e race more likely to trigger? Has anyone else seen list_add corruption / hard lockups from this chipset since updating?
I’d like to avoid a repeat of “silently dead until someone finds it,” so in the meantime I’m adding a hardware watchdog so a future full lockup triggers an automatic reboot instead of requiring a manual power-cycle — but I’d rather fix the root cause than just paper over it. Happy to pull more logs (journalctl -k, dmesg, fwupdmgr get-details on the 3.05 release notes, etc.) if that helps triage.