From: Lukas Wunner <lukas@wunner•de>
To: Yury Murashka <yurypm@arista•com>
Cc: bhelgaas@google•com, mahesh@linux•ibm.com, oohall@gmail•com,
linux-pci@vger•kernel.org, linux-kernel@vger•kernel.org,
linuxppc-dev@lists•ozlabs.org
Subject: Re: [PATCH] PCI/AER: Clear non-fatal errors on AER recovery failure
Date: Tue, 19 May 2026 11:53:35 +0200 [thread overview]
Message-ID: <agwzHzF3bpPM6jcC@wunner.de> (raw)
In-Reply-To: <CAPzpGcRCTCZtaX1EVaJNZ103THZKsoszZduY7=gwfYdcrMo-SQ@mail.gmail.com>
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
next prev parent reply other threads:[~2026-05-19 10:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
[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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agwzHzF3bpPM6jcC@wunner.de \
--to=lukas@wunner$(echo .)de \
--cc=bhelgaas@google$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-pci@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mahesh@linux$(echo .)ibm.com \
--cc=oohall@gmail$(echo .)com \
--cc=yurypm@arista$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox