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

First, thanks to everyone helping out with this - really appreciate
the time you're all putting in.

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 - either by disconnecting and
reconnecting the WiFi connection, or by switching to my band-lock
workaround (forcing 5GHz-only, which disables MLO). What I can say
for certain: the system itself has never needed a reboot - it stays
fully responsive throughout, only the WiFi link itself needs manual
action to recover. Wanted to correct that record before it causes
confusion.

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. Fixed by
   disconnecting/reconnecting the WiFi connection fairly quickly.
- Freeze #2 (15:43): this time I deliberately waited longer before
   intervening. The trace shows several ROC events (rocabort, mloroc,
   rocwork) clustered together. Fixed by switching to the band-lock
   workaround (5GHz-only).
- Freeze #3 (16:15): no ROC activity again. Fixed by
   disconnecting/reconnecting the WiFi connection.

Uploaded all three logs to the bugzilla ticket if useful:
https://bugzilla.kernel.org/show_bug.cgi?id=221884

Still haven't gotten to confirming 6.18 as a clean baseline on my own
hardware - that's next on my list.

Am 16.08.26 um 22:48 schrieb Devin Wittmayer:
> On 15/08/2026 07:51, Thorsten Leemhuis wrote:
>> CCing Devin, who wrote two of the following messages
> Those are the mt7921 regd deadlock. mt7925 does not have it, there is no
> equivalent of the mt7921_mac_sta_add() call site that creates it.
>
> Worth ruling in or out before you bisect. mt7925 sets
> IEEE80211_MLD_CAP_OP_MAX_SIMUL_LINKS to 0 in mt7925/main.c. It is an N-1
> field, mt7996 sets MT7996_MAX_RADIOS - 1, so 0 means one simultaneous link,
> and mt7925/mcu.c then requests MT7925_ROC_REQ_MLSR_AG or _AA. MLSR is
> multi-link single radio: your two links share one radio, and ROC is what
> moves it between them.
>
> If 5 GHz is your deflink, your pair is named on that path in
> mt7925_mac_set_links():
>
> 	if (band == NL80211_BAND_2GHZ ||
> 	    (band == NL80211_BAND_5GHZ && secondary_band == NL80211_BAND_6GHZ)) {
> 		mt7925_abort_roc(...);
> 		mt7925_set_mlo_roc(...);
> 	}
>
> That one only runs at association. The path that can run mid-session is
> mt7925_change_vif_links(), which calls mt7925_set_mlo_roc() for each added
> link. Both reach mt7925_mcu_set_mlo_roc(), and all of this is the same in
> 7.1 and 7.2-rc7.
>
> Under your existing watchdog:
>
> 	cd /sys/kernel/debug/tracing
> 	echo 'r:mloroc mt7925_mcu_set_mlo_roc ret=$retval:s32' > kprobe_events
> 	echo 'r:rocabort mt7925_mcu_abort_roc ret=$retval:s32' >> kprobe_events
> 	echo 'p:rocwork mt7925_roc_work' >> kprobe_events
> 	echo 1 > events/kprobes/enable
>
> Association will fire mloroc once, so anything later is a mid-session
> switch. If the WFDMA0 tail freezes while one of those is in flight, it is a
> link switch that did not finish. If they are silent across a stall, the
> whole path is ruled out and that is worth as much.
>
> On the bisect itself: your 6.18 good point is second-hand, from different
> hardware and a different AP. Worth confirming on your own box before
> spending steps against it.
>
> Devin