MT7922 crash after 23–24 hours of operation when upstream AP disconnects

[o4114o]

Hi,

I am using the MT7922 Wi-Fi module in an OpenWrt 23.x environment and have encountered a reproducible crash after long-term operation in Station + Access Point (STA + AP) mode. Please suggest if there is a known fix for this STA + AP stability issue when the upstream AP disconnects after long uptime.

Summary of the issue

• Firmware used: WIFI_MT7922_patch_mcu_1_1_hdr.bin and WIFI_RAM_CODE_MT7922_1.bin (Feb 20 2024 and Sept 2025 versions both tested)
• Kernel/driver: OpenWrt 23.x (mt76 driver)
• Mode: Single radio (radio0) operating simultaneously as STA uplink and AP for local clients

Steps to reproduce

1. Configure radio0 as STA connecting to an upstream AP on channel (e.g. 161).

2. On the same radio, start AP mode with SSID “WR315B” on the same channel.

3. Let the system run continuously for more than 23–24 hours.

4. When the upstream AP disconnects (e.g. hotspot turned off or signal lost), the system outputs messages such as:

   phy0-sta0: Driver requested disconnection from AP 00:00:00:00:00:00
   mt7921e 0000:01:00.0: Message 00000010 (seq 8) timeout
   mt7921e 0000:01:00.0: Failed to get patch semaphore
   mt7921e 0000:01:00.0: chip reset failed
   

5. After this, the wireless interface (phy0) disappears; wifi reload, ‘/etc/init.d/network restart’, rmmod/modprobe, ‘reboot’ cannot recover it. The PCI bus show no module. Only a full hardware reboot restores the module.

Observation and analysis

• The failure appears after long-term operation (> 23 h) and is triggered by the STA disconnection event.
• Updating to the 2025-09 firmware does not solve the problem, suggesting a driver/firmware synchronization issue involving PCIe reset and MCU power state.
• Disabling power save (iw dev phy0-sta0 set power_save off) may delay the issue but does not prevent it.

[castiel652]

Can you try 24.10

[o4114o]

I have tried 24.10.3 and 24.10.4, but the issue still occurs.
Attached is the system boot and the log when the problem occurred.

log-OpenWrt 24.10.4.txt

[castiel652]

Maybe mt7922 needs something like this too 79dd14f

[zbowling]

my patch in #1034 likely solves this. I've been fixing issues with MT7925, but that driver is based on this one and inherited many of the bugs.

[o4114o]

@zbowling After applying the patch in #1034 , the iwinfo command hangs and becomes unresponsive.

[zbowling]

Will take a look

…

On Wed, Jan 7, 2026 at 5:19 AM vincent ***@***.***> wrote: *o4114o* left a comment (openwrt/mt76#1013) <#1013 (comment)> @zbowling <https://github.com/zbowling> After applying the patch in #1034 <#1034> , the iwinfo command hangs and becomes unresponsive. _20260107153300_58_6.png (view on web) <https://github.com/user-attachments/assets/10aeff3f-98da-4021-b56b-bd07355811be> — Reply to this email directly, view it on GitHub <#1013 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB4A7ROVS6D5AUV6GTVEDT4FUBVJAVCNFSM6AAAAACLCKE5SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMJYHA2DGMJVG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[zbowling]

@zbowling After applying the patch in #1034 , the iwinfo command hangs and becomes unresponsive.

You are right. Thanks for testing my backport. I updated the patch.

The original patch added mutex protection around mt7921_roc_abort_sync() call sites in suspend paths, but those paths already had mutex protection. I missed that backporting. This created nested mutex acquisition (same mutex acquired twice), causing a deadlock since Linux mutexes aren't recursive.

The fix moves the mutex protection inside mt7921_roc_abort_sync() around the interface iteration where MCU functions are called, and removes it from the suspend call sites. This matches the pattern used in the MT7925 patches and prevents deadlocks.

Before (deadlock):

// Suspend path already has mutex
mt792x_mutex_acquire(dev);
mt7921_roc_abort_sync(dev);  // Patch added mutex here = nested = deadlock
mt792x_mutex_release(dev);

After (fixed):

// Inside mt7921_roc_abort_sync()
if (test_and_clear_bit(...)) {
    mt792x_mutex_acquire(dev);  // Mutex here, inside the function
    ieee80211_iterate_interfaces(...);
    mt792x_mutex_release(dev);
}

// Suspend path - no mutex needed
mt7921_roc_abort_sync(dev);  // Function handles mutex internally