From: Bjorn Helgaas <helgaas@kernel.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Terry Bowman <terry.bowman@amd.com>,
Sathyanarayanan Kuppuswamy
<sathyanarayanan.kuppuswamy@linux.intel.com>,
linux-pci@vger.kernel.org, Shuai Xue <xueshuai@linux.alibaba.com>,
tianruidong@linux.alibaba.com, Keith Busch <kbusch@kernel.org>,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Oliver OHalloran <oohall@gmail.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] PCI/AER: Clear stale errors on reporting agents upon probe
Date: Tue, 27 Jan 2026 17:00:55 -0600 [thread overview]
Message-ID: <20260127230055.GA384686@bhelgaas> (raw)
In-Reply-To: <3011c2ed30c11f858e35e29939add754adea7478.1769332702.git.lukas@wunner.de>
On Sun, Jan 25, 2026 at 10:25:51AM +0100, Lukas Wunner wrote:
> Correctable and Uncorrectable Error Status Registers on reporting agents
> are cleared upon PCI device enumeration in pci_aer_init() to flush past
> events. They're cleared again when an error is handled by the AER driver.
Do you think pci_aer_init() is the right time to clear the error
status bits? Most of those bits are sticky, so they're not cleared by
reset.
I'm thinking about the scenario where a PCIe error occurs is captured
in the AER error status registers, but the system reboots before the
AER driver can log the error. Since the bits are sticky, the new
kernel might have a chance to find and log the error that happened
with the previous kernel.
So I wonder if pci_aer_init() should just find the Capability and
alloc its buffers, and aer_probe() should look for existing errors and
log them before clearing them.
Of course enumeration will cause some errors (probably mostly
Unsupported Requests), and we wouldn't want to log all those.
Bjorn
next prev parent reply other threads:[~2026-01-27 23:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-25 9:25 [PATCH] PCI/AER: Clear stale errors on reporting agents upon probe Lukas Wunner
2026-01-26 18:42 ` Kuppuswamy Sathyanarayanan
2026-01-27 7:56 ` Lukas Wunner
2026-01-27 23:00 ` Bjorn Helgaas [this message]
2026-02-02 10:42 ` Lukas Wunner
2026-02-06 22:24 ` Bjorn Helgaas
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=20260127230055.GA384686@bhelgaas \
--to=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lukas@wunner.de \
--cc=mahesh@linux.ibm.com \
--cc=oohall@gmail.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=terry.bowman@amd.com \
--cc=tianruidong@linux.alibaba.com \
--cc=xueshuai@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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