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:
> 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.

Following your suggestion, I performed a full stack reload including
mac80211.ko and cfg80211.ko, and was able to reproduce the warning:

  [152.226055] Rate marked as a VHT rate but data is invalid: MCS: 0, NSS: 0
  [152.226057] WARNING: net/mac80211/rx.c:5491 at
ieee80211_rx_list+0x177/0x1020 [mac80211]
  [152.226336] CPU: 2 UID: 0 PID: 638 Comm: irq/56-rtw_pci Tainted: G
IOE 6.19.7-1-cachyos
  [152.226344] Hardware name: HP HP Notebook/81F0, BIOS F.50 11/20/2020

One observation worth mentioning: the warning triggered approximately
72 seconds after initial association, coinciding with a Bluetooth
device connecting to the system. This may suggest the NSS=0 condition
occurs during BT coexistence negotiation rather than during normal
WiFi traffic. I am not sure if this is relevant, but I wanted to
mention it in case it helps narrow down the root cause.

I also noticed the offset is now +0x177, which matches exactly what
you showed from v6.19.6. The earlier +0x183 was likely an artifact of
CachyOS's LTO optimizations while mac80211 had been resident for a
long time.

As you noted, this appears to be a separate issue from the freeze and
h2c timeout problems, so I leave it to your judgment whether it
warrants further investigation.

---

I would like to take this opportunity to thank you sincerely for your
time, patience, and expertise throughout this whole process. From your
very first response to the final v2 patch, your guidance made it
possible to properly identify and resolve a bug that had been causing
real frustration for users of this hardware for a long time.

If any further testing of the rtw88 driver is needed -- whether for
this hardware or for other patches -- I am happy to help to the best
of my abilities and available time. This HP Notebook with RTL8821CE
will remain available for testing whenever it is useful.

Best regards,
Oleksandr Havrylov

вт, 17 мар. 2026 г. в 03:28, 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
>