Thread (13 messages) flat view 13 messages, 3 authors, 3d ago

Re: [PATCH 0/6] PCI/AER: Support Advisory Non-Fatal Errors

From: Lukas Wunner <lukas@wunner.de>
Date: 2026-08-01 09:08:59
Also in: linux-pci

On Sat, Aug 01, 2026 at 02:24:18AM -0600, Matthew W Carlis wrote:
What if we decoupled the message received by the root port from checking &
logging the AER status registers? In other words, when the root port
receives a message we log the severity we received and whether it was
multiple errors.
We already do exactly that in aer_print_source().
Then, when we get to the device that sent the message we just always check
the CE and the UE status registers? If any status is set that is also
unmasked then we log the corresponding TLP Header for that. In addition
we log the device status register so users can know what severities were
signaled.
That's also already being done (in aer_get_device_error_info() +
aer_print_error()) , except we only check the status/mask register
corresponding to the severity that the Root Port received.

E.g. if the Root Port received ERR_COR, we only read the Correctable
Error Status/Mask registers.
We can use the Error Message severity received at the root port to
decide whether to walk the pci bus and do the error_detected() stuff.
Same here, we already do that.  For ERR_COR, only ->cor_error_detected()
is invoked at the reporting device, whereas for ERR_NONFATAL and
ERR_FATAL, ->error_detected() and the other callbacks are invoked
via pcie_do_recovery().
If there are multiple UE status bits set at the reporter & Dev Status
register says there was a Non Fatal Error as well a Correctable Error
I don't think I care if simply logs everything in UE status as a UE,
everything in CE status as CE as long as it also tells me the Dev
Status Bits that are set.

Going a little further I would be fine with just always checking both
CE/UE status because it seems like it simplifies things a lot &
two/three extra config reads/writes is almost a nop if you're already
at the device probing it for the other AER things.
This is where we differ right now from your proposal:  Errors received
at the Root Port are queued up in a kfifo and we then empty that kfifo
one by one.  If there is an Uncorrectable Error behind a Correctable
Error in the queue for the same device, we handle the two separately.

Would it make sense to combine them?  Maybe, but keep in mind that for
Uncorrectable Errors, we may have to perform a Secondary Bus Reset to
recover from them, which can affect other devices in the same part of
the hierarchy.  E.g. if a Switch Upstream Port signals ERR_NONFATAL
and then its ->error_detected() callback returns
PCI_ERS_RESULT_NEED_RESET, the reset will affect the Switch Upstream
Port and everything below.  That's very different from how we handle
Correctable Errors.  For those, the driver of a single device just
gets a notification via ->cor_error_detected() and that's it.

There are still many bugs and opportunities for simplification in the
AER driver, but refactoring it without breaking things is quite
difficult and your proposal would be fairly intrusive I'm afraid.

Thanks,

Lukas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help