[Bug 2167595] Re: mt7921u: USB reset after -110 timeouts deadlocks in mt7921_abort_roc, blocks rtnl_lock and shutdown

Tested v2 on Ubuntu kernel 7.0.0-34-generic (rebased build, patch applied with no offsets). Results: Test procedure: 3x rapid unload/load cycles of the patched modules (deliberately targeting the window that produced the v1 WARNING), adapter unplug during active transfer, and a full clean shutdown. Results: all three v1 symptoms are gone - zero WARNING at kthread_park, zero "rx urb mismatch" (mt76u_complete_rx), zero "chip reset failed" across the whole test boot. Unplug under load: no call traces, no hung tasks, interface teardown immediate, device re-probes cleanly on replug. Shutdown completed without hanging. Full kernel log of the test boot available on request. Three observations from code review / testing: 1. "Message ... timeout" lines still appear on module unload with an active connection (e.g. 00020002 = MCU_UNI_CMD(BSS_INFO_UPDATE), 000046ed = MCU_EXT_CMD(MAC_INIT_CTRL), sent from the mac80211 teardown path). These are cosmetic: with MT76_MCU_RESET set, mt76_mcu_get_response returns immediately (the messages appear ~33 ms after disconnect starts, not after the 3 s mcu timeout), and the mt792x_reset they trigger is now correctly suppressed by the new MT76_REMOVED check. Suggestion: check MT76_MCU_RESET in mt7921_mcu_parse_response before the dev_err + mt792x_reset to silence these misleading messages (same pattern exists in mt7925/mcu.c). 2. The commit message says this aligns mt7921 with mt7925, but in the 7.0.x tree mt7925_mac_reset_work does not have the MT76_REMOVED check - so mt7925 USB devices would still be exposed to the same race. You may want to include the equivalent fix for mt7925 in the series. 3. Minor: with the flags set on disconnect entry, the teardown MCU commands (MAC disable, BSS removal) and wfsys_reset in mt792xu_cleanup no longer reach the chip (-EIO). Harmless in practice - probe resets the chip on next load and the device recovers cleanly every time in our tests - but worth being aware of. Planning to run v2 as daily driver; will report back after 1-2 weeks of regular use. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167595 Title: mt7921u: USB reset after -110 timeouts deadlocks in mt7921_abort_roc, blocks rtnl_lock and shutdown Status in linux package in Ubuntu: Confirmed Bug description: [ Impact ] When an MT7921AU USB Wi-Fi dongle (e.g. 0e8d:7961) experiences communication stalls (USB -110 ETIMEDOUT errors), mt792x_mac_work holds dev->mt76.mutex while looping on register reads. When USB core detects the stall and triggers unbind, mt792xu_disconnect calls mt76_unregister_device, which takes rtnl_lock and calls mt7921_abort_roc. mt7921_abort_roc then tries to acquire dev->mt76.mutex, which is already held by the stuck mac_work thread. This creates an ABBA deadlock between rtnl_lock and mt76.mutex. As a result: - mac_work waits on USB timeouts with mt76.mutex held. - mt792xu_disconnect waits for mt76.mutex under rtnl_lock. - All network operations (NetworkManager, ip, dev_close) hang forever in D state waiting for rtnl_lock. - The system cannot power off or reboot cleanly without a hard reset. [ Fix ] 1. In mt792xu_disconnect(), set MT76_REMOVED, MT76_RESET, and MT76_MCU_RESET flags and wake pending waitqueues before calling mt76_unregister_device(). Setting MT76_REMOVED causes all pending and subsequent USB register requests to fail immediately with -EIO instead of waiting for 3-second timeouts. 2. In mt792xu_disconnect(), synchronously cancel all workers (mac_work, ps_work, wake_work, reset_work, init_work) prior to unregistration. 3. In mt7921_abort_roc() (and mt7925_abort_roc()), check if MT76_REMOVED is set. If the device was removed, clear MT76_STATE_ROC and return 0 immediately without taking dev->mt76.mutex. [ Test Plan ] 1. Boot kernel 7.0.0-31-generic with patched mt7921u / mt792x-usb modules. 2. Insert MT7921AU USB Wi-Fi adapter (0e8d:7961) and connect to an AP. 3. Physically disconnect the USB adapter while network traffic is active, or trigger bus reset while requests are pending. 4. Verify in dmesg: - Device disconnect completes cleanly without call traces. - rtnl_lock is not blocked; NetworkManager and ip link operate normally. - System reboots and powers off cleanly without hanging in D state. [ Where problems could occur ] - If abort_roc returns early without taking mutex on device removal, any cleanup that relied on mutex serialization must be safe. Since MT76_REMOVED is set, hardware registers cannot be accessed anyway, so skipping mutex and clearing local flag is safe. - Canceling works before unregistering prevents concurrent execution during teardown, which is the desired behavior on unbind. [ Other Info ] Patch tested and compiled against linux-headers-7.0.0-31-generic on Ubuntu 26.04 (Resolute). Clean compile with 0 errors and 0 warnings. --- [ Original Report ] Dell Precision 3650 Tower, Ubuntu 26.04 dev kernel 7.0.0-31-generic. Alfa AWUS036AXM (MT7921AU, USB ID 0e8d:7961). Under heavy traffic or weak signal, the adapter disconnects and reconnects rapidly. Eventually kernel dmesg shows: [ 342.112004] mt7921u 1-2:1.0: Message 00000040 (seq 4) timeout [ 345.184002] mt7921u 1-2:1.0: Message 00000040 (seq 5) timeout [ 348.256011] mt7921u 1-2:1.0: Failed to get patch sem [ 351.328008] mt7921u 1-2:1.0: hardware init failed After that, NetworkManager stops responding. Running 'ip link' hangs indefinitely in D state. Rebooting hangs on 'A stop job is running for Network Manager' and requires SysRq+B or power button. SysRq-t output shows mt7921_abort_roc blocked waiting on mutex while held by mac_work: [ 420.100012] task:kworker/u16:3 blocked for more than 120 seconds. [ 420.100020] Call Trace: [ 420.100025] __schedule+0x345/0x890 [ 420.100030] schedule+0x5a/0xc0 [ 420.100035] schedule_preempt_disabled+0x18/0x30 [ 420.100040] __mutex_lock.isra.0+0x28a/0x4b0 [ 420.100045] mt7921_abort_roc+0x2d/0x80 [mt7921_common] [ 420.100050] ieee80211_set_disassoc+0x62/0x90 [cfg80211] [ 420.100055] mt76_unregister_device+0x48/0x90 [mt76] [ 420.100060] mt792xu_disconnect+0x3c/0x70 [mt792x_usb] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167595/+subscriptions