RE: [BUG] wifi: rtw89: RTL8852BE firmware fails to leave LPS and recovery times out

[Ping-Ke Shih <pkshih@realtek.com>]

Rohit Mahesh <rm4336@columbia.edu> wrote:
> On Sun, Aug 2, 2026, Ping-Ke Shih wrote:
> > Try to set these to Y to see if help.
> 
> Hi Ping-Ke,
> 
> Apologies for the delayed follow-up. This is the laptop I use every day, so
> I wanted to leave the workaround in place long enough to see whether it
> was actually stable.
> 
> I first tried:
> 
>   rtw89_core.disable_ps_mode=Y
> 
> but the Wi-Fi failure recurred. It also continued after I went back to
> kernel 7.0.3-artix1-2. On August 2, it happened six times in roughly two
> hours, so I do not currently have a known-good kernel version to use as
> a bisect endpoint.

It looks like rtw89_core.disable_ps_mode=Y isn't the cause.

> 
> During one of the August 2 failures, I monitored the Link Status of the
> upstream AMD PCIe bridge at approximately 20 ms intervals. In that
> capture, the Data Link Layer Link Active bit changed from 1 to 0. The
> subsequent rtw89 messages begin with:
> 
>   rtw89_8852be 0000:02:00.0: failed to pre-release fwcmd
>   rtw89_8852be 0000:02:00.0: read rf busy swsi

I'm guessing the PCI becomes inaccessible at this moment.
Use 'sudo lspci -s 0000:02:00.0 -xxx' to see if all things are 0xFF or 0x00.

> 
> Immediately afterward, lspci reported "Unknown header type 7f" for the
> RTL8852BE, and the upstream port reported DLActive-. I attached that
> capture as rtw89-2026-08-02-pcie-link-loss.txt.
> 
> I then rebooted with the following PCIe-related settings:
> 
>   rtw89_pci.disable_aspm_l1=Y
>   rtw89_pci.disable_aspm_l1ss=Y
>   rtw89_pci.disable_clkreq=Y
>   pcie_aspm=force

I'm thinking if 'pcie_aspm=off' can be more conservative (stable) ?
But your experiments are positive, so no need this extra experiment. 

>   pcie_aspm.policy=performance
> 
> rtw89_core.disable_ps_mode remained set to Y. I also disabled runtime
> power management and D3cold for the Wi-Fi device and its AMD root port.
> 
> With that configuration, I have now gone nine days without another
> occurrence. Before these changes, the failure sometimes occurred
> several times within an hour.

Good to hear that. 

Without oscilloscope or CAT-C, we can't dig PCI bus L1/L1SS/CLKREQ
interoperability issue further. Therefore, I suggest you apply these
settings.

> 
> Given the August 2 capture, I suspect the LPS and SER failures may be a
> consequence of the PCIe link becoming unavailable rather than the
> initial failure itself. Since I changed several PCIe power-management
> settings together, however, I cannot say whether L1, L1SS, CLKREQ, or
> another part of the configuration is responsible.
> 
> I did not test each setting individually because every occurrence
> leaves the Wi-Fi unusable until I reboot, and this is my daily-use
> machine.
> 
> > Did it occur right after system resume? Can you share the full log?
> 
> No. The two original failures occurred during normal use, not
> immediately after system resume.

At system resume, host/wifi card restart PCI power-on sequence, and
retrain PCI. Mostly, problems happen at this moment, so I asked you
this question. Fortunately, you didn't encounter this. :)

> 
> I attached the plain-text logs for the July 30 and July 31
> incidents, as well as the August 2 PCIe link-loss capture.

Thanks for all captures, which looks like PCI bus gets inaccessible. 
If you want to get better power consumption, first one you can try is
to remove

   rtw89_core.disable_ps_mode=Y

The other APSM settings don't affect too much (in aspect of WiFi card),
so you can try them afterward. 

Ping-Ke