LP#2167595 - second real-world failure, now with the v3 patch on
7.0.0-38
== Environment ==
- Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic
- v3 patch built out of tree and loaded from
/lib/modules/7.0.0-38-generic/updates/
(mt792x_usb srcversion BF5F60AFAFBFC93CA662D26,
mt7921_common srcversion 9336B003C308D2F9FDFC700)
- Adapter: MediaTek MT7921AU USB (0e8d:7961) on xHCI port 1-9
- Firmware: WM build 20260224110949 (HW/SW 0x8a108a10),
Bluetooth build 20260224111243 (HW/SW 0x008a008a). This is the latest
MT7921 firmware available in Ubuntu (linux-firmware-mediatek
20260319.git217ca6e4-0ubuntu1.2, resolute-updates) and in upstream
linux-firmware as of 2026-10-15.
- Driver: mt76 from Ubuntu 7.0.0-38.38 (upstream 7.0.14) plus the v3 patch,
which is the newest mt76 in Ubuntu 26.04 (generic/HWE; the OEM 7.0.0-1015
kernel carries the same mt76 changes), while upstream the USB hang
hardening by Sean Wang landed in v7.3-rc1 (e137e5fd245c "mt792x: stop
USB register access after bus hang", 161596f033e8 "mt7921u: escalate
broken USB transport to device reset", 7910bd565d8b "mt792x: quiesce USB
paths on disconnect") and is not in any Ubuntu 26.04 kernel yet.
- Use: managed station to a phone hotspot (2.4 GHz, channel 11) plus a
concurrent AP interface (hostapd, same channel) on the same radio. The AP
had no associated clients at the time.
== 1. Timeline (local time, 2026-10-14) ==
07:46 system suspended
14:22 resumed; station reconnected, AP interface recreated
14:30 Bluetooth HID gamepad connected to the same combo chip
(about 60 ACL packets/s from then on)
15:23:16 last periodic sample before the failure, nothing unusual:
about 2 MPDU/s, about 10% failed MPDUs, RTT to the gateway 9 ms,
no packet loss
15:23:34 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d02c failed:-110
15:23:37 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d054 failed:-110
15:23:40 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d058 failed:-110
15:23:44 kernel: mt7921u 1-9:1.3: vendor request req:63 off:53b8 failed:-110
15:23:46 kernel: Bluetooth: hci0: Opcode 0x0401 failed: -110
15:23:46 kernel: Bluetooth: hci0: command 0x0401 tx timeout
15:23:47 kernel: mt7921u 1-9:1.3: vendor request req:63 off:53c4 failed:-110
15:23:50 kernel: mt7921u 1-9:1.3: vendor request req:66 off:53c4 failed:-110
15:23:54 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d02c failed:-110
15:23:57 kernel: mt7921u 1-9:1.3: vendor request req:63 off:d054 failed:-110
15:23:57 kernel: Bluetooth: hci0: Failed to write uhw reg(-110)
15:24:04 kernel: wlx...: deauthenticating from [BSSID] by local choice (Reason:
3=DEAUTH_LEAVING)
15:24:17 kernel: wlx...: failed to remove key (2, ff:ff:ff:ff:ff:ff) from
hardware (-110)
15:24:18 kernel: wlx...: failed to remove key (5, ff:ff:ff:ff:ff:ff) from
hardware (-110)
15:24:19 kernel: mt7921u 1-9:1.3: timed out waiting for pending tx
15:24:20 kernel: usb 1-9: reset high-speed USB device number 3 using xhci_hcd
15:24:26 kernel: usb 1-9: device descriptor read/64, error -110
15:25:08 kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device
command
15:25:14 kernel: usb 1-9: device not accepting address 3, error -62
15:25:26 kernel: usb 1-9: USB disconnect, device number 3
15:26:09 kernel: usb usb1-port9: attempt power cycle
15:26:20 kernel: usb 1-9: device not accepting address 7, error -62
15:31:30 kernel: usb usb1-port9: attempt power cycle
15:31:41 kernel: usb 1-9: device not accepting address 11, error -62
15:31:46 manual reboot. The shutdown tail was 5 s, with no hung tasks and
no "blocked for more than" messages. After the reboot the adapter
enumerated normally and has worked since.
== 2. Comparison with earlier events ==
2026-09-26 (v2 patch, 7.0.0-34): the same failure, described in comment #7.
The register sequence is identical
(d02c -> d054 -> d058 -> 53b8 -> BT 0x0401 -> 53c4 -> 53c4 -> d02c -> d054
-> BT uhw reg), with the same spacing of about 3 s, followed by
"timed out waiting for pending tx" and a USB reset loop the device never
recovered from. At that time no AP interface existed; the adapter was a
plain station.
2026-10-02 05:48: this was NOT a field failure. It was produced by my own
test script (sysfs unbind under TX load), which yielded "failed to remove
key -110" and a "rx urb mismatch" WARNING. Please do not count it as a
spontaneous event.
== 3. What this shows ==
1. The deadlock fix holds in the field. This is the second real failure
with the patch (v2 on 26.09, v3 now). Neither had a hung task, and the
reboot was clean (5 s shutdown tail on 14.10).
2. The underlying failure is outside the disconnect path the patch touches.
The whole chip stops answering on USB: WiFi and Bluetooth time out at the
same moment. A port power cycle does not bring it back, and
re-enumeration fails with -110/-62 until the machine is rebooted. This
looks like a firmware or USB-level hang rather than a driver logic error.
3. Running the AP and the station concurrently is not required to trigger it:
26.09 happened without any AP interface. Both failures happened under low
traffic. New in this occurrence: an active Bluetooth HID device on the
same chip, and the failure came about one hour after resume from
suspend. I do not know the Bluetooth or suspend state for 26.09.
== 4. Questions ==
- Is a firmware hang of this kind known for the 20260224 WM/BT firmware
builds on MT7921AU?
- Is there any debug output (mt76 debugfs, firmware log, usbmon, a module
parameter) worth enabling permanently, so the next occurrence captures
more than the -110 sequence? Failures so far are about 18 days apart, so
a low-overhead option would be preferred.
== 5. Request ==
The USB hang hardening by Sean Wang (MediaTek), merged in v7.3-rc1
(d23353688dd0, 161596f033e8, e137e5fd245c, 7910bd565d8b, a4803d1801c7,
b994cb409f21, plus the dependency 5323d3e50c20 "mt76u: use a threaded NAPI
for the RX path"), targets exactly this failure: e137e5fd245c describes the
same pattern of "vendor request ... failed:-110" every ~3 s. None of it is
in any Ubuntu 26.04 kernel yet.
Could the kernel team consider an SRU of this series to resolute? I am happy
to test a PPA or -proposed kernel on the affected hardware and report back.
See also LP#2161448, which looks like the same issue on noble HWE.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167595
Title:
mt7921u: USB reset after -110 timeouts deadlocks in mt7921_abort_roc,
blocks rtnl_lock and shutdown
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167595/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
