RE: [BUG] wifi: rtw89: firmware regression on RTL8922AE (0.35.80.3 vs 0.35.42.1)

Louis <[email protected]> wrote:
> Hardware: Realtek RTL8922AE (rtw89_8922ae driver)
> Also tested on: RTL8922AE-VS (same PCI ID: 10ec:8922)
> Systems: Lenovo Yoga 7 14AKP10 (Type 83JR) [laptop, PCIe],
>          desktop (RTL8922AE via M.2-to-PCIe adapter, replacing a
>          QCNFA765/ath11k card)
> Kernels tested: CachyOS default, CachyOS zen, Arch (vanilla),
>                 mainline LTS — regression reproduces identically
>                 on all of them, ruling out kernel version as a
>                 variable.
> 
> === ISSUE 1: Firmware regression, reproduced across two
>     linux-firmware releases ===
> 
> Known-good firmware:
>   Firmware version 0.35.42.1 (cc364c30), cmd version 1, type 1
>   Firmware version 0.35.42.1 (cc364c30), cmd version 1, type 3
> 
> Known-bad firmware:
>   Firmware version 0.35.80.3 (8ef4f0cf), cmd version 1, type 1
>   Firmware version 0.35.80.3 (8ef4f0cf), cmd version 1, type 3
> 
> Symptoms on the bad firmware (0.35.80.3):
>   - Intermittent disconnects on both 5GHz and 6GHz, under load or after 3-5 minutes
>     (observed most reliably during sustained transfer / speedtest)
>   - Recurring log line preceding drops:
>       "rtw89_8922ae 0000:03:00.0: sec cam entry is empty"

This says it can't find a corresponding security key entry, so 
I guess it happen after re-key. Can you enlarge the rekey
period of AP to see if anything change?

Since the firmware changes power save timing between the two 
firmware, so another try is to disable power save by:
   sudo iw wlan0 set power_save off

Did you enable Bluetooth at the same time? If so, please try
to disable it because firmware also changed some BT-coexistence
mechanism.

Also, can you share full kernel log?

>   - Followed by reassociation failures:
>       "wlan0: deauthenticated from <MAC> while associating
>        (Reason: 9=STA_REQ_ASSOC_WITHOUT_AUTH)"
>   - Ruled out as the cause before landing on firmware:
>       DFS channel-vacate events, router DCS (dynamic channel
>       selection), PCIe ASPM L1, GTK/group-rekey interval,
>       kernel choice (4 different kernels tested)
> 
> Reproduction:
>   1. Install current linux-firmware (rtw8922a_fw-4.bin loads,
>      version 0.35.80.3)
>   2. Sustained transfer / speedtest on 5GHz or 6GHz, wide channel
>      (160MHz+) — disconnect + "sec cam entry is empty" +
>      reason-9 reassoc failure within minutes
>   3. Move/delete the -3.bin and -4.bin firmware files so the
>      driver falls back to an earlier bundled version
>      (0.35.42.1 (cc364c30) loads) — stable indefinitely under
>      the same load/test conditions

By the way, I setup my environment (I use the latest driver) to run iperf3
with firmware 0.35.80.3 on 5GHz band for 999 seconds TX/RX respectively.
No disconnection.
Could you also do the same test with another AP (like hotspot of your phone)?

> 
> This was independently reproduced a second time after a
> subsequent linux-firmware update reintroduced the same -3/-4
> files — same fix (remove them, fall back to 0.35.42.1) resolved
> it identically both times. Confirms this isn't a one-off but a
> persistent regression carried across releases.
> 
> Happy to test candidate fixes or provide a fuller dmesg/pcap
> capture around a live drop if useful — I have the reproduction
> steps down to a few minutes reliably.
> 
> === ISSUE 2 (informational, not a bug report): MLO/MLSR real-world
>     test data ===
> 
> Tested the MLO patchset (MLSR — link-switching) with an AP
> broadcasting one SSID across 5GHz and 6GHz simultaneously.

What is the MLO patchset you mentioned?

> AP-side confirms the client associated on both bands at once.
> `iw dev wlan0 station dump` shows only a single active tx/rx
> bitrate pair at a time (consistent with MLSR link-switching
> rather than MLMR aggregation, as expected given the current
> patchset).
> 
> Real-world throughput/quality comparison from the same physical
> location (one interior wall between client and AP), same
> firmware (0.35.42.1):
> 
>   5GHz, 240MHz (160+80 non-contiguous), separate SSID:
>     RSSI: -34 to -57 dBm
>     MCS: steady EHT-MCS 8-11 (2 streams), occasionally EHT-MCS 13
>     iperf3 -P4: 728 Mbit/s aggregate, 81 retransmits/30s
> 
>   6GHz, 160MHz, separate SSID:
>     RSSI: -65 dBm (AP has no AFC — confirmed with vendor, LPI-only,
>           23dBm ceiling on 6GHz)
>     MCS: oscillating EHT-MCS 5-7 (2 streams)
>     iperf3 -P4: 889 Mbit/s aggregate, 800 retransmits/30s
>     (~8x more retransmits per Mbit/s than the 5GHz link)
> 
> Sharing in case it's useful data for prioritizing MLSR vs. MLMR
> work, or for anyone else's testing/comparison — not filing this
> half as a bug, more as real-world confirmation that link quality
> (not just raw throughput) matters for whichever link MLSR
> switching logic favors.

Currently, rtw89 has MLO capability (as you saw by iw) but we are
still cooking the rules to switch link though.

Ping-Ke