MT7922 [14c3:7922]: tmac=4 (~2 dBm) TX power clamp on ASUS GA503RM — ~50% tx retries, 450-550 Mbps vs 600 on Windows

[sagunkayastha]

Summary

ASUS ROG Zephyrus G15 GA503RM (AMD Ryzen 9 6900HS, BIOS GA503RM.319), integrated MT7922 [14c3:7922]. The firmware TX power table shows tmac = 4 (0.5 dB units ≈ 2 dBm) for every OFDM/HT/VHT/HE rate while the eeprom rows allow 32–40 (16–20 dBm). Under load: ~50% tx retries at −42 dBm on a clean, exclusive channel; TCP throughput plateaus around 440–550 Mbps. Same laptop on Windows 11, same AP/channel: ~600 Mbps. Carried over from openwrt/mt76#1107 at @morrownr's request.

                      6m     9m    12m    18m    24m    36m    48m    54m
OFDM (eeprom)   :     39     39     39     39     36     36     36     34
OFDM (tmac)     :      4      4      4      4      4      4      4      4

Environment

• Kernel 7.1.4 mainline (also reproduced on Ubuntu 7.0.0-28)
• morrownr/mt76 installed via install-driver.sh, verified with check-driver.sh (all 5 _git modules, device bound to mt7921e_git)
• Firmware WIFI_RAM_CODE_MT7922_1.bin build 20260605 (also reproduced on 20260224)
• Regdomain US (30 dBm allowed on the test channel, 5 GHz ch 157/80 MHz)
• iw dev wlan0 info reports txpower 3.00 dBm

Reproduce

1. Associate to a 5 GHz AP, US regdomain.
2. cat /sys/kernel/debug/ieee80211/phy*/mt76/txpower_sku → observe tmac=4 across all rate rows.
3. Load test (12 parallel HTTP downloads), sample iw dev wlan0 station dump deltas → tx retries ≈ 50% of tx packets; throughput 440–550 Mbps vs ~600 on Windows on the same AP.

Already ruled out (no effect on tmac)

• disable_clc=1 with the full mt76 module stack unloaded first (this fixed Debian bug #1105211 on an ASUS Vivobook with the same chip — different platform, different outcome)
• ACPI SAR: DSDT has MTCL/MTDS/MTGS; MTDS static limits decode to 8–14.5 dBm; binary-patched MTDS to 22 dBm via initrd ACPI table upgrade (verified live in /sys/firmware/acpi/tables/DSDT) — tmac unchanged
• iw dev wlan0 set txpower fixed 2000 (accepted, no effect), iw phy set sar_specs (no SAR capability advertised), regdomain re-set
• deep-sleep=0 / runtime-pm=0 via debugfs (helps throughput slightly; tmac unchanged), NM powersave off, Bluetooth rfkill'd, ASPM disabled
• CPU >90% idle during tests; scans show the channel exclusive to this AP

Questions

1. Is tmac the final per-rate limit programmed into the MAC, or an offset/backoff table?
2. If final: what input besides eeprom / CLC / regdomain / ACPI SAR can drive it to 4 on this platform?

Full txpower_sku dump, eeprom dump, ACPI tables, and monitor-mode pcaps available on request.

[Lucid-Duck]

I've got the same chip here (AMD RZ616, which is an MT7922) on the same firmware build, and I can't reproduce this. On channel 157 with reg US my table shows tmac at 42, about 21 dBm. So it's probably not the chip, the firmware build, or the eeprom, as yours matches mine.

To your first question: tmac is the real limit as far as the firmware is concerned. That debugfs file asks the firmware what it's enforcing, so a flat 4 means it believes it's capping you at 2 dBm, and your retry numbers suggest it really is.

Here's my suspicion. An AP can tell clients to limit their transmit power (part of 802.11h, there's a power constraint field in the beacon, and some vendors have their own version of it). Linux honors that, and it would beat everything you tried: it wins over iw set txpower, it has nothing to do with CLC or the SAR tables, and the driver takes that one number and applies it to every rate, which is the flat table you're seeing. The 3.00 dBm from iw would be the same number surfacing on the host side.

