* [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure
@ 2026-05-18 13:23 Yury Murashka
2026-05-18 20:29 ` Bjorn Helgaas
2026-05-19 9:53 ` Lukas Wunner
0 siblings, 2 replies; 7+ messages in thread
From: Yury Murashka @ 2026-05-18 13:23 UTC (permalink / raw)
To: bhelgaas, mahesh
Cc: oohall, corbet, skhan, linux-pci, linux-doc, linux-kernel,
linuxppc-dev, Yury Murashka
pci_aer_clear_nonfatal_status() is not called when AER recovery fails.
If a new AER error is subsequently reported, the AER driver calls
find_source_device() to find the source of the error. It rescans the
whole bus and picks the first device reporting an AER error. Because the
previous error was never cleared, the error is attributed to the wrong
device and AER recovery is started for the wrong device.
Add a kernel boot parameter pci=aer_clear_on_recovery_failure to clear
AER error status even when recovery fails, preventing stale errors from
causing incorrect device identification on subsequent AER events.
Signed-off-by: Yury Murashka <yurypm@arista•com>
---
Documentation/admin-guide/kernel-parameters.txt | 5 +++++
drivers/pci/pci.c | 2 ++
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/err.c | 13 +++++++++++++
4 files changed, 22 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 4d0f545fb..5a9e266f5 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5301,6 +5301,11 @@ Kernel parameters
nomio [S390] Do not use MIO instructions.
norid [S390] ignore the RID field and force use of
one PCI domain per PCI function
+ aer_clear_on_recovery_failure
+ [PCIE] If the PCIEAER kernel config parameter is
+ enabled, this kernel boot option can be used to
+ enable AER errors cleanup even if error recovery
+ failed.
notph [PCIE] If the PCIE_TPH kernel config parameter
is enabled, this kernel boot option can be used
to disable PCIe TLP Processing Hints support
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d34266651..701459c62 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6769,6 +6769,8 @@ static int __init pci_setup(char *str)
disable_acs_redir_param = str + 18;
} else if (!strncmp(str, "config_acs=", 11)) {
config_acs_param = str + 11;
+ } else if (!strncmp(str,
"aer_clear_on_recovery_failure", 29)) {
+ pci_enable_aer_clear_on_recovery_failure();
} else {
pr_err("PCI: Unknown option `%s'\n", str);
}
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4a14f88e5..093a7c896 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -1292,6 +1292,7 @@ int pci_aer_clear_status(struct pci_dev *dev);
int pci_aer_raw_clear_status(struct pci_dev *dev);
void pci_save_aer_state(struct pci_dev *dev);
void pci_restore_aer_state(struct pci_dev *dev);
+void pci_enable_aer_clear_on_recovery_failure(void);
#else
static inline void pci_no_aer(void) { }
static inline void pci_aer_init(struct pci_dev *d) { }
@@ -1301,6 +1302,7 @@ static inline int pci_aer_clear_status(struct
pci_dev *dev) { return -EINVAL; }
static inline int pci_aer_raw_clear_status(struct pci_dev *dev) {
return -EINVAL; }
static inline void pci_save_aer_state(struct pci_dev *dev) { }
static inline void pci_restore_aer_state(struct pci_dev *dev) { }
+static inline void pci_enable_aer_clear_on_recovery_failure(void) { }
#endif
#ifdef CONFIG_ACPI
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index bebe4bc11..29d655a34 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -21,6 +21,13 @@
#include "portdrv.h"
#include "../pci.h"
+static int enable_aer_clear_on_recovery_failure;
+
+void pci_enable_aer_clear_on_recovery_failure(void)
+{
+ enable_aer_clear_on_recovery_failure = 1;
+}
+
static pci_ers_result_t merge_result(enum pci_ers_result orig,
enum pci_ers_result new)
{
@@ -289,6 +296,12 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
return status;
failed:
+ if (enable_aer_clear_on_recovery_failure &&
+ (host->native_aer || pcie_ports_native)) {
+ pcie_clear_device_status(dev);
+ pci_aer_clear_nonfatal_status(dev);
+ }
+
pci_walk_bridge(bridge, pci_pm_runtime_put, NULL);
pci_walk_bridge(bridge, report_perm_failure_detected, NULL);
--
2.51.0
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure
2026-05-18 13:23 [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure Yury Murashka
@ 2026-05-18 20:29 ` Bjorn Helgaas
2026-05-18 20:49 ` Yury M.
2026-05-19 9:53 ` Lukas Wunner
1 sibling, 1 reply; 7+ messages in thread
From: Bjorn Helgaas @ 2026-05-18 20:29 UTC (permalink / raw)
To: Yury Murashka
Cc: bhelgaas, mahesh, oohall, corbet, skhan, linux-pci, linux-doc,
linux-kernel, linuxppc-dev, Lukas Wunner
[+cc Lukas]
On Mon, May 18, 2026 at 02:23:36PM +0100, Yury Murashka wrote:
> pci_aer_clear_nonfatal_status() is not called when AER recovery fails.
> If a new AER error is subsequently reported, the AER driver calls
> find_source_device() to find the source of the error. It rescans the
> whole bus and picks the first device reporting an AER error. Because the
> previous error was never cleared, the error is attributed to the wrong
> device and AER recovery is started for the wrong device.
>
> Add a kernel boot parameter pci=aer_clear_on_recovery_failure to clear
> AER error status even when recovery fails, preventing stale errors from
> causing incorrect device identification on subsequent AER events.
Why should we add a kernel parameter for this? How would a user
decide whether to use the parameter? Are there cases where we
find the source of the first error, but we *wouldn't* want to clear
it if recovery fails?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure
2026-05-18 20:29 ` Bjorn Helgaas
@ 2026-05-18 20:49 ` Yury M.
0 siblings, 0 replies; 7+ messages in thread
From: Yury M. @ 2026-05-18 20:49 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas, mahesh, oohall, corbet, skhan, linux-pci, linux-doc,
linux-kernel, linuxppc-dev, Lukas Wunner
Current behavior has existed for a long time and I could easily imagine
that there is software which relies on the fact that the system is in a
non-modified state if AER recovery failed. The software can analyze the
system and do cleanup afterwards. Sometimes, if something fails in the
system, it is better to have it in a non-modified state.
In short, I just wanted to preserve the current logic by default because
there is a chance that we have software which relies on the current
behavior.
On 5/18/26 21:29, Bjorn Helgaas wrote:
> [+cc Lukas]
>
> On Mon, May 18, 2026 at 02:23:36PM +0100, Yury Murashka wrote:
>> pci_aer_clear_nonfatal_status() is not called when AER recovery fails.
>> If a new AER error is subsequently reported, the AER driver calls
>> find_source_device() to find the source of the error. It rescans the
>> whole bus and picks the first device reporting an AER error. Because the
>> previous error was never cleared, the error is attributed to the wrong
>> device and AER recovery is started for the wrong device.
>>
>> Add a kernel boot parameter pci=aer_clear_on_recovery_failure to clear
>> AER error status even when recovery fails, preventing stale errors from
>> causing incorrect device identification on subsequent AER events.
> Why should we add a kernel parameter for this? How would a user
> decide whether to use the parameter? Are there cases where we
> find the source of the first error, but we *wouldn't* want to clear
> it if recovery fails?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure
2026-05-18 13:23 [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure Yury Murashka
2026-05-18 20:29 ` Bjorn Helgaas
@ 2026-05-19 9:53 ` Lukas Wunner
[not found] ` <3633b587-5782-4cfa-b967-997de86866bb@arista.com>
1 sibling, 1 reply; 7+ messages in thread
From: Lukas Wunner @ 2026-05-19 9:53 UTC (permalink / raw)
To: Yury Murashka
Cc: bhelgaas, mahesh, oohall, linux-pci, linux-kernel, linuxppc-dev
On Mon, May 18, 2026 at 02:23:36PM +0100, Yury Murashka wrote:
> pci_aer_clear_nonfatal_status() is not called when AER recovery fails.
> If a new AER error is subsequently reported, the AER driver calls
> find_source_device() to find the source of the error. It rescans the
> whole bus and picks the first device reporting an AER error. Because the
> previous error was never cleared, the error is attributed to the wrong
> device and AER recovery is started for the wrong device.
I guess the rationale of the current behavior is that the devices
affected by the failed error recovery are basically in a broken
state once error recovery failed and so user intervention is
required, e.g. a remove/rescan via sysfs.
My question is, why is error recovery failing for the devices
in the first place?
And what does the hierarchy look like?
(lspci -tv and lspci -vvv output please)
I also don't quite follow your assertion that (only) the first device
reporting an error is picked. The algorithm tries to collect *all*
error-reporting devices in the affected portion of the hierarchy.
Thanks,
Lukas
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-05-20 10:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-18 13:23 [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure Yury Murashka
2026-05-18 20:29 ` Bjorn Helgaas
2026-05-18 20:49 ` Yury M.
2026-05-19 9:53 ` Lukas Wunner
[not found] ` <3633b587-5782-4cfa-b967-997de86866bb@arista.com>
2026-05-20 8:43 ` Lukas Wunner
2026-05-20 10:00 ` Yury M.
2026-05-20 9:02 ` Lukas Wunner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox