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

[LB F]

Hi Bitterblue,

I am writing to report preliminary testing results for your RTL8821CE
RX descriptor validation patch (addressing Bugzilla 221286). I have
successfully applied the patch to the out-of-tree rtw88 driver.

System Environment:

OS: openSUSE Tumbleweed-Slowroll
Kernel: 6.19.12-1-default (x86_64)
Hardware: HP Notebook 15-ay027ur (SKU: P3S95EA#ACB, Board: 81F0)
Wi-Fi Module: Realtek RTL8821CE (PCIe)
Firmware loaded: Firmware version 24.11.0, H2C version 12
Driver: Out-of-tree rtw88 (manually patched rx.c, pci.c, pci_old.c,
sdio.c, usb.c)
Note on Patch Baseline: This testing was conducted with the new RX
descriptor validation patch applied on top of the previous patches
we've discussed:

Quirks to disable PCI ASPM and deep LPS for this HP model.
NULL check for chip->edcca_th.
The diagnostic hex dump patch for unused phy status pages.
Testing Methodology: To intentionally trigger the hardware bug, I
performed the following stress tests:

Sustained high-throughput RX load (continuously downloading a 145MB
file to /dev/null at maximum bandwidth).
Toggling PCIe ASPM and interface power saving (iw dev wlp19s0 set
power_save on) under active network load.
Rapid software de-authentication and re-association via NetworkManager.
ACPI Power state transitions: Suspend to RAM (S3) and Suspend to Disk
(S4/Hibernation) while actively connected.
Results: Previously, resuming from S3/S4 or shifting ASPM states under
load would consistently trigger a hard system freeze or kernel panic
within minutes. With your patch applied, the system remained
completely stable across all test phases. The driver handled all power
state transitions and sustained network loads without any issues.

Log Analysis: A detailed review of dmesg and journalctl shows no
mac80211 warnings, no rtw_8821ce initialization errors, and no memory
corruption traces. Notably, the pr_err_once trap for the corrupted
descriptor (drv_info_sz != PHY_STATUS_SIZE or length mismatches) was
not triggered during these artificial tests. This suggests the
hardware did not emit a corrupted frame during this specific session.
However, the system's ability to survive heavy S3/S4 transitions
without crashing is a massive improvement.

Next Steps: Given the intermittent nature of the bug, I will use the
machine for standard daily workloads over the next several days
(longitudinal testing). If the pr_err_once trap is triggered or if any
instability occurs, I will immediately provide the logs. If the system
remains perfectly stable for a week, I will report back to confirm the
fix is solid.

Thank you for your time and for providing this patch.

Best regards, Oleksandr Havrylov