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:
> I add a printk to show the case VHT and NSS==0 as below. Please help to
> collect the output, and then I can see what it happened.

Hi Ping-Ke,

I applied your diagnostic patch (using pr_err for maximum log
visibility) and spent the last couple of days testing it on the
affected hardware. The results answer both open questions cleanly.

---

Regarding your earlier question:
> Not sure if this is because PCIE bridge has no ASPM capability?

You were correct. The very beginning of the boot log shows:

  [0.177872] ACPI FADT declares the system doesn't support PCIe ASPM,
              so disable it
  [15.157752] r8169 0000:07:00.0: can't disable ASPM; OS doesn't have
               ASPM control

The BIOS on this HP laptop uses the ACPI FADT table to globally revoke
OS control over PCIe ASPM before Linux even takes over. This has an
important implication: since ASPM is already disabled at the hardware
level by firmware, the instability on this specific SKU is caused
entirely by LPS Deep Mode, not ASPM itself.

This explains why the ASPM-only quirk (v1 patch) did not stop the h2c
timeouts -- ASPM was never actually active on this machine to begin
with. Disabling LPS Deep Mode via the v2 quirk is what eliminates the
firmware timeout loop entirely.

---

Regarding the VHT NSS=0 diagnostic patch:

During normal idle, active pinging, and heavy VHT throughput
(175.5 Mb/s), the pr_err condition never triggered -- no
"VHT NSS=0" lines appeared in dmesg during active use.

However, the standard WARNING at mac80211/rx.c:5491 does reliably
appear exactly once after a fresh full stack reload (including
mac80211.ko and cfg80211.ko) or after resume from suspend:

  [167.708201] WARNING: net/mac80211/rx.c:5491 at
               ieee80211_rx_list+0x177/0x1020 [mac80211]

This suggests the hardware reports a malformed nss=0 VHT rate only
during initial link establishment. Since mac80211 uses WARN_ONCE, it
is suppressed on all subsequent packets.

The diagnostic module remains installed. I will report back
immediately if the pr_err condition is caught, or if any other
relevant symptoms appear.

Best regards,
Oleksandr Havrylov