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

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 <[email protected]>:
>
>> 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