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:
> 
> Hi Ping-Ke,
> 
> Thank you for your guidance. To provide you with the cleanest possible
> diagnostic data, we devised a strict testing environment:
> 
> 1. **Live USB Environment:** We booted a completely fresh Live USB of
> CachyOS (Kernel 6.19.6) to eliminate any potential interference from
> installed software, TLP profiles, or custom NetworkManager
> configurations.
> 2. **Aggressive Local Logging:** Because the system freeze physically
> locks the PCIe bus and disables the Wi-Fi adapter instantly, using
> `netconsole` was impossible (the network drops microseconds before the
> freeze).
> 
> To overcome this, we wrote an "aggressive logger" script that pipes
> `dmesg -w` directly to an independent FAT32 USB drive while issuing a
> `sync` command twice a second. This bypassed RAM caching and
> physically burned the logs to the drive right up to the moment of the
> hard freeze. The script we used was:
> 
> ```bash
> #!/bin/bash
> LOG_FILE="/run/media/liveuser/LOGS/kernel_freeze.log"
> dmesg -w > "$LOG_FILE" &
> while true; do
>     sync
>     sleep 0.5
> done
> ```
> 
> 3. No workarounds (`disable_aspm=n`, `disable_lps_deep=n`) were active
> in this test. We manually enabled power saving (`iw dev wlan0 set
> power_save on`) and triggered the freeze via typical web browsing.
> 
> Here are the precise, unadulterated logs showing the adapter
> successfully connecting to the network, sitting idle for about 10
> seconds (presumably entering power-saving states), and then suffering
> a fatal firmware lockup right before the PCIe bus froze:
> 
> ```
> [  304.709201] audit: type=1111 ... op=connection-add-activate ...
> name="Andrey_5G" ...
> [  305.617785] wlan0: authenticate with 6c:68:a4:1c:97:5b ...
> [  305.660333] wlan0: authenticated
> [  305.661661] wlan0: associate with 6c:68:a4:1c:97:5b (try 1/3)
> [  305.663404] wlan0: associated
> [  305.719997] wlan0: Limiting TX power to 30 (30 - 0) dBm as
> advertised by 6c:68:a4:1c:97:5b
> ... (~10 seconds of idle network time) ...
> [  316.907114] rtw88_8821ce 0000:13:00.0: failed to send h2c command
> [  316.911190] rtw88_8821ce 0000:13:00.0: failed to send h2c command
> [  316.921504] rtw88_8821ce 0000:13:00.0: coex request time out
> ...
> [  349.630952] rtw88_8821ce 0000:13:00.0: failed to send h2c command
> [  349.635023] rtw88_8821ce 0000:13:00.0: failed to send h2c command
> [  357.811235] rtw88_8821ce 0000:13:00.0: firmware failed to leave lps state
> [  359.797238] rtw88_8821ce 0000:13:00.0: firmware failed to leave lps state
> ... (repeats indefinitely until hard reset) ...
> ```

Just want to clarify that these logs only appear in test 3, right?
No these logs in test 1/2. 

> 
> As the logs clearly demonstrate, the adapter authenticates perfectly
> but the firmware explicitly fails to leave the LPS state after a brief
> idle period, dropping all H2C commands immediately before the
> system-wide hard freeze begins.
> 
> We will upload the full, unabridged `.log` file to our Bugzilla thread
> (Bug 221195) momentarily, but we wanted to provide you with this exact
> 'smoking gun' trace right away to help identify the root cause.
> 
> Please let us know if this information is helpful or if there are any
> specific module patches or further tests you would like us to perform
> to assist with debugging.

Thanks for your detail tests and logs. With this kind of hardware problem,
to dig the cause, we need real hardware and hardware scope to measure
signals. I'd apply quirk or some validations on RX path. That'd be a
better way.

Ping-Ke