From: Alan Omar <alanomar1992@gmail.com>
To: linux-wireless@vger.kernel.org
Cc: linux-mediatek@lists.infradead.org, Felix Fietkau <nbd@nbd.name>,
Lorenzo Bianconi <lorenzo@kernel.org>
Subject: [BUG] mt76/mt7921e (MT7922): bulk TX transfers stall irrecoverably until driver reload — multiple apps, multiple APs, two firmware versions
Date: Tue, 25 Aug 2026 17:27:42 +0200 [thread overview]
Message-ID: <c0d9535c-ce42-4eea-bb5d-3ccb87b8a3ea@gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3796 bytes --]
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,
[-- Attachment #1.2: Type: text/html, Size: 4699 bytes --]
[-- Attachment #2: mt76-bug-evidence.tar.gz --]
[-- Type: application/gzip, Size: 3391 bytes --]
reply other threads:[~2026-08-25 15:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c0d9535c-ce42-4eea-bb5d-3ccb87b8a3ea@gmail.com \
--to=alanomar1992@gmail.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=nbd@nbd.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox