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

[LB F]

Ping-Ke Shih <pkshih@xxxxxxxxxxx> 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.

---

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@xxxxxxxxxxx/

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.

Best regards,
Oleksandr Havrylov