[BUG] mt76/mt7921e (MT7922): bulk TX transfers stall irrecoverably until driver reload — multiple apps , multiple APs, two firmware versions

Hi,

I''m reporting a severe reliability bug in mt7921e (MediaTek MT7922, AMD 
RZ616)
on kernel 7.0.0-30-generic (Ubuntu 26.04). I have not seen this exact 
failure
mode reported to this list; a similar report exists only in a distro tracker
(Red Hat Bugzilla #2459017, "Severe download speed degradation until 
reboot or
driver reload", status NEW since April 2026, apparently never forwarded 
here).

== HARDWARE / SOFTWARE ==
- WiFi: MediaTek MT7922 [14c3:7922], AzureWave subsystem [1a3b:5911], PCIe
- Driver: mt7921e (in-tree mt76), kernel 7.0.0-30-generic
- Firmware tested BOTH: build 20260224103233 AND build 20260724143402
(latest from linux-firmware as of Aug 2026) — bug identical on both
- APs tested: TP-Link Deco M4R (802.11ac, WPA2) and Pixel 8 Pro hotspot
- Control machine: same location, same APs, same peer device, same apps —
laptop with Intel WiFi (iwlwifi): ZERO issues ever

== SYMPTOM ==
Any sustained bulk transfer (KDE Connect file send ~100MB, adb wireless
install, plain TCP file share) stalls partway (typically 10–70%) and the
application eventually times out and fails. Happens on multiple apps, so it
is not app-specific. Interactivity (ICMP, small traffic, internet 
speedtests)
remains perfect throughout the stalls.

Critical detail: PHONE→LAPTOP direction works 100%. Only LAPTOP→PHONE
(bulk TX toward the AP) triggers it. On the Intel laptop both directions
work flawlessly on the identical network.

== EVIDENCE ==

1) TX retry explosion + rate collapse during stalls (iw station dump):
- tx retries: 208,941 → 247,117 within minutes of transfer attempts
- tx bitrate collapses 866.7 MBit/s (VHT-MCS 9, 80MHz, NSS2)
→ 121.5 MBit/s (VHT-MCS 6, 40MHz, NSS1) mid-stall
- signal: -51 to -58 dBm (excellent, so not RF)

2) Beacon-loss storms correlated with stalls (wpa_supplicant):
- 3,934 CTRL-EVENT-BEACON-LOSS events in one afternoon, including
25+ seconds of continuous beacon loss (12:15:35–12:15:59)
- card stops hearing the AP entirely while gateway ICMP stays 4–8ms
in adjacent windows

3) Socket-level capture during a stall (ss -tnie, 2s sampling):
- transfer socket frozen: receive queue stuck at exactly 2,122,768
bytes for 70+ seconds; kernel buffers full, application wedged
- during the same window: ping to peer 5–9ms, ping to gateway 3–5ms,
zero beacon loss, healthy tx rate — network provably clean while
the transfer is dead

4) Recovery: ONLY a driver reload recovers the link
(modprobe -r mt7921e && modprobe mt7921e). After reload, transfers
work again — sometimes for minutes, sometimes hours — then degrade
again under bulk TX. This is 100% reproducible.

== RULED OUT ==
- PCIe ASPM L1 (disable_aspm=Y applied; latency spikes fixed, stalls remain)
- NM/wpa_supplicant power save (power_save off; stalls remain)
- Chip deep-sleep + runtime-pm (debugfs flags toggled; no effect on stalls)
- TX pacing/burstiness (tc tbf 30mbit + tcp_limit_output_bytes=128KB; 
stalls)
- RTS/CTS (rts 512; stalls)
- AP firmware (TP-Link Deco updated 1.5.0→1.6.1; stalls)
- WiFi firmware (two builds tested as above; stalls on both)
- Peer device power management (fails with peer screen on, app foreground)
- Roaming (BSSID pinned; stalls)

The trigger is specifically SUSTAINED BULK TX from the MT7922. RX-heavy
loads (internet downloads at full speed) do NOT trigger it. This smells
like a TX path / aggregation state issue in the driver or firmware
(A-MPDU/B-A session state?) that progressively wedges the MAC until reset.

Kernel log during one storm:
[134991.282223] mt7921e 0000:63:00.0: disabling ASPM L1
(no firmware crash lines, no page_pool errors, no other warnings)

Happy to provide full logs (iw dumps, ss captures, journalctl excerpts,
ping timelines) on request, or to test patches on this hardware.

Regards,