Two quick things would prove it or rule it out. Fresh boot, set reg US, and cat txpower_sku before you connect to anything: if it looks normal there and only collapses after you associate to the XB8, it's the AP. And iw dev wlan0 scan dump, looking at the XB8's entry for a "Power constraint:" line and the country info. That gateway already sends a broken basic HT-MCS set, so its beacons are worth a close look.

If it does turn out to be the AP, there's still a driver conversation to have about why userspace can't override it, but the data comes first.

[sagunkayastha]

Some progress — this might be coming from the ACPI SAR geo table handling rather than the AP. mac80211's per-link debugfs shows ap_power_level=30, user unset, txpower=30 dBm even while mt76 reports 1 dBm, so the beacon seems innocent.

This GA503RM's DSDT has MTDS = 1C 1D 1D 19 19 10 10 11 10 10 11 and MTGS = 4D 54 47 53 01 00 03 + 01 1C 00 1D 00 11 00 02 3C 3C 3C 3C 3C 3C 03 3C 3C 3C 3C 3C 3C. If I'm reading it right, that MTGS body looks like the v2 layout (28 bytes: names/version/rsvd/nr_tbl=3, then 3 × 7-byte entries with three {pwr,offset} bands each), but its version byte is 1 — so mt792x_asar_get_geo_pwr() would parse it with the 5-byte v1 struct. If that's what happens, the misalignment puts a 0x00 in the FCC/5GHz slot: geo_power=0, min(geo_power, dyn_power)=0, frp.power=0, and the firmware floors at ~2 dBm — which would match the flat tmac=4.

Two experiments via initrd ACPI table override seem consistent with this: raising the MTDS limits to 22 dBm changed nothing (min with 0 would stay 0), while renaming MTDS/MTGS/MTCL so the driver skips SAR entirely restored everything — tmac 4→39, txpower 23 dBm, TX holds HE-MCS 11, and throughput is now 550–600 Mbps, same as Windows on this laptop.

[Lucid-Duck]

@sagunkayastha I walked your bytes through mt792x_acpi_sar.c and it comes out the way you read it. One step is different from your description, though: the driver never reads MTGS's own version byte at all. Every SAR table gets parsed with whatever layout the MTCL version byte declares, so a v2-shaped MTGS gets the v1 read as long as MTCL says 1.

The v1 header is 6 bytes instead of 7, so tbl[0] starts one byte early and the FCC entry's 5 GHz slot comes out as pwr 0x00. min(geo_power, dyn_power) with geo_power at 0 leaves frp.power at 0, which is your flat tmac 4. The length check doesn't catch any of this because (28 - 6) / 5 is integer division, giving 4 entries, legal, and nr_tbl is never compared against anything. That lines up with both of your tests too, since raising MTDS can't matter while it's min'd against 0, and renaming the tables away skips SAR completely.

The one byte I haven't seen is your MTCL version. Can you post the MTCL bytes too? If that says 1, the whole chain is accounted for.

I diffed this parser against mainline and it's byte-identical, so this isn't something the out-of-tree build did. The BIOS table is malformed either way you read it, and the driver trusts the version byte without checking it against the table length. Renaming the tables is a reasonable way to run until there's a real fix.

[sagunkayastha]

Here's MTCL:

MTCL: 4D 54 43 4C 01 01 D1 80 41 18 00 00 00 00 00 00 00 00 00

The byte after the MTCL name is 01 — the version you were expecting. So every SAR table gets the v1 parse regardless of its own shape, and the v2-shaped MTGS gets read as v1, which is where the one-byte-early misalignment comes from.

The other two:

MTGS: 4D 54 47 53 01 00 03 01 1C 00 1D 00 11 00 02 3C 3C 3C 3C 3C 3C 03 3C 3C 3C 3C 3C 3C
MTDS: 4D 54 44 53 01 00 01 01 1C 1D 1D 19 19 10 10 11 10 10 11