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

[Ping-Ke Shih <pkshih@realtek.com>]

LB F <goainwo@gmail.com> wrote:
> 
> Ping-Ke Shih <pkshih@realtek.com> wrote:
> > Not sure if this is because PCIE bridge has no ASPM capability?
> 
> That could indeed be the case -- I do not have a way to confirm
> without further hardware-level inspection.
> 
> > LN5491 (kernel v6.19.6) is:
> >                 case RX_ENC_VHT:
> >                         if (WARN_ONCE(status->rate_idx > 11 ||
> >                                       !status->nss ||
> >                                       status->nss > 8,
> >                                       "Rate marked as a VHT rate but data is
> invalid: MCS: %d, NSS: %d\n",
> >                                       status->rate_idx, status->nss))
> >                                 goto drop;
> >                         break;
> > Looks like driver reports improper VHT nss/rate? But this warns once, and
> > you message isn't like this.
> > Could you check the source code LN5491 you are using?
> 
> The file net/mac80211/rx.c is not available on disk on my system
> (CachyOS ships only .h files in the headers package), but I located
> the exact warning message in journalctl:
> 
>   Rate marked as a VHT rate but data is invalid: MCS: 0, NSS: 0
> 
> This confirms that line 5491 in my kernel matches exactly what you
> showed from v6.19.6 -- the RX_ENC_VHT case checking for
> status->nss == 0. The offset in my trace is slightly different
> (+0x183 vs +0x177), which is likely due to CachyOS's LTO/AutoFDO
> compiler optimizations.
> 
> The warning appeared once in my initial test session:
> 
>   Rate marked as a VHT rate but data is invalid: MCS: 0, NSS: 0
>   WARNING: net/mac80211/rx.c:5491 at ieee80211_rx_list+0x183/0x1020 [mac80211]
> 
> However, in subsequent module reload and reconnect cycles I was unable
> to reproduce it. This is consistent with WARN_ONCE behavior -- it
> likely fired on the first invalid nss=0 packet after the initial
> driver load and has not triggered since. I cannot confirm it as a
> reliable symptom.

To reproduce this reliable, you need to remove driver ko and mac80211.ko,
and reinstall them.

However, you have confirmed this is the symptom. I think only if you
want to dig why the rate reported by hardware is weird, otherwise we
can ignore this warning.

> 
> ---
> 
> Regarding patch stability: the results below are from testing your
> original RFT patch [1], not any newer submission. I want to be
> explicit to avoid confusion:
> 
>   [1]
> https://lore.kernel.org/linux-wireless/20260311020816.7065-1-pkshih@realtek.
> com/
> 
> This is the exact diff I compiled and tested:
> 
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -2,6 +2,7 @@
>  /* Copyright(c) 2018-2019  Realtek Corporation
>   */
> 
> +#include <linux/dmi.h>
>  #include <linux/module.h>
>  #include <linux/pci.h>
>  #include "main.h"
> @@ -1744,6 +1745,34 @@ const struct pci_error_handlers rtw_pci_err_handler = {
>  };
>  EXPORT_SYMBOL(rtw_pci_err_handler);
> 
> +enum rtw88_quirk_dis_pci_caps {
> + QUIRK_DIS_PCI_CAP_ASPM,
> +};
> +
> +static int disable_pci_caps(const struct dmi_system_id *dmi)
> +{
> + uintptr_t dis_caps = (uintptr_t)dmi->driver_data;
> +
> + if (dis_caps & BIT(QUIRK_DIS_PCI_CAP_ASPM))
> + rtw_pci_disable_aspm = true;
> +
> + return 1;
> +}
> +
> +static const struct dmi_system_id rtw88_pci_quirks[] = {
> + {
> + .callback = disable_pci_caps,
> + .ident = "HP Notebook - P3S95EA#ACB",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "HP"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP Notebook"),
> + DMI_MATCH(DMI_PRODUCT_SKU, "P3S95EA#ACB"),
> + },
> + .driver_data = (void *)BIT(QUIRK_DIS_PCI_CAP_ASPM),
> + },
> + {}
> +};
> +
>  int rtw_pci_probe(struct pci_dev *pdev,
>     const struct pci_device_id *id)
>  {
> @@ -1808,6 +1837,7 @@ int rtw_pci_probe(struct pci_dev *pdev,
>       bridge && bridge->vendor == PCI_VENDOR_ID_INTEL)
>   rtwpci->rx_no_aspm = true;
> 
> + dmi_check_system(rtw88_pci_quirks);
>   rtw_pci_phy_cfg(rtwdev);
> 
>   ret = rtw_register_hw(rtwdev, hw);
> 
> Results with only this patch applied:
> 
>   - The hard freeze lockup is gone.
>   - However, during idle the logs are flooded with:
> 
>       rtw88_8821ce 0000:13:00.0: failed to send h2c command
>       rtw88_8821ce 0000:13:00.0: firmware failed to leave lps state
> 
>   - To give a concrete sense of the volume: over an ~80-minute
>     observation window after a clean module reload, I recorded
>     11,757 "failed to send h2c command" events and 2 "firmware
>     failed to leave lps state" events -- approximately 110 errors
>     per minute during active periods.
>   - These errors cause Bluetooth audio stuttering and WiFi
>     throughput drops.
> 
> When I additionally set disable_lps_deep=Y alongside your ASPM patch,
> all h2c errors vanish completely and Bluetooth/WiFi remain fully
> stable. This confirms that disabling LPS Deep is necessary for
> complete stability on this specific HP SKU.
> 
> I also noticed what appears to be a new patch in a separate mailing
> list thread. I will test it shortly and report back with the results.

Thanks for your experiments in detail. :)

Ping-Ke