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

From: LB F

Date: Wed Mar 18 2026 - 20:23:40 EST


Hi Ping-Ke,

I successfully collected the output with your diagnostic printk.

Here is the exact log entry triggered when the warning fires:

[ 180.424146] VHT NSS=0 pkt_stat->rate=0x65 rx_status->band=1
rx_status->rate_idx=0
[ 180.424157] WARNING: net/mac80211/rx.c:5491 at
ieee80211_rx_list+0x177/0x1020 [mac80211]

Looking at the rtw88 source code, this perfectly explains why `nss` is 0:
1. The hardware/firmware reports `pkt_stat->rate = 0x65` (101 in decimal).
2. `rtw_rx_fill_rx_status()` checks if `pkt_stat->rate >=
DESC_RATEVHT1SS_MCS0` (which is `0x2c`). Since `0x65 >= 0x2c`, it
correctly sets `rx_status->encoding = RX_ENC_VHT`.
3. It then calls `rtw_desc_to_mcsrate(pkt_stat->rate,
&rx_status->rate_idx, &rx_status->nss)`.
4. Inside `rtw_desc_to_mcsrate()`, the value `0x65` falls completely
outside any known bounds. The highest defined rate in `enum
rtw_trx_desc_rate` is `DESC_RATEVHT4SS_MCS9` (`0x53`). The HT range
(`DESC_RATEMCS0` to `DESC_RATEMCS31`) ends at `0x2b`.
5. Because `0x65` matches absolutely none of the `if/else` brackets in
`rtw_desc_to_mcsrate()`, the function simply returns without mutating
`mcs` and `nss`.
6. Since `rx_status` was initialized with `memset(rx_status, 0, ...)`
at the beginning of the function, `rx_status->nss` remains `0`.

So mac80211 complains because the rtw88 driver doesn't know what rate
`0x65` means, leaves NSS at 0, but still flags it as a VHT packet.

Any idea what `0x65` represents from the hardware's perspective? Is it
a firmware bug or a proprietary control/management frame rate index?

Looking forward to your thoughts!

Best regards,
Oleksandr