Environment
Still 7.0.0-28-generic (#28~24.04.1-Ubuntu) — same kernel as the original
report, never rebooted since. Uptime at diagnosis: 66 days. Same Netgear A8000
(mt7921u/mt7922), same iface wlx289401d29b8e, WM firmware ____010000 build
20240219111038.
Neither v7.2-rc4 nor v7.2-rc5 was booted for this session, so this is
not the mainline test that was requested — that is still outstanding.
Symptom
Wi-Fi unusable. NetworkManager held the device at:
GENERAL.STATE: 20 (unavailable)
GENERAL.REASON: 2 (Device is now managed)
Reason 2 is the startup default, i.e. the device entered unavailable at NM
start and was never re-evaluated. Interface was admin-down, no carrier. Wired
was unaffected throughout.
The kernel was not at fault this time
Two independent checks:
The dmesg ring buffer still held unbroken coverage from t=0.655s to
t=5713638s (66.1 days) — it had wrapped only far enough to drop the
first ~0.65s of early-boot output, well before the driver probe. Across
that entire 66-day window there are exactly 11 mt76/USB lines, all of
them the clean probe below, and zero occurrences of
unregister_netdevice, hung-task warnings, or firmware/xHCI errors:
[ 1.032782] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
[ 1.047628] usb 2-1: New USB device found, idVendor=0846, idProduct=9065
[ 4.367949] usbcore: registered new interface driver mt7921u
[ 4.369201] mt7921u 2-1:1.0: HW/SW Version: 0x8a108a10, Build Time:
20240219110958a
[ 4.380188] mt7921u 2-1:1.0: WM Firmware Version: ____010000, Build Time:
20240219111038
[ 5.964413] mt7921u 2-1:1.0 wlx289401d29b8e: renamed from wlan0
Nothing after t=5.96s. The one reset SuperSpeed USB device line at t=4.225s is
the normal probe-time reset that precedes firmware load, not a fault — there
are no resets at all in the remaining 66 days.
ip link set wlx289401d29b8e up followed by iw dev wlx289401d29b8e scan
returned 92 SSID lines on the first attempt. That path goes nl80211 →
mt76 and bypasses wpa_supplicant entirely, so driver, USB link and
firmware were all working.
wpa_supplicant was alive but had stopped answering
The daemon (pid 1671, running the full 66 days) was:
Ss, wchan 0, single-threaded — not in D-state. Nothing blocked in the
kernel, so unlike the Jul-24 capture there was no stack trace to show
the stall.
Still owning its D-Bus name: busctl --system status
fi.w1.wpa_supplicant1 → PID=1671.
Completely unresponsive on the control interface. Even INTERFACES, the
most trivial command, timed out:
$ sudo wpa_cli interface
Selected interface 'wlx289401d29b8e'
Available interfaces:
'INTERFACES' command timed out.
$ sudo wpa_cli -i wlx289401d29b8e status
'STATUS' command timed out.
And /proc/net/packet showed the EAPOL socket unbound, with a large static
backlog:
sk RefCnt Type Proto Iface R Rmem User Inode
3 2 888e 0 1 214272 0 15781
Iface 0 — not bound to any interface — and Rmem 214272 unchanged across
repeated samples: nothing was draining it. The Jul-24 capture in this bug
recorded the same socket at Recv-Q 69120, so it had grown roughly 3x over a
long uptime. The socket disappeared from /proc/net/packet the instant the
daemon was restarted, confirming it belonged to the wedged process.
Since NM drives Wi-Fi through wpa_supplicant, a supplicant that never
answers means NM can never promote the device out of unavailable. That
is the whole outage.
Recovery: no reboot needed, but the supplicant restart alone was not enough
sudo systemctl restart wpa_supplicant
This cleared pid 1671 and the stale EAPOL socket, but did not restore Wi-Fi. NM
still reported unavailable and logged zero mentions of the interface
afterwards, and wpa_cli now failed with No such file or directory — in -u D-Bus
mode the daemon claims no interfaces itself, NM has to hand them over, and NM
never re-tried.
Forcing NM to re-adopt the device fixed it:
sudo nmcli device set wlx289401d29b8e managed no
sudo nmcli device set wlx289401d29b8e managed yes
It then associated immediately: UConnHealth-GUEST, 5 GHz ch 36, −54 dBm, Wi-Fi
6 at 573.5 Mbit/s both directions (HE-MCS 11, NSS 2), DHCP lease obtained, 0%
packet loss forced over the Wi-Fi interface. No new driver messages appeared
through association, DHCP or traffic.
Why this may matter for the SRU
The mode-1 kernel deadlock in this bug is real — the earlier
unregister_netdevice: waiting for wlx289401d29b8e to become free. Usage count =
2 capture is a genuine kernel-side hang, and the mt76 USB hardening backport is
a reasonable fix for it.
But that backport would not have prevented what happened here. On
2026-10-19 the kernel ran clean for 66 days and the failure was entirely
in user space. If the adapter's reputation for "going unrecoverable
after prolonged uptime" is partly this mode, then an mt76-only SRU will
not fully resolve the reported symptom. Two things seem worth
considering:
a wpa_supplicant-side investigation of the event loop stalling while the
process stays schedulable and keeps its D-Bus name — the unbound EAPOL socket
with an undrained backlog looks like the most promising lead, and it appears in
two separate long-uptime captures;
an NM-side watchdog, since NM parked the device at unavailable/reason 2 and
never re-evaluated it across 66 days even after a healthy supplicant was
available.
It also means a v7.2-rc4/rc5 boot test can neither confirm nor refute this mode.
What I can still provide
The full dmesg from this 66-day boot, including the unbroken driver-silence
record. (Worth noting the systemd journal is not useful here: an unrelated DHCP
retry loop on a USB ethernet adapter generated ~12,000 lines/day and rotated
all mt7921 history out of the retained window. Only the kernel ring buffer
preserved it.)
strace, kernel stack and socket fdinfo from the wedged supplicant next time — I
restarted the daemon before capturing those, which I now know was the wrong
order. If it recurs I will collect that state before touching anything.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2161448
Title:
mt7921u: USB Wi-Fi enters unrecoverable state after prolonged uptime;
NetworkManager/supplicant stalls followed by USB disconnect deadlock
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161448/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
