mt7921e hangs when hardware fails
Matthew Wilcox
willy at infradead.org
Mon Nov 2 11:23:16 PST 2026
Something appears to have gone wrong with the mt7921e in my Framework
laptop, but my attempts to recover are hindered by the driver hanging.
lspci:
aa:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter
Subsystem: MEDIATEK Corp. Device e616
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupts: pin B disabled, MSI(X) routed to IRQ 207
IOMMU group: 19
Region 0: Memory at 6019200000 (64-bit, prefetchable) [size=1M]
Region 2: Memory at 98000000 (64-bit, non-prefetchable) [size=32K]
Here's the relevant parts of my dmesg:
[ 54.429097] mt7921e 0000:aa:00.0: enabling device (0000 -> 0002)
[ 54.434064] mt7921e 0000:aa:00.0: ASIC revision: 79220010
[ 54.532459] mt7921e 0000:aa:00.0: HW/SW Version: 0x8a108a10, Build Time: 2026
0724143257a
[ 54.906027] mt7921e 0000:aa:00.0: WM Firmware Version: ____000000, Build Time
: 20260724143402
[ 56.086928] mt7921e 0000:aa:00.0 wlp170s0: renamed from wlan0
[164937.892036] mt7921e 0000:aa:00.0: driver own failed
[164938.942093] mt7921e 0000:aa:00.0: driver own failed
[164939.995093] mt7921e 0000:aa:00.0: driver own failed
[164941.272075] mt7921e 0000:aa:00.0: Timeout for driver own
[164942.316076] mt7921e 0000:aa:00.0: driver own failed
(...)
[164962.212360] mt7921e 0000:aa:00.0: chip reset failed
[164962.212383] wlp170s0: Driver requested disconnection from AP 84:a0:6e:ee:3f:b7
[164965.388396] mt7921e 0000:aa:00.0: Message 00020001 (seq 4) timeout
[164968.464445] mt7921e 0000:aa:00.0: Message 00020001 (seq 6) timeout
(hundreds of similar lines)
So I tried to rmmod to see if reloading the module would fix anything.
Unfortunately, it hung like this:
$ sudo cat /proc/136298/stack
[<0>] __flush_work+0x315/0x4c0
[<0>] cancel_work_sync+0x5e/0x80
[<0>] mt7921_pci_remove+0xb0/0x190 [mt7921e]
[<0>] pci_device_remove+0x4a/0xb0
[<0>] device_release_driver_internal+0x19e/0x200
[<0>] driver_detach+0x48/0x90
[<0>] bus_remove_driver+0x78/0x110
[<0>] pci_unregister_driver+0x36/0xe0
[<0>] __do_sys_delete_module+0x1de/0x350
[<0>] do_syscall_64+0xe1/0x650
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
I think something's wrong with the hardware at this point because lspci
-vvv reported something funny in config space which has disappeared
after a power cycle. Unfortunately I didn't record it, nor did I dump
lspci -xxxx. I'll do that next time this happens.
My call to action here is that this driver should more gracefully cope
with hardware that's not responding properly. Whatever work is being
waited for in __flush_work needs to timeout (I left it overnight and it
didn't timeout) or be cancellable.
After a reboot, it's working fine. I'm going to try stressing the laptop
to see if it fails again, but wanted to get this report out first.
More information about the linux-arm-kernel
mailing list