LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Matthew W Carlis <mattc@purestorage.com>
Cc: agovindjee@purestorage.com, an.luo@enflame-tech.com,
	ashishk@purestorage.com, bill.wu@enflame-tech.com,
	dio.sun@enflame-tech.com, fernando.hu@enflame-tech.com,
	helgaas@kernel.org, jrangi@purestorage.com,
	linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	mahesh@linux.ibm.com, msaggi@purestorage.com, oohall@gmail.com,
	qingshun.wang@linux.intel.com, rhan@purestorage.com,
	sathyanarayanan.kuppuswamy@linux.intel.com,
	sconnor@purestorage.com, terry.bowman@amd.com,
	xin.wang@enflame-tech.com, yang.yicong@picoheart.com,
	yurypm@arista.com, zhenzhong.duan@intel.com
Subject: Re: [PATCH 0/6] PCI/AER: Support Advisory Non-Fatal Errors
Date: Sat, 1 Aug 2026 11:08:48 +0200	[thread overview]
Message-ID: <am23oEnTurWaznAa@wunner.de> (raw)
In-Reply-To: <20260801082419.7780-1-mattc@purestorage.com>

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


      reply	other threads:[~2026-08-01  9:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 15:24 [PATCH 0/6] PCI/AER: Support Advisory Non-Fatal Errors Lukas Wunner
2026-07-24 15:24 ` [PATCH 1/6] PCI/AER: Fix mapping of errors to agent & layer Lukas Wunner
2026-07-24 15:24 ` [PATCH 2/6] PCI/AER: Log agent & layer for each individual error Lukas Wunner
2026-07-24 15:24 ` [PATCH 3/6] PCI/AER: Deduplicate logging of Error Source Identification Lukas Wunner
2026-07-24 15:24 ` [PATCH 4/6] PCI/AER: Emit TLP Log only for unmasked errors Lukas Wunner
2026-07-24 15:24 ` [PATCH 5/6] PCI/AER: Move retrieval of FEP and TLP Log into helper Lukas Wunner
2026-07-24 15:24 ` [PATCH 6/6] PCI/AER: Support Advisory Non-Fatal Errors Lukas Wunner
2026-07-24 22:39 ` [PATCH 0/6] " Bjorn Helgaas
2026-07-27 14:12   ` Lukas Wunner
2026-07-27 15:51     ` Bjorn Helgaas
2026-07-31 18:47     ` Lukas Wunner
2026-08-01  8:24       ` Matthew W Carlis
2026-08-01  9:08         ` Lukas Wunner [this message]

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=am23oEnTurWaznAa@wunner.de \
    --to=lukas@wunner.de \
    --cc=agovindjee@purestorage.com \
    --cc=an.luo@enflame-tech.com \
    --cc=ashishk@purestorage.com \
    --cc=bill.wu@enflame-tech.com \
    --cc=dio.sun@enflame-tech.com \
    --cc=fernando.hu@enflame-tech.com \
    --cc=helgaas@kernel.org \
    --cc=jrangi@purestorage.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mahesh@linux.ibm.com \
    --cc=mattc@purestorage.com \
    --cc=msaggi@purestorage.com \
    --cc=oohall@gmail.com \
    --cc=qingshun.wang@linux.intel.com \
    --cc=rhan@purestorage.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=sconnor@purestorage.com \
    --cc=terry.bowman@amd.com \
    --cc=xin.wang@enflame-tech.com \
    --cc=yang.yicong@picoheart.com \
    --cc=yurypm@arista.com \
    --cc=zhenzhong.duan@intel.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