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

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.

$ uname -r
6.18.42-1-cachyos-lts

$ cat /proc/version
Linux version 6.18.42-1-cachyos-lts (linux-cachyos-lts@cachyos) (gcc
(GCC) 16.1.1 20260728, GNU ld (GNU Binutils) 2.47) #1 SMP
PREEMPT_DYNAMIC Mon, 03 Aug 2026 17:38:28 +0000

$ uptime -p
up 3 hours, 2 minutes

$ iw dev wlan0 link
Connected to 96:fc:7d:1a:7f:f0 (on wlan0)
     SSID: BKA Diensttelefon #52
     Link 1 BSSID b6:fc:7d:1a:7f:f0
         freq: 5200.0
     Link 2 BSSID c6:fc:7d:1a:7f:f0
         freq: 5975.0
MLD 96:fc:7d:1a:7f:f0 stats:
     RX: 448724534 bytes (2158217 packets)
     TX: 257975286 bytes (1259211 packets)
     signal: -64 dBm
     tx bitrate: 1921.5 MBit/s 160MHz EHT-MCS 9 EHT-NSS 2 EHT-GI 0

Regards,
Jonas

Am 17.08.26 um 16:25 schrieb Jonas Hort:
> 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