Re: [PATCH v2] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Lukas Wunner <lukas@wunner.de>]

On Wed, Jul 01, 2026 at 03:42:01PM -0500, Bjorn Helgaas wrote:
> On Wed, Jul 01, 2026 at 08:27:13AM +0200, Manivannan Sadhasivam wrote:
> > On Wed, Jun 10, 2026 at 10:47:23AM +0800, Max Lee wrote:
> > > The Realtek RTS525A PCI-Express SD card reader (10ec:525a) generates
> > > excessive Correctable Error (Replay Timer Timeout) AER events during
> > > PCIe link initialization. On systems where firmware enables AER
> > > reporting (CERptEn+), this causes an AER storm of ~240K error events
> > > within 11 seconds of boot, overwhelming the kernel error handler and
> > > blocking shutdown/reboot.
> 
> Specifically, I guess these error events are the AER interrupts.  We
> rate-limit the actual *messages*, but not the interrupts, so we can be
> overwhelmed by handling them.

Ratelimiting went into v6.16.  It would be good to know whether
the behavior described in the commit message occurs only with
older kernels or persists with ratelimiting.

It would also be good to know whether the "overwhelming" occurs
with OS-native AER handling (aer_print_error()) or with Firmware
First AER handling (pci_print_aer()).

The PCIe port driver is registered in a device_initcall, which happens
much later than PCI device enumeration in a subsys_initcall.  Do these
errors occur before the port driver registers?  If they do, then the
"overwhelming" likely happens through the Firmware First code path.
Or perhaps "within 11 seconds of boot" is when portdrv probes and
registers the AER driver?

It would be good to have full dmesg output for analysis because this
is all a little murky.

> Based on the flowchart in PCIe r7.0, sec 6.2.5, it looks like an
> Endpoint that detects a Correctable Error but lacks an AER Capability
> sets PCI_EXP_DEVSTA_CED and, if PCI_EXP_DEVCTL_CERE is set, sends
> ERR_COR upstream.
> 
> I suspect that what we need here is:
> 
>   - Mask PCI_ERR_COR_REP_TIMER in Endpoint to prevent it from sending
>     ERR_COR
> 
>   - Mask PCI_ERR_COR_REP_TIMER in upstream bridge to prevent it from
>     sending ERR_COR
> 
>   - If the upstream bridge is not the Root Port, mask
>     PCI_ERR_COR_REP_TIMER in Root Port to prevent AER interrupt if it
>     receives ERR_COR, e.g., if the Endpoint or bridge lacks AER

The last bullet point doesn't sound quite right:  Per table 6-4 in
PCIe r7.0 sec 6.2.7, Replay Timer Timeout is detected by the Transmitter.
This can only be the Endpoint or its upstream bridge.  If the upstream
bridge is not the Root Port, masking PCI_ERR_COR_REP_TIMER in the
Root Port doesn't help.

If the Endpoint or its upstream bridge don't support AER, one has to
clear Correctable Error Reporting Enable in the Device Control Register
to suppress the Replay Timer Timeout errors.  Obviously this will
suppress reporting of any other Correctable Error as well.

> I wonder if aer.c should disable the AER interrupt by temporarily
> clearing PCI_ERR_ROOT_CMD_COR_EN if it detects a storm.  Maybe that
> could avoid device quirks for transient issues like this.

The hierarchy below the Root Port might be deeper and we'd risk
losing errors reported by other devices in that hierarchy while
interrupt generation is temporarily disabled.

Thanks,

Lukas