Description of problem:
Since kernel 7.1.x my WiFi (Realtek RTL8852BE, rtw89_8852be) stalls silently every
few minutes. The radio link stays completely healthy throughout -- received frames are counted by mac80211 but never delivered to the network stack.

During a stall:
  - the interface stays associated, signal unchanged (~-62 dBm)
  - "tx failed" and "tx retries" stay at 0: the AP ACKs every frame we send
  - "beacon loss" stays at 0
  - the station's "rx packets" counter keeps increasing (~23 frames/s)
  - but almost nothing reaches the IP stack -- no ping, no traffic at all
  - the kernel logs NOTHING: no deauth, no disassoc, no firmware error
  - after 1-7 minutes it recovers on its own, WITHOUT re-association, and the
    entire backlog is delivered in a single burst

Quantified over one 54-second stall, comparing the mac80211 station counter
against 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 (0x0806), AVM vendor protocols (0x8912, 0x88e1), IPv6 multicast (0x86dd) --
exactly the traffic that bypasses Block-Ack reordering.

SUSPECTED COMMIT:
  bda294ed0ed0 ("wifi: rtw89: Drop malformed AMPDU frames with abnormal PN")

Reverting this commit on top of v7.1 appears to fix the problem: the stalls are
gone. The mechanism fits every observation -- dropping a frame inside an A-MPDU
leaves a hole in the sequence numbers, the RX reorder buffer waits for something
that never arrives, everything behind it piles up, and it is only flushed when a
timeout eventually fires.

Version-Release number of selected component:
  Bad:      kernel-7.1.3-200.fc44.x86_64, and v7.1 vanilla (self-built)
  Good:     kernel-7.0.14-201.fc44.x86_64
  Fixed by: v7.1 with bda294ed0ed0 reverted

Note: "git log v7.1..v7.1.3 -- net/mac80211/ drivers/net/wireless/realtek/rtw89/"
is EMPTY, so the regression entered with the v7.1 merge window, not via a stable
patch.

Hardware:
  04:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8852BE
          PCIe 802.11ax Wireless Network Controller [10ec:b852]
  Driver:   rtw89_8852be (chip info CID: 0, CV: 1, AID: 0, ACV: 1, RFE: 1)
  Firmware: 0.29.29.18 (9e3d777f)
  AP:       FRITZ!Box 4040, 5 GHz, channel 36 (5180 MHz), VHT80, non-DFS

How reproducible:
Every few minutes under normal use. Never on 7.0.14, tested over several full
working days. Confirmed A/B/A. I could NOT find a way to trigger it on demand -- tearing down the RX Block-Ack sessions via mac80211 debugfs looked promising at first but produced no stall in 10 controlled attempts. Because of that I could not bisect;
the suspect was found by reading the v7.0..v7.1 commits touching the RX/AMPDU path
and doing a targeted revert test.

Actual results (monitoring script, 5 s interval; counters from "iw station dump",
router = ping to the AP):

  15:59:30 sig=-63 txp=70540 txr=0 txf=0 rxp=266600 bl=0 router=OK
  15:59:35 sig=-62 txp=70824 txr=0 txf=0 rxp=267564 bl=0 router=FAIL  <- stall
  16:02:00 sig=-63 txp=71396 txr=0 txf=0 rxp=270838 bl=0 router=FAIL
  16:06:42 sig=-61 txp=72752 txr=0 txf=0 rxp=277203 bl=0 router=FAIL
  16:06:48 sig=-64 txp=72864 txr=0 txf=0 rxp=277369 bl=0 router=OK    <- recovers
  16:06:53 sig=-61 txp=74304 txr=0 txf=0 rxp=280463 bl=0 router=OK    <- +3094 burst

Note txf=0 and bl=0 throughout, and rxp climbing steadily during the stall.
dmesg over this entire window contains ZERO wireless-related entries.

Additional info:
- WiFi powersave disabled (NetworkManager wifi.powersave=2, confirmed via iw).
- /etc/modprobe.d/rtw89.conf sets:
    options rtw89_pci disable_clkreq=y disable_aspm_l1=y disable_aspm_l1ss=y
    options rtw89_core disable_ps_mode=y
  All confirmed active via /sys/module/*/parameters/. The stall STILL occurs, so the
  known disable_aspm_l1 workaround does NOT help here.
- Signal is constant across the stall; not a range, interference or DFS issue.
- The Fedora kernel is built without CONFIG_RTW89_DEBUGMSG / CONFIG_RTW89_DEBUGFS,
  so no driver-level trace is available.
- A regression with the same version boundary was reported against the CachyOS
  kernel: https://github.com/CachyOS/linux-cachyos/issues/921
  There, disable_aspm_l1 resolved it; here it does not.


Reproducible: Always