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

Sun Aug 23 21:52:35 PDT 2026

On 8/23/26 22:54, Jonas Hort wrote:
> Bisect is done. First bad commit:
>
> ff643b81bc38eaff6c0ab783a62e4ba9e10d2476
> wifi: mt76: mt7925: pass mlink and mconf to sta_mld_tlv()
> Sean Wang, 2026-03-06
> https://patch.msgid.link/20260306232238.2039675-4-sean.wang@kernel.org

Then let's add Sean to the list of recipients. :-D

Sean, FWIW, this thread starts here:

https://lore.kernel.org/all/066b30cc-a9e6-4aeb-964d-71551e8ea3ef@posteo.de/t/#u

To quote the 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."

Ciao, Thorsten
> Bisected on vanilla, path-restricted to
> drivers/net/wireless/mediatek/mt76/mt7925/, using v7.0 as good and
> v7.1 as bad. Each step was booted and tested with MLO active
> (5GHz+6GHz, FritzBox 5690 Pro), and every "bad" verdict was confirmed
> by the WFDMA0 signature (tail frozen while head keeps advancing),
> not just by the connection dropping.
> 
>   ea757740dd87  pass WCID indices to bss_basic_tlv()      good (45 min
> clean)
>   ff643b81bc38  pass mlink and mconf to sta_mld_tlv()     bad (freeze
> after ~4 min)
>   dc019e3294c7  pass mlink to mcu_sta_update()            bad (freeze
> after ~3 min)
>   9e4d518a4707  pass mlink to mac_link_sta_remove()       bad (freeze
> after ~4 min)
>   cf9db836b1e0  pass mlink to set_link_key()              bad (freeze
> after ~4 min)
> 
> git bisect log and the incident logs for each step are available if
> useful - happy to attach them to the bugzilla ticket or send them
> here.
> 
> Let me know if you want anything else tested.
> 
> Thanks,
> Jonas
> 
> Am 22.08.26 um 22:18 schrieb Jonas Hort:
>> Quick update: v7.0 vanilla has been running clean for over 2 hours now
>> with MLO active (5GHz+6GHz, same FritzBox 5690 Pro), no freeze at all.
>>
>> Am 19.08.26 um 11:03 schrieb Jonas Hort:
>>> Thanks for the detailed breakdown.
>>>
>>> I'll build v7.0 vanilla and test it, as suggested. Fair warning
>>> though: I'm on vacation this week, so I'll pick this up next week.
>>> I've also never compiled a kernel before, so it'll likely take me a
>>> bit of trial and error the first time around - please bear with me
>>> if it takes a little longer than expected.
>>>
>>> Will report back once I have results.
>>>
>>> Thanks again,
>>> Jonas
>>>
>>> 19.08.2026 03:18:34 Devin Wittmayer <lucid_duck at justthetip.ca>:
>>>
>>>> Thank you very much, that answers both things.
>>>>
>>>> The ROC tracing is the more useful of the two even though it came back
>>>> negative. Two of the three freezes have no ROC activity in them at
>>>> all, so a
>>>> link switch that never finished cannot be what starts this. The
>>>> middle one
>>>> does have rocabort, mloroc and rocwork in it, but one out of three
>>>> makes
>>>> that look like the exception rather than the pattern. So the area I
>>>> sent you
>>>> looking at is out, and that is worth knowing before you spend nights on
>>>> builds.
>>>>
>>>> One other thing worth saying first. There is a five patch mt76
>>>> series on the
>>>> list at the moment and two of the patches look like they were
>>>> written for
>>>> exactly this bug. I do not think they were, and it is your own
>>>> numbers that
>>>> show it. The failure 4/5 fixes stops mt76_txq_schedule_list from
>>>> servicing
>>>> the queue, and the one 5/5 fixes stops mt76_txq_send_burst once the
>>>> non-AQL
>>>> count reaches its cap. Both of those keep frames from ever reaching the
>>>> hardware, so if either were your problem head would be sitting still
>>>> alongside tail. Yours does the opposite. Head climbs 390 to 408
>>>> while tail
>>>> stays at 260, so the frames are getting into the ring and nothing is
>>>> finishing them, which is the far end of the same path. 2/5 is a use
>>>> after
>>>> free when an interface goes away, so it does not fit either. I would
>>>> not
>>>> expect that series to change what you see.
>>>>
>>>> On the bisect I would build v7.0 next. There are 32 mt7925 commits
>>>> between
>>>> 7.0 and 7.1 and 19 of them are one run of work from Sean Wang,
>>>> reworking how
>>>> the driver tracks the per link mlink and WCID for an MLO station.
>>>> That is
>>>> the kind of change that fits a bug only showing up with two links
>>>> up. If
>>>> v7.0 comes back clean, that series is where I would look. If v7.0 is
>>>> already
>>>> broken then it is off the hook and 6.19 becomes the next split. The
>>>> mt76
>>>> core and mac80211 both moved in the same window, so mt7925 is where
>>>> I would
>>>> look first rather than the only place worth looking.
>>>>
>>>> Devin
>>>>
>>>> Am 17.08.26 um 23:34 schrieb Jonas Hort:
>>>>
>>>>> Quick follow-up: managed to confirm 6.18 as a clean baseline on my
>>>>> own hardware now (not just secondhand from others in the forum
>>>>> thread) - running Linux 6.18.42-1-cachyos-lts with MLO active
>>>>> (5GHz+6GHz, same FritzBox 5690 Pro) for 3 hours straight, no freeze
>>>>> at all.
>>>> Am 17.08.26 um 16:25 schrieb Jonas Hort:
>>>>
>>>>> One correction to how I described this earlier: the connection does
>>>>> NOT reliably self-heal on its own. I have manually intervened every
>>>>> single time to restore connectivity [...]
>>>>>
>>>>> Update on the ROC tracing: three real freezes captured now with the
>>>>> kprobes active (all confirmed via the WFDMA0 tail-frozen signature).
>>>>>
>>>>> - Freeze #1 (15:37): no ROC activity in the trace.
>>>>> - Freeze #2 (15:43): [...] The trace shows several ROC events
>>>>>    (rocabort, mloroc, rocwork) clustered together.
>>>>> - Freeze #3 (16:15): no ROC activity again.
>>>>>
>>>>> Uploaded all three logs to the bugzilla ticket if useful:
>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=221884