[regression] rtw89_8852be: silent RX stalls since v7.1; reverting bda294ed0ed0 appears to fix it

[Armin Breiteneder]

Hi,

I am hitting a reproducible WiFi regression with rtw89_8852be 
(RTL8852BE, 10ec:b852, CV:1 RFE:1, firmware 0.29.29.18) on Fedora 44.

Good: 7.0.14-201.fc44
Bad:  7.1.3-200.fc44, and v7.1 vanilla

Reverting bda294ed0ed0 ("wifi: rtw89: Drop malformed AMPDU frames with 
abnormal PN") on top of v7.1 appears to fix it -- the stalls are gone.

Symptom: every few minutes the RX data path stalls silently for 1-7 
minutes at a time. The radio link stays perfectly healthy -- still 
associated, signal unchanged (~-62 dBm), "tx failed" and "tx retries" 
both 0 (the AP ACKs every frame we send), "beacon loss" 0 -- and the 
station's rx_packets counter keeps climbing at ~23 frames/s. Yet almost 
nothing is delivered to the network stack. The kernel logs nothing at 
all. Then it recovers on its own, without re-association, and the whole 
backlog is delivered in one burst.

Quantified over one 54-second stall (mac80211 station counter vs. the 
napi_gro_receive tracepoint):
  frames received and counted from the AP : ~1230
  frames delivered to the network stack   :  ~211
  frames withheld                         : ~1000
  delivered in one interval on recovery   : +5070

Everything that does get through during the stall is broadcast/multicast 
only (ARP, IPv6 multicast, vendor ethertypes) -- exactly the traffic 
that bypasses Block-Ack reordering.

That fits the suspected commit: dropping a frame inside an A-MPDU leaves 
a hole in the sequence numbers, so the RX reorder buffer waits for 
something that never arrives, everything behind it piles up, and it is 
only released once a timeout fires. I have not verified this in the code 
beyond reading the commit, so please treat the mechanism as a hypothesis 
-- the revert result is the solid part.

The AP is a FRITZ!Box 4040 on channel 36 (5180 MHz, VHT80), non-DFS.

Already ruled out:
- Powersave: disabled (NetworkManager wifi.powersave=2, confirmed via iw).
- ASPM: disable_clkreq=y disable_aspm_l1=y disable_aspm_l1ss=y 
disable_ps_mode=y
  all set and confirmed active. The stall still occurs -- note this is the
  workaround that reportedly fixes the CachyOS case below; it does not 
help here.
- Signal / range / DFS: signal constant across the stall, channel is 
non-DFS.
- TX path: txf=0 and txr=0 throughout.
- Stable patches: "git log v7.1..v7.1.3 -- net/mac80211/ 
drivers/net/wireless/
  realtek/rtw89/" is empty, so this came in with the v7.1 merge window.

I could not find a way to trigger the stall on demand, so I could not 
bisect; the suspect was found by reading the v7.0..v7.1 commits touching 
the RX/AMPDU path and running a targeted revert test.

A regression with the same version boundary was reported against the 
CachyOS kernel: https://github.com/CachyOS/linux-cachyos/issues/921

Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=2501974

Happy to run a debug build or test patches -- I have the affected 
hardware and the failure shows up within minutes of normal use, so 
turnaround is fast.

#regzbot introduced: bda294ed0ed0

Thanks,
Armin