Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)

[LB F <goainwo@gmail.com>]

Ping-Ke Shih <pkshih@realtek.com> wrote:
> Not sure what hardware get wrong. Let's validate rate when reading
> from hardware. Since 1M rate can only 20MHz, I set it together.
> Please help to test below. I suppose you can see "weird rate=xxx",
> but "WARNING: net/mac80211/rx.c:5491" disappears.

Hi Ping-Ke,

I can confirm your patch works as expected. Here are the full results.

--- Test environment ---

Kernel:  6.19.7-1-cachyos
Patch:   your rate validation patch applied to rtw_rx_query_rx_desc(),
         on top of the v2 DMI quirk (ASPM + LPS Deep disabled)

--- Captured log (relevant excerpt) ---

  [  43.046] input: Soundcore Q10i (AVRCP)   <-- BT headset connected
  [ 111.551] rtw_8821ce 0000:13:00.0: unused phy status page (13)
  [ 111.635] weird rate=101
  [ 111.635] rtw_8821ce 0000:13:00.0: unused phy status page (7)
  [ 111.741] weird rate=102
  [ 115.045] weird rate=98
  [ 118.371] weird rate=104

--- Analysis ---

1. Timing: the anomalous events began approximately 68 seconds after
   the Bluetooth A2DP headset (Soundcore Q10i) established its
   connection. No anomalies were observed before BT connected.

2. Multiple invalid rate values were captured, not just 0x65:

     weird rate=101  (0x65)
     weird rate=102  (0x66)
     weird rate=98   (0x62)
     weird rate=104  (0x68)

   All four values exceed DESC_RATE_MAX (0x53 = 83 decimal). This
   suggests the hardware occasionally reports a range of out-of-bounds
   rate values during BT/Wi-Fi coexistence, not a single fixed value.

3. The "unused phy status page" messages (pages 13 and 7) appeared
   immediately before and alongside the "weird rate" events. As noted
   in my previous message, only pages 0 and 1 are expected. This
   further suggests the firmware leaks internal coexistence state
   into the RX ring during BT antenna arbitration.

4. Most importantly: the WARNING: net/mac80211/rx.c:5491 did NOT
   appear anywhere in the log. Your rate clamping patch successfully
   intercepts the out-of-bounds values before they propagate to
   mac80211, preventing the invalid VHT NSS=0 warning entirely.

--- Conclusion ---

Your patch achieves the intended result. The "weird rate" printk
confirms the hardware is the source of the invalid values (occurring
during BT coexistence), and the mac80211 WARNING is suppressed.

Please let me know if you need any additional data or further testing.

Best regards,
Oleksandr Havrylov