Re: [REGRESSION] mt7925: MLO connectivity silently stalls with 6GHz link active

On 8/14/26 16:04, Jonas Hort wrote:
> Filed as: https://bugzilla.kernel.org/show_bug.cgi?id=221884
> 
> Summary: WiFi 7 MLO (5GHz+6GHz) on MT7925 silently stops passing traffic
> after a few minutes, while the driver continues to report a fully
> healthy link. Root cause appears to be a stalled WFDMA0 TX hardware
> queue. Reproduced on both linux 7.1.8 (stable) and 7.2.0-rc7 (mainline
> pre-release), not fixed as of rc7. Disabling the 6GHz radio on the
> access point eliminates the freeze entirely in my testing.

Not my area of expertise, but there was one patch was reverted on
Thursday that is somewhat related
(https://git.kernel.org/torvalds/c/3aa1dcaa4f6f5ae08936491e08bd456f331f2d40
), but that was more about shutdown/module unload aiui and likely
something else.

But there were other reports that sounds somewhat related (but careful,
I might send you on the wrong track here; CCing Devin, who wrote two of
the following messages):

https://lore.kernel.org/linux-wireless/[email protected]/
https://lore.kernel.org/linux-wireless/[email protected]/
https://lore.kernel.org/all/[email protected]/

Ciao, Thorsten
> This is a regression: reported by multiple users on the CachyOS forum
> as broken starting with the 7.1.x kernel line; earlier kernels
> (6.18.x longterm) are reported to work fine. I have not yet performed
> a commit-level bisection but can if guided on the best approach given
> the AP-side 6GHz dependency.
> 
> --- Detailed description ---
> 
> Symptom:
> When connected via MLO (Multi-Link Operation, EHT/WiFi 7) with two
> active links - one on 5GHz and one on 6GHz - network traffic silently
> stops after a few minutes of normal use (web browsing, etc). The
> connection continues to show as healthy:
> 
> - `iw link` / `iw station dump` report the connection as associated,
>   authenticated, good signal (-60 to -65 dBm), high negotiated
>   bitrate (800-1700 Mbit/s), 0 tx retries, 0 tx failed.
> - Nothing is logged to dmesg/journalctl at the time of the freeze.
> - Ping to the gateway shows 100% packet loss for several minutes,
>   until the connection eventually recovers on its own.
> 
> I built a small watchdog script (ping-based failure detection + live
> kernel log monitoring) to catch the freeze automatically and sample
> mt76 debugfs state repeatedly across the event. This revealed the
> actual mechanism:
> 
> `/sys/kernel/debug/ieee80211/phy0/mt76/xmit-queues` shows the WFDMA0
> hardware TX queue's `tail` pointer completely frozen while `head`
> keeps advancing - i.e. packets keep getting enqueued but the firmware
> stops draining the queue. RX stops in the same instant (rx byte/packet
> counters in `iw station dump` freeze completely). No tx retries or tx
> failures are ever reported by the driver, so it does not appear to
> notice the stall itself.
> 
> Example from one incident (kernel 7.2.0-rc7):
>   t+1s:  WFDMA0: queued=130 head=390 tail=260   rx bytes=184791894
>   t+9s:  WFDMA0: queued=148 head=408 tail=260   rx bytes=184791894 (unchanged)
> 
> `tail` never advances during the whole stall window while `head`
> keeps growing - the queue is being filled but never drained.
> 
> Reproduced this exact signature four times total (twice on 7.1.8-1,
> twice on 7.2.0-rc7-1), always with MLO 5GHz+6GHz active, always
> within 3-5 minutes of normal use.
> 
> 6GHz correlation:
> My MLO links are 5GHz (5180 MHz) + 6GHz (varies, e.g. 6135 MHz).
> Fully disabling the 6GHz radio on the access point (FritzBox 5690
> Pro, FRITZ!OS 8.25 - not just client-side band restriction via
> NetworkManager, which does not reliably suppress the second MLO
> link) results in 30+ minutes of clean operation with no freeze.
> Re-enabling 6GHz reproduces the freeze again within minutes.
> 
> Regression info:
> Multiple users on the CachyOS forum report this started with the
> 7.1.x kernel line; the previous longterm kernel (6.18.x) is reported
> to work fine by another user with different affected hardware
> (different AP). I have not personally tested 6.18.x myself, and have
> not performed a commit-level bisection yet - happy to do so if
> pointed toward the most likely area of the driver, given the AP-side
> 6GHz dependency makes a fully automated bisection awkward.
> 
> Steps to reproduce:
> 1. Connect to an AP advertising WiFi 7 MLO with 5GHz+6GHz link
>    options, so the client negotiates both links.
> 2. Use the connection normally (web browsing is sufficient).
> 3. Within roughly 3-5 minutes, new connections start hanging;
>    existing traffic stops.
> 4. Check `iw link` - link still reports as connected/healthy.
> 5. Check `/sys/kernel/debug/ieee80211/phy*/mt76/xmit-queues` -
>    WFDMA0 tail pointer frozen while head continues to advance.
> 
> Environment:
> - Kernel: linux-cachyos 7.1.8-1 and linux-cachyos-rc 7.2.0-rc7-1
>   (CachyOS, near-vanilla Arch-based build)
> - cat /proc/version:
>   Linux version 7.2.0-rc7-1-cachyos-rc (linux-cachyos-rc@cachyos)
>   (clang version 22.1.8, LLD 22.1.8) #1 SMP PREEMPT_DYNAMIC
>   Mon, 10 Aug 2026 20:51:00 +0000
> - Distribution: CachyOS
> - Architecture: x86_64
> - Kernel tainted: no (/proc/sys/kernel/tainted = 0)
> - WiFi hardware: MediaTek MT7925 (mt7925e driver, mt76 core),
>   WM Firmware Build 20260605184805, ASIC revision 79250000
> - Access point: AVM FritzBox 5690 Pro, FRITZ!OS 8.25
> 
> Related community discussion:
> https://discuss.cachyos.org/t/mt7925-wifi-7-mlo-breaks-connectivity-on-7-1-x-mt76-regression/31972
> (I am the thread starter; several other users report matching
> symptoms with different hardware/APs)
> 
> Possibly related (different symptom, same 6GHz/MT7925 area, worth
> checking for a common root cause):
> Bug 221627 - MT7925E - System locks up with flashing caps lock
> (comment 1 there: "caused by switching between AP's with the same
> 6GHz wifi name")
> 
> Attachments (will add to this ticket):
> - Full incident logs for all four reproductions (dmesg + journalctl
>   + mt76 debugfs time series across each freeze)
> - iw station dump / iw link output during freeze
> - Kernel .config
> 
> Note: checked bug 220424 (mlo_sta_cmd/sta_cmd regression) before filing -
> different symptom (persistent near-zero throughput vs. our intermittent
> full stall with healthy link stats) and different root cause (broadcast
> wtbl hdr_trans_tlv handling). That fix landed in 6.16.6/6.17-rc5, well
> before the kernel versions tested here, so it is not the cause of this
> issue.
> 
>