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

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

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

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

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

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

[Jonas Hort]

Filed as: https://bugzilla.kernel.org/show_bug.cgi?id=221884


Summary: WiFi 7 MLO (5GHz+6GHz) on MT7925 silently stops passing traffic
after a few minutes, while the driver continues to report a fully
healthy link. Root cause appears to be a stalled WFDMA0 TX hardware
queue. Reproduced on both linux 7.1.8 (stable) and 7.2.0-rc7 (mainline
pre-release), not fixed as of rc7. Disabling the 6GHz radio on the
access point eliminates the freeze entirely in my testing.

This is a regression: reported by multiple users on the CachyOS forum
as broken starting with the 7.1.x kernel line; earlier kernels
(6.18.x longterm) are reported to work fine. I have not yet performed
a commit-level bisection but can if guided on the best approach given
the AP-side 6GHz dependency.

--- Detailed description ---

Symptom:
When connected via MLO (Multi-Link Operation, EHT/WiFi 7) with two
active links - one on 5GHz and one on 6GHz - network traffic silently
stops after a few minutes of normal use (web browsing, etc). The
connection continues to show as healthy:

- `iw link` / `iw station dump` report the connection as associated,
  authenticated, good signal (-60 to -65 dBm), high negotiated
  bitrate (800-1700 Mbit/s), 0 tx retries, 0 tx failed.
- Nothing is logged to dmesg/journalctl at the time of the freeze.
- Ping to the gateway shows 100% packet loss for several minutes,
  until the connection eventually recovers on its own.

I built a small watchdog script (ping-based failure detection + live
kernel log monitoring) to catch the freeze automatically and sample
mt76 debugfs state repeatedly across the event. This revealed the
actual mechanism:

`/sys/kernel/debug/ieee80211/phy0/mt76/xmit-queues` shows the WFDMA0
hardware TX queue's `tail` pointer completely frozen while `head`
keeps advancing - i.e. packets keep getting enqueued but the firmware
stops draining the queue. RX stops in the same instant (rx byte/packet
counters in `iw station dump` freeze completely). No tx retries or tx
failures are ever reported by the driver, so it does not appear to
notice the stall itself.

Example from one incident (kernel 7.2.0-rc7):
  t+1s:  WFDMA0: queued=130 head=390 tail=260   rx bytes=184791894
  t+9s:  WFDMA0: queued=148 head=408 tail=260   rx bytes=184791894 (unchanged)

`tail` never advances during the whole stall window while `head`
keeps growing - the queue is being filled but never drained.

Reproduced this exact signature four times total (twice on 7.1.8-1,
twice on 7.2.0-rc7-1), always with MLO 5GHz+6GHz active, always
within 3-5 minutes of normal use.

6GHz correlation:
My MLO links are 5GHz (5180 MHz) + 6GHz (varies, e.g. 6135 MHz).
Fully disabling the 6GHz radio on the access point (FritzBox 5690
Pro, FRITZ!OS 8.25 - not just client-side band restriction via
NetworkManager, which does not reliably suppress the second MLO
link) results in 30+ minutes of clean operation with no freeze.
Re-enabling 6GHz reproduces the freeze again within minutes.

Regression info:
Multiple users on the CachyOS forum report this started with the
7.1.x kernel line; the previous longterm kernel (6.18.x) is reported
to work fine by another user with different affected hardware
(different AP). I have not personally tested 6.18.x myself, and have
not performed a commit-level bisection yet - happy to do so if
pointed toward the most likely area of the driver, given the AP-side
6GHz dependency makes a fully automated bisection awkward.

Steps to reproduce:
1. Connect to an AP advertising WiFi 7 MLO with 5GHz+6GHz link
   options, so the client negotiates both links.
2. Use the connection normally (web browsing is sufficient).
3. Within roughly 3-5 minutes, new connections start hanging;
   existing traffic stops.
4. Check `iw link` - link still reports as connected/healthy.
5. Check `/sys/kernel/debug/ieee80211/phy*/mt76/xmit-queues` -
   WFDMA0 tail pointer frozen while head continues to advance.

Environment:
- Kernel: linux-cachyos 7.1.8-1 and linux-cachyos-rc 7.2.0-rc7-1
  (CachyOS, near-vanilla Arch-based build)
- cat /proc/version:
  Linux version 7.2.0-rc7-1-cachyos-rc (linux-cachyos-rc@cachyos)
  (clang version 22.1.8, LLD 22.1.8) #1 SMP PREEMPT_DYNAMIC
  Mon, 10 Aug 2026 20:51:00 +0000
