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

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