[REGRESSION] mt7925e: firmware 20260813113118 causes severe low-RSSI 5 GHz loss

[Mario Stanski Jr]

Hi,

I am reporting a severe low-RSSI 5 GHz regression in the MT7925 Wi-Fi
firmware added by linux-firmware commit 3c11e660d3a8 (MR !1191).

On an MT7925/RZ717 PCIe adapter [14c3:0717], WM build
20260813113118 remains associated at about -70 dBm, but traffic suffers
23-29% packet loss, 1.2-1.8 s average RTT to the gateway, and HTTPS
timeouts. Replacing only the two Wi-Fi blobs with the previous pair and
reloading the same in-tree mt7925e driver loads WM build 20260605184805.
On the same AP/BSSID, machine position, kernel, profile and RSSI, gateway
loss becomes 0% and average RTT becomes 4.237 ms.

Firmware-only A/B results:

                         20260813113118       20260605184805
Gateway packet loss      23-29%               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 1 MB HTTPS probes  2 connect timeouts;  3/3 complete,
                         1 partial timeout    4.18-5.25 MB/s

The partial newer-firmware probe received 293689/1000000 bytes in 8 s
(36702 B/s). After pinning the previous blobs, a longer confirmation at
-70 to -72 dBm returned 50/50 gateway replies (4.236 ms average), 20/20
Internet replies (15.548 ms average), and three further complete 1 MB
downloads at 3.91-4.60 MB/s. A separate acceptance run at -74 dBm also
had 0% gateway loss.

Environment:

  Device:          MediaTek MT7925 / AMD RZ717 Wi-Fi 7 PCIe
  PCI ID:          14c3:0717
  ASIC / HW-SW:    79250000 / 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
  Link:            WPA2-PSK, 5805 MHz/channel 161, VHT40, non-MLO
  Regulatory:      BR
  Power saving:    off in both runs
  Module params:   defaults; no experimental ASPM/CLC parameters

Firmware identities and uncompressed SHA-256:

  Regressed WM/Patch: 20260813113118 / 20260813113015a
  WIFI_RAM_CODE_MT7925_1_1.bin:
    23ff53b4bb639b30481e2e06bb1688569ad1ba971b897936db539882abfbd120
  WIFI_MT7925_PATCH_MCU_1_1_hdr.bin:
    8eb46014d2a6b4124472eee7476d995008a6f40b1daffef87eb42f30d98699e1

  Good WM/Patch: 20260605184805 / 20260605184651a
  WIFI_RAM_CODE_MT7925_1_1.bin:
    7e4ed27d1e9fe21cdefda35a22da32137b2473fada350617fb603489af19346a
  WIFI_MT7925_PATCH_MCU_1_1_hdr.bin:
    089dd0252a7eb95feed55950ad0fd9e6f751a07b4cf22273de722b73fa50d49e

The regressed firmware stays associated and no driver timeout/reset/AER
accompanied the failure. RSSI was effectively unchanged across the A/B.
Bluetooth firmware was not reloaded during the test.

The workaround is to pin the two Wi-Fi blobs from linux-firmware commit
bd1c66cfef5fb9cba15f1838a3fd222fb88a832b, then reboot or safely reload
mt7925e. No kernel parameters are required on this system.

References:

  Regression commit / MR:
  https://gitlab.com/kernel-firmware/linux-firmware/-/commit/3c11e660d3a8f8b35e12809b4b721a722b597148
  https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/1191

  Previous known-good commit:
  https://gitlab.com/kernel-firmware/linux-firmware/-/commit/bd1c66cfef5fb9cba15f1838a3fd222fb88a832b

  Original submission thread (Message-ID
  <20260818010915.445782-1-jb.tsai at mediatek.com>):
  https://lists.openwall.net/linux-kernel/2026/08/18/60

  Full sanitized report and reproduction commands:
  https://github.com/openwrt/mt76/issues/1128

  Related low-signal report:
  https://bugzilla.kernel.org/show_bug.cgi?id=219429

Could you please confirm whether 20260813113118 is known to regress
low-signal 5 GHz transport, and whether the blobs should be reverted
while a fixed build is prepared? I can provide the recovery-safe A/B
script, full sanitized output, mt76 debugfs state or traces, and can test
a replacement firmware with the same procedure.

Regards,
MJr