- Distribution: CachyOS
- Architecture: x86_64
- Kernel tainted: no (/proc/sys/kernel/tainted = 0)
- WiFi hardware: MediaTek MT7925 (mt7925e driver, mt76 core),
  WM Firmware Build 20260605184805, ASIC revision 79250000
- Access point: AVM FritzBox 5690 Pro, FRITZ!OS 8.25

Related community discussion:
https://discuss.cachyos.org/t/mt7925-wifi-7-mlo-breaks-connectivity-on-7-1-x-mt76-regression/31972
(I am the thread starter; several other users report matching
symptoms with different hardware/APs)

Possibly related (different symptom, same 6GHz/MT7925 area, worth
checking for a common root cause):
Bug 221627 - MT7925E - System locks up with flashing caps lock
(comment 1 there: "caused by switching between AP's with the same
6GHz wifi name")

Attachments (will add to this ticket):
- Full incident logs for all four reproductions (dmesg + journalctl
  + mt76 debugfs time series across each freeze)
- iw station dump / iw link output during freeze
- Kernel .config

Note: checked bug 220424 (mlo_sta_cmd/sta_cmd regression) before filing -
different symptom (persistent near-zero throughput vs. our intermittent
full stall with healthy link stats) and different root cause (broadcast
wtbl hdr_trans_tlv handling). That fix landed in 6.16.6/6.17-rc5, well
before the kernel versions tested here, so it is not the cause of this
issue.

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

[Thorsten Leemhuis]

On 8/14/26 16:04, Jonas Hort wrote:
> Filed as: https://bugzilla.kernel.org/show_bug.cgi?id=221884
> 
> Summary: WiFi 7 MLO (5GHz+6GHz) on MT7925 silently stops passing traffic
> after a few minutes, while the driver continues to report a fully
> healthy link. Root cause appears to be a stalled WFDMA0 TX hardware
> queue. Reproduced on both linux 7.1.8 (stable) and 7.2.0-rc7 (mainline
> pre-release), not fixed as of rc7. Disabling the 6GHz radio on the
> access point eliminates the freeze entirely in my testing.

Not my area of expertise, but there was one patch was reverted on
Thursday that is somewhat related
(https://git.kernel.org/torvalds/c/3aa1dcaa4f6f5ae08936491e08bd456f331f2d40
), but that was more about shutdown/module unload aiui and likely
something else.

But there were other reports that sounds somewhat related (but careful,
I might send you on the wrong track here; CCing Devin, who wrote two of
the following messages):

https://lore.kernel.org/linux-wireless/20260629083543.153564-1-jb.tsai@mediatek.com/
https://lore.kernel.org/linux-wireless/20260804185118.19705-1-lucid_duck@justthetip.ca/
https://lore.kernel.org/all/20260812155811.10950-1-lucid_duck@justthetip.ca/

Ciao, Thorsten
> This is a regression: reported by multiple users on the CachyOS forum
> as broken starting with the 7.1.x kernel line; earlier kernels
> (6.18.x longterm) are reported to work fine. I have not yet performed
> a commit-level bisection but can if guided on the best approach given
> the AP-side 6GHz dependency.
> 
> --- Detailed description ---
> 
> Symptom:
> When connected via MLO (Multi-Link Operation, EHT/WiFi 7) with two
> active links - one on 5GHz and one on 6GHz - network traffic silently
> stops after a few minutes of normal use (web browsing, etc). The
> connection continues to show as healthy:
> 
> - `iw link` / `iw station dump` report the connection as associated,
>   authenticated, good signal (-60 to -65 dBm), high negotiated
>   bitrate (800-1700 Mbit/s), 0 tx retries, 0 tx failed.
> - Nothing is logged to dmesg/journalctl at the time of the freeze.
> - Ping to the gateway shows 100% packet loss for several minutes,
>   until the connection eventually recovers on its own.
> 
> I built a small watchdog script (ping-based failure detection + live
> kernel log monitoring) to catch the freeze automatically and sample
> mt76 debugfs state repeatedly across the event. This revealed the
> actual mechanism:
> 
> `/sys/kernel/debug/ieee80211/phy0/mt76/xmit-queues` shows the WFDMA0
> hardware TX queue's `tail` pointer completely frozen while `head`
> keeps advancing - i.e. packets keep getting enqueued but the firmware
> stops draining the queue. RX stops in the same instant (rx byte/packet
> counters in `iw station dump` freeze completely). No tx retries or tx
> failures are ever reported by the driver, so it does not appear to
> notice the stall itself.
> 
> Example from one incident (kernel 7.2.0-rc7):
>   t+1s:  WFDMA0: queued=130 head=390 tail=260   rx bytes=184791894
>   t+9s:  WFDMA0: queued=148 head=408 tail=260   rx bytes=184791894 (unchanged)
> 
> `tail` never advances during the whole stall window while `head`
> keeps growing - the queue is being filled but never drained.
> 
> Reproduced this exact signature four times total (twice on 7.1.8-1,
> twice on 7.2.0-rc7-1), always with MLO 5GHz+6GHz active, always
> within 3-5 minutes of normal use.
> 
> 6GHz correlation:
> My MLO links are 5GHz (5180 MHz) + 6GHz (varies, e.g. 6135 MHz).
> Fully disabling the 6GHz radio on the access point (FritzBox 5690
> Pro, FRITZ!OS 8.25 - not just client-side band restriction via
> NetworkManager, which does not reliably suppress the second MLO
> link) results in 30+ minutes of clean operation with no freeze.
> Re-enabling 6GHz reproduces the freeze again within minutes.
> 
> Regression info:
> Multiple users on the CachyOS forum report this started with the
> 7.1.x kernel line; the previous longterm kernel (6.18.x) is reported
> to work fine by another user with different affected hardware
> (different AP). I have not personally tested 6.18.x myself, and have
> not performed a commit-level bisection yet - happy to do so if
> pointed toward the most likely area of the driver, given the AP-side
> 6GHz dependency makes a fully automated bisection awkward.
> 
> Steps to reproduce:
> 1. Connect to an AP advertising WiFi 7 MLO with 5GHz+6GHz link
>    options, so the client negotiates both links.
> 2. Use the connection normally (web browsing is sufficient).
> 3. Within roughly 3-5 minutes, new connections start hanging;
>    existing traffic stops.
> 4. Check `iw link` - link still reports as connected/healthy.
> 5. Check `/sys/kernel/debug/ieee80211/phy*/mt76/xmit-queues` -
>    WFDMA0 tail pointer frozen while head continues to advance.
> 
> Environment:
> - Kernel: linux-cachyos 7.1.8-1 and linux-cachyos-rc 7.2.0-rc7-1
>   (CachyOS, near-vanilla Arch-based build)
> - cat /proc/version:
>   Linux version 7.2.0-rc7-1-cachyos-rc (linux-cachyos-rc@cachyos)
>   (clang version 22.1.8, LLD 22.1.8) #1 SMP PREEMPT_DYNAMIC
>   Mon, 10 Aug 2026 20:51:00 +0000
> - Distribution: CachyOS
> - Architecture: x86_64
> - Kernel tainted: no (/proc/sys/kernel/tainted = 0)
> - WiFi hardware: MediaTek MT7925 (mt7925e driver, mt76 core),
>   WM Firmware Build 20260605184805, ASIC revision 79250000
> - Access point: AVM FritzBox 5690 Pro, FRITZ!OS 8.25
> 
> Related community discussion:
> https://discuss.cachyos.org/t/mt7925-wifi-7-mlo-breaks-connectivity-on-7-1-x-mt76-regression/31972
> (I am the thread starter; several other users report matching
> symptoms with different hardware/APs)
> 
> Possibly related (different symptom, same 6GHz/MT7925 area, worth
> checking for a common root cause):
> Bug 221627 - MT7925E - System locks up with flashing caps lock
> (comment 1 there: "caused by switching between AP's with the same
> 6GHz wifi name")
> 
> Attachments (will add to this ticket):
> - Full incident logs for all four reproductions (dmesg + journalctl
>   + mt76 debugfs time series across each freeze)
> - iw station dump / iw link output during freeze
> - Kernel .config
> 
> Note: checked bug 220424 (mlo_sta_cmd/sta_cmd regression) before filing -
> different symptom (persistent near-zero throughput vs. our intermittent
> full stall with healthy link stats) and different root cause (broadcast
> wtbl hdr_trans_tlv handling). That fix landed in 6.16.6/6.17-rc5, well
> before the kernel versions tested here, so it is not the cause of this
> issue.
> 
> 

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

[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

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

[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

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

[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.

$ 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

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

[Devin Wittmayer]

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