All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jon Pan-Doh <pandoh@google.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"Karolina Stolarek" <karolina.stolarek@oracle.com>,
	linux-pci@vger.kernel.org,
	"Martin Petersen" <martin.petersen@oracle.com>,
	"Ben Fuller" <ben.fuller@oracle.com>,
	"Drew Walton" <drewwalton@microsoft.com>,
	"Anil Agrawal" <anilagrawal@meta.com>,
	"Tony Luck" <tony.luck@intel.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Sathyanarayanan Kuppuswamy"
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH v2 1/8] PCI/AER: Remove aer_print_port_info
Date: Wed, 5 Mar 2025 16:35:40 -0600	[thread overview]
Message-ID: <20250305223540.GA312467@bhelgaas> (raw)
In-Reply-To: <CAMC_AXUqLYb=qr+EW0WeKq-NW7wQwNNi14Kc5k-6XmtXNiC18w@mail.gmail.com>

On Tue, Mar 04, 2025 at 05:04:21PM -0800, Jon Pan-Doh wrote:
> On Tue, Mar 4, 2025 at 10:32 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > It's true this is redundant information, but that e1000e device may
> > no longer be accessible.
> >
> > In that case, I think aer_get_device_error_info() would probably
> > return 0 because config reads would all return ~0, and
> > PCI_ERR_COR_STATUS & ~PCI_ERR_COR_MASK would be 0, so
> > we probably wouldn't see the e1000e messages at all.
> 
> Wouldn't we have larger issues if the device is no longer accessible?
> Would a log suffice in that case (i.e. when aer_get_device_error()
> returns 0)? Something along the lines of "{device} is not accessible
> while processing (un)correctable error"

It's quite likely that a device is inaccessible after an uncorrectable
error.

DPC takes the link down automatically for uncorrectable errors, but I
don't think aer_print_port_info() is used in that case anyway.

Documentation/PCI/pci-error-recovery.rst mentions other cases where
the affected device is disconnected.

If the purpose of this patch is only to turn this:

  pcieport 0000:00:04.0: Correctable error message received from 0000:01:00.0
  e1000e 0000:01:00.0: PCIe Bus Error: severity=Correctable, type=Data Link
Layer, (Receiver ID)
  e1000e 0000:01:00.0:   device [8086:10d3] error status/mask=00000040/0000e000
  e1000e 0000:01:00.0:    [ 6] BadTLP

into this:

  e1000e 0000:01:00.0: PCIe Bus Error: severity=Correctable, type=Data Link
Layer, (Receiver ID)
  e1000e 0000:01:00.0:   device [8086:10d3] error status/mask=00000040/0000e000
  e1000e 0000:01:00.0:    [ 6] BadTLP

I don't think it's worth it.

I guess the problem is that future patches rate limit the e1000e
messages, and we really need to rate limit the pcieport message using
the same e1000e ratelimit_state.  We do know the Requester ID of the
device, so maybe we could look up that ratelimit_state?

  reply	other threads:[~2025-03-05 22:35 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-14  2:35 [PATCH v2 0/8] Rate limit AER logs Jon Pan-Doh
2025-02-14  2:35 ` [PATCH v2 1/8] PCI/AER: Remove aer_print_port_info Jon Pan-Doh
2025-03-04 18:32   ` Bjorn Helgaas
2025-03-05  1:04     ` Jon Pan-Doh
2025-03-05 22:35       ` Bjorn Helgaas [this message]
2025-03-06  1:32         ` Jon Pan-Doh
2025-03-07  0:02           ` Bjorn Helgaas
2025-02-14  2:35 ` [PATCH v2 2/8] PCI/AER: Use the same log level for all messages Jon Pan-Doh
2025-02-17 11:25   ` Karolina Stolarek
2025-02-19  2:48     ` Jon Pan-Doh
2025-02-24 11:26       ` Karolina Stolarek
2025-02-28 22:25         ` Jon Pan-Doh
2025-03-04 18:59   ` Bjorn Helgaas
2025-03-07 12:04     ` Karolina Stolarek
2025-03-13 21:15       ` Jon Pan-Doh
2025-02-14  2:35 ` [PATCH v2 3/8] PCI/AER: Move AER stat collection out of __aer_print_error Jon Pan-Doh
2025-02-17 11:29   ` Karolina Stolarek
2025-02-19  2:48     ` Jon Pan-Doh
2025-02-24 11:26       ` Karolina Stolarek
2025-02-14  2:35 ` [PATCH v2 4/8] PCI/AER: Rename struct aer_stats to aer_report Jon Pan-Doh
2025-02-17 11:29   ` Karolina Stolarek
2025-02-19  2:49     ` Jon Pan-Doh
2025-02-14  2:35 ` [PATCH v2 5/8] PCI/AER: Introduce ratelimit for error logs Jon Pan-Doh
2025-02-17 11:29   ` Karolina Stolarek
2025-02-19  2:49     ` Jon Pan-Doh
2025-02-14  2:35 ` [PATCH v2 6/8] PCI/AER: Add ratelimits to PCI AER Documentation Jon Pan-Doh
2025-02-17 11:30   ` Karolina Stolarek
2025-02-14  2:35 ` [PATCH v2 7/8] PCI/AER: Add AER sysfs attributes for log ratelimits Jon Pan-Doh
2025-02-17 13:31   ` Karolina Stolarek
2025-02-19  2:50     ` Jon Pan-Doh
2025-02-24 11:28       ` Karolina Stolarek
2025-02-19  5:42     ` Jon Pan-Doh
2025-02-25 13:56   ` Karolina Stolarek
2025-02-28 22:28     ` Jon Pan-Doh
2025-03-03  8:31       ` Karolina Stolarek
2025-03-04  0:58         ` Jon Pan-Doh
2025-03-07 12:10           ` Karolina Stolarek
2025-03-07 19:41             ` Bjorn Helgaas
2025-02-14  2:35 ` [PATCH v2 8/8] PCI/AER: Update AER sysfs ABI filename Jon Pan-Doh

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=20250305223540.GA312467@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=anilagrawal@meta.com \
    --cc=ben.fuller@oracle.com \
    --cc=bhelgaas@google.com \
    --cc=drewwalton@microsoft.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=karolina.stolarek@oracle.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=martin.petersen@oracle.com \
    --cc=pandoh@google.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=tony.luck@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.