Framework 13 AMD, Ryzen AI 300] MT7925 WiFi disappears with `pcie_aspm.policy=powersupersave` — survives reboot, only cleared by a full power-off

Framework Laptop 13 Linux
1

Preamble

Which Linux distro are you using?

  • Arch Linux

Which kernel are you using?

  • 7.1.4-arch1-1

Which BIOS version are you using?

$ sudo dmidecode -s bios-version
03.05

Which Framework Laptop 13 model are you using?

  • AMD Ryzen™ AI 300 Series

Issue

[Framework 13 AMD, Ryzen AI 300] MT7925 WiFi disappears with pcie_aspm.policy=powersupersave — survives reboot, only cleared by a full power-off

TL;DR: With pcie_aspm.policy=powersupersave on the kernel cmdline, my MT7925 WiFi card intermittently fails to probe after a kernel update + reboot (driver own failed, error -5). A normal reboot does not clear it — only a full shutdown + power-on does. This has now happened twice, on two different kernel versions, so it doesn’t look like a one-off. Posting in case others with the same hardware have hit this, or have more insight into the actual cause.

System

  • Machine: Framework Laptop 13 — AMD Ryzen AI 7 350 (Strix Point)
  • WiFi/BT: MediaTek MT7925 (RZ717), Wi-Fi 7, PCIe, driver mt7925e — 0000:c0:00.0
  • Distro: Arch Linux
  • Kernel: first seen on 7.0.3-arch1-2 (up from 6.19.11-arch1-1, which never showed this). Recurred on 7.1.4-arch1-1.
  • Relevant cmdline param: pcie_aspm.policy=powersupersave — set for power savings (measured ~7W idle-draw improvement on this machine, so it’s a meaningful tradeoff to give up)

Symptom

After a kernel update and reboot, the WiFi interface is simply gone — no wlan*/wlp* in ip link show. Bluetooth, which shares the same MT7925 PCIe device, is unaffected. lspci still shows the device and the mt7925e module is loaded, but the kernel log shows:

mt7925e 0000:c0:00.0: driver own failed
mt7925e 0000:c0:00.0: probe with driver mt7925e failed with error -5

Error -5 is -EIO, and it’s failing during the “driver own” step — the PCIe ownership handshake between the host driver and the chip’s firmware — which happens before firmware is even loaded.

What does NOT fix it

  • A normal reboot (reboot/systemctl reboot) — the fault survives across it. I hit this twice in a row within about 90 seconds tonight, each reboot landing back in the same broken state.
  • modprobe -r mt7925e && modprobe mt7925e — same failure.
  • PCI-level remove + rescan (echo 1 > /sys/bus/pci/devices/0000:c0:00.0/remove then echo 1 > /sys/bus/pci/rescan) — tested this specifically as a lower-cost alternative to a full power cycle. Still fails identically.
  • Switching pcie_aspm.policy to default live via sysfs, then remove/rescan — also fails identically. This was useful to rule out: if the problem were purely an ASPM-policy race happening at probe time, reverting the policy before re-probing should have avoided it. It didn’t, which says the bad state isn’t just “the current ASPM policy is hostile to probe” — something is stuck at a lower level.

What does fix it

A genuine full power-off (systemctl poweroff, wait for it to fully power down, then press the power button) — not a warm reboot. This has worked both times.

My working theory (not confirmed) is that this machine keeps the PCIe Vaux rail powered across a warm reboot, so the MT7925’s shared WiFi/BT ownership register (MT_CONN_ON_LPCTL, part of the CONN_ON block) never actually resets — it only clears on a true D3cold transition, which a warm reboot and a software PCI remove/rescan both apparently fail to trigger on this hardware. A real power-off does trigger it. I don’t have hard confirmation of this (would need EC/power-rail visibility I don’t have), so take it as a hypothesis, not a diagnosis.

One data point that supports this: a recent upstream patch for the sibling MT7927 chip disables ASPM and runtime PM unconditionally, specifically because “SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT firmware, requiring a full power cycle to recover” — same register family, same “only a full power cycle fixes it” behavior I’m seeing on MT7925. Different chip variant, but suggests this class of bug is real and not specific to my machine.

Reproduction pattern so far

Both occurrences followed the same pattern: pacman -Syu updates the kernel package → reboot into new kernel → WiFi gone. First time was going from 6.19.11 to 7.0.3; this was thought to be a one-time fluke (fixed by power-off, re-tested powersupersave afterward and it worked fine for weeks). Second occurrence was on 7.1.4, so it’s not tied to one specific kernel build.

Questions for anyone else on MT7925 + Framework 13 AMD

  1. Has anyone else seen driver own failed on mt7925e, particularly with pcie_aspm.policy=powersupersave set?
  2. Does this reproduce without overriding pcie_aspm.policy at all (i.e., leaving it at the kernel default)? I suspect not, since powersupersave is specifically what forces aggressive L1 substate entry, but I haven’t tested a long run on default to be sure it never happens there.
  3. Anyone with lower-level PCIe/power-rail debug access (or a way to check ACPI _PS3/power-resource state for this device) willing to compare notes? I’d like to actually confirm the D3cold/Vaux theory rather than leave it as a guess.

I’ve got kernel logs, journalctl --list-boots timelines, and a detailed writeup of the driver-own handshake mechanism (register-level) from digging into the mt76/mt792x source if that’s useful to anyone trying to bisect this or file it upstream. Happy to share or help test.