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

[Jonas Hort <jonas.hort@posteo.de>]

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@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