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

[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

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

[Bitterblue Smith]

On 18/07/2026 01:48, Armin Breiteneder wrote:
> 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
> 
> 

Hi!

This commit from 7.2 should fix it: https://github.com/torvalds/linux/commit/63ccdfac8677387dfdbd9d4336089e9823280704

It's queued for 7.1.x as well.

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

[Armin Breiteneder]

Perfect!
Thank you for the fast response!


Am 18.07.2026 um 13:55 schrieb Bitterblue Smith <rtl8821cerfe2@gmail.com>:

On 18/07/2026 01:48, Armin Breiteneder wrote:
> 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
> 
> 

Hi!

This commit from 7.2 should fix it: https://github.com/torvalds/linux/commit/63ccdfac8677387dfdbd9d4336089e9823280704

It's queued for 7.1.x as well.