mt7925e: firmware 20260813113118 regresses low-RSSI 5 GHz; 20260605184805 restores 0% loss

Open
  • Is something wrong?
#1,128 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
c, linux
Domain
networking, operating-systems

Research direction

Start with the mt7925e firmware-loading path and the two named linux-firmware blob pairs from commits 3c11e660d3a8 and bd1c66cf. Reproduce the A/B comparison using ethtool, iw, ping, and curl at the stated RSSI, then review the routed linux-wireless and linux-firmware reports. Done means the regression boundary is confirmed and maintainers have a validated firmware fix or rollback.

Written by the indexing model from the issue text.

Description

Summary

Routing note: This is a Linux mt7925e / linux-firmware regression, not an OpenWrt-specific issue. It was filed here because this repository actively develops the same mt76/mt7925 driver and reaches several of its maintainers. The current Linux MAINTAINERS route is [email protected]; binary firmware reports go to [email protected]. This issue is retained as a secondary driver-maintainer cross-reference while the report is routed to those lists.

A controlled firmware-only A/B test on an MT7925/RZ717 PCIe adapter (14c3:0717) isolated a severe low-RSSI 5 GHz regression in the firmware added by linux-firmware commit 3c11e660d3a8 / MR !1191.

With WM firmware build 20260813113118, the link remains associated at about -70 dBm, but traffic suffers 23–29% packet loss, gateway RTT in the 1.2–1.8 second range, and HTTPS timeouts. Removing only those overlay blobs and reloading the same driver causes firmware build 20260605184805 to load; on the same AP/BSSID and at the same RSSI, packet loss becomes 0%, gateway RTT falls to 4.237 ms, and all HTTPS probes complete.

Hardware / software
  • Device: MediaTek MT7925 / AMD RZ717 Wi-Fi 7 160 MHz PCIe
  • PCI ID: 14c3:0717; ASIC revision 79250000; HW/SW version 0x8a108a10
  • Driver: in-tree mt7925e
  • Kernel: 7.3.0-rc1, x86_64, PREEMPT_DYNAMIC
  • Distribution: Arch-derived (CachyOS)
  • NetworkManager 1.58.1; wpa_supplicant 2.12; WPA2-PSK
  • Test link: 5 GHz channel 161 / 5805 MHz, VHT40 (non-MLO)
  • RSSI during the direct A/B: approximately -70 dBm
  • Regulatory domain: BR; Wi-Fi power save off in both cases
  • Same machine, AP, BSSID, position, connection profile, kernel and driver throughout
  • Default ASPM/CLC behavior; no experimental mt7925 module parameters
Firmware identities
Blob set WM build Patch build Result
Newer linux-firmware overlay 20260813113118 20260813113015a Regressed
Distribution-packaged blobs 20260605184805 20260605184651a Good

The good pair came from linux-firmware commit bd1c66cf.

Uncompressed SHA-256:

Blob Good (20260605) Regressed (20260813)
WIFI_MT7925_PATCH_MCU_1_1_hdr.bin 089dd0252a7eb95feed55950ad0fd9e6f751a07b4cf22273de722b73fa50d49e 8eb46014d2a6b4124472eee7476d995008a6f40b1daffef87eb42f30d98699e1
WIFI_RAM_CODE_MT7925_1_1.bin 7e4ed27d1e9fe21cdefda35a22da32137b2473fada350617fb603489af19346a 23ff53b4bb639b30481e2e06bb1688569ad1ba971b897936db539882abfbd120
Controlled A/B results
Measurement Firmware 20260813113118 Firmware 20260605184805
RSSI about -70 dBm about -70 dBm
Gateway packet loss 23–29% across repeated runs 0/20 (0%)
Gateway average RTT 1.2–1.8 s 4.237 ms
Internet packet loss about 29% 0/10 (0%)
Internet average RTT about 3.7 s 15.109 ms
Three bounded 1 MB HTTPS downloads 2 connection timeouts; third stopped at 293,689/1,000,000 bytes after 8 s (36.7 kB/s) 3/3 complete at 4.18–5.25 MB/s

After making the rollback persistent, a longer confirmation at -70 to -72 dBm produced 50/50 gateway replies (average 4.236 ms), 20/20 Internet replies (average 15.548 ms), and three more complete 1 MB HTTPS downloads at 3.91–4.60 MB/s. At -74 dBm, a separate acceptance run also had 0% gateway loss.

Reproduction
  1. Install the two Wi-Fi blobs from linux-firmware commit 3c11e660d3a8 in the firmware override path so they take precedence over the packaged blobs.
  2. Reboot (or safely reload mt7925e) and reconnect to a 5 GHz AP.
  3. Confirm with ethtool -i <iface> that the firmware version ends in 20260813113118.
  4. Record iw dev <iface> link, then run:
ping -n -c 20 -i 0.2 -W 2 <gateway>
ping -n -c 10 -i 0.3 -W 3 1.1.1.1
for n in 1 2 3; do
  curl --silent --show-error --output /dev/null \
    --connect-timeout 3 --max-time 8 \
    --write-out "probe=$n http=%{http_code} bytes=%{size_download} time=%{time_total}s speed=%{speed_download}B/s\n" \
    'https://speed.cloudflare.com/__down?bytes=1000000'
done
  1. Replace only the two 20260813 Wi-Fi blobs with the 20260605 pair from commit bd1c66cf, then reboot/reload and reconnect to the same AP/BSSID.
  2. Confirm firmware 20260605184805 and repeat the commands.

Only the selected Wi-Fi firmware blobs changed between the runs. The A/B operation used a recovery wrapper and completed within minutes, preserving the AP position and radio conditions. Bluetooth firmware was not reloaded during the A/B.

Reversible workaround

Pin the two MT7925 Wi-Fi blobs from bd1c66cf / build 20260605, then reboot or reload mt7925e. On this system, moving the 20260813 override outside the active firmware search path makes the driver fall back to the known-good packaged pair. No kernel parameters are required.

Additional observations
  • The regressed firmware stays associated; this is transport collapse, not merely failure to connect.
  • RSSI is effectively unchanged across A/B, so signal strength alone does not explain the difference.
  • No driver timeout/reset/AER accompanied the regression; it fails mostly silently.
  • With the good firmware, final station counters showed zero TX failures, beacon loss, and RX misc drops.
  • This is likely relevant to kernel Bugzilla #219429, but the firmware-only A/B gives a narrower regression boundary.
  • Related mt76 issue #1108 reports latency under contention on the older firmware; this report is distinct because it directly bisects a new binary firmware update at the same RSSI/AP.

The original firmware submission thread has Message-ID <[email protected]>.

Questions for maintainers
  1. Is 20260813113118 known to regress low-signal 5 GHz transport on MT7925/RZ717?
  2. Should linux-firmware revert/pin these MT7925 Wi-Fi blobs while a fixed build is prepared?
  3. Which additional capture would be most useful: sanitized A/B logs, iw station dump, mt76 debugfs state, trace-cmd events, or firmware debug logging?
  4. Is there a newer test firmware available that can be validated with the same automated A/B procedure?

I can provide the recovery-safe A/B script and complete sanitized output if useful.

Dominant language
C
Stars
895
Forks
461
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openwrt/mt76

All issues in openwrt/mt76

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.