From: Bjorn Helgaas <helgaas@kernel.org>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: linux-pci@vger.kernel.org,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Oliver O'Halloran <oohall@gmail.com>,
Robert Richter <rrichter@amd.com>,
Terry Bowman <terry.bowman@amd.com>,
Kai-Heng Feng <kai.heng.feng@canonical.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 2/3] PCI/AER: Decode Requester ID when no error info found
Date: Tue, 2 Jan 2024 16:53:27 -0600 [thread overview]
Message-ID: <20240102225327.GA1739520@bhelgaas> (raw)
In-Reply-To: <6cc6adf0-e82d-4429-9e76-5fef7dda2d95@linux.intel.com>
On Tue, Jan 02, 2024 at 11:22:53AM -0800, Kuppuswamy Sathyanarayanan wrote:
> On 12/6/2023 2:42 PM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas <bhelgaas@google.com>
> >
> > When a device with AER detects an error, it logs error information in its
> > own AER Error Status registers. It may send an Error Message to the Root
> > Port (RCEC in the case of an RCiEP), which logs the fact that an Error
> > Message was received (Root Error Status) and the Requester ID of the
> > message source (Error Source Identification).
> >
> > aer_print_port_info() prints the Requester ID from the Root Port Error
> > Source in the usual Linux "bb:dd.f" format, but when find_source_device()
> > finds no error details in the hierarchy below the Root Port, it printed the
> > raw Requester ID without decoding it.
> >
> > Decode the Requester ID in the usual Linux format so it matches other
> > messages.
> >
> > Sample message changes:
> >
> > - pcieport 0000:00:1c.5: AER: Correctable error received: 0000:00:1c.5
> > - pcieport 0000:00:1c.5: AER: can't find device of ID00e5
> > + pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5
> > + pcieport 0000:00:1c.5: AER: found no error details for 0000:00:1c.5
> >
> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>
> Except for the suggestion given below, it looks good to me.
>
> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Thanks for taking a look!
> > @@ -740,7 +740,7 @@ static void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info)
> > u8 bus = info->id >> 8;
> > u8 devfn = info->id & 0xff;
> >
> > - pci_info(dev, "%s%s error received: %04x:%02x:%02x.%d\n",
> > + pci_info(dev, "%s%s error message received from %04x:%02x:%02x.%d\n",
> > info->multi_error_valid ? "Multiple " : "",
> > aer_error_severity_string[info->severity],
> > pci_domain_nr(dev->bus), bus, PCI_SLOT(devfn),
> > @@ -929,7 +929,12 @@ static bool find_source_device(struct pci_dev *parent,
> > pci_walk_bus(parent->subordinate, find_device_iter, e_info);
> >
> > if (!e_info->error_dev_num) {
> > - pci_info(parent, "can't find device of ID%04x\n", e_info->id);
> > + u8 bus = e_info->id >> 8;
> > + u8 devfn = e_info->id & 0xff;
>
> You can use PCI_BUS_NUM(e_info->id) for getting bus number. Since
> you are extracting this info in more than one place, maybe you can
> also define a macro PCI_DEVFN(id) (following PCI_BUS_NUM()).
Thanks, both good ideas.
We already have a PCI_DEVFN() that *combines* slot + func into devfn,
so we'd have to come up with a different name.
I'll add a patch to use PCI_BUS_NUM() in the two places here and in
pme.c.
I think I'll wait with these until after the v6.7 release.
> > + pci_info(parent, "found no error details for %04x:%02x:%02x.%d\n",
> > + pci_domain_nr(parent->bus), bus, PCI_SLOT(devfn),
> > + PCI_FUNC(devfn));
> > return false;
> > }
> > return true;
>
> --
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Robert Richter <rrichter@amd.com>,
Terry Bowman <terry.bowman@amd.com>,
linux-pci@vger.kernel.org,
Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
linux-kernel@vger.kernel.org,
Kai-Heng Feng <kai.heng.feng@canonical.com>,
Oliver O'Halloran <oohall@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/3] PCI/AER: Decode Requester ID when no error info found
Date: Tue, 2 Jan 2024 16:53:27 -0600 [thread overview]
Message-ID: <20240102225327.GA1739520@bhelgaas> (raw)
In-Reply-To: <6cc6adf0-e82d-4429-9e76-5fef7dda2d95@linux.intel.com>
On Tue, Jan 02, 2024 at 11:22:53AM -0800, Kuppuswamy Sathyanarayanan wrote:
> On 12/6/2023 2:42 PM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas <bhelgaas@google.com>
> >
> > When a device with AER detects an error, it logs error information in its
> > own AER Error Status registers. It may send an Error Message to the Root
> > Port (RCEC in the case of an RCiEP), which logs the fact that an Error
> > Message was received (Root Error Status) and the Requester ID of the
> > message source (Error Source Identification).
> >
> > aer_print_port_info() prints the Requester ID from the Root Port Error
> > Source in the usual Linux "bb:dd.f" format, but when find_source_device()
> > finds no error details in the hierarchy below the Root Port, it printed the
> > raw Requester ID without decoding it.
> >
> > Decode the Requester ID in the usual Linux format so it matches other
> > messages.
> >
> > Sample message changes:
> >
> > - pcieport 0000:00:1c.5: AER: Correctable error received: 0000:00:1c.5
> > - pcieport 0000:00:1c.5: AER: can't find device of ID00e5
> > + pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5
> > + pcieport 0000:00:1c.5: AER: found no error details for 0000:00:1c.5
> >
> > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>
> Except for the suggestion given below, it looks good to me.
>
> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Thanks for taking a look!
> > @@ -740,7 +740,7 @@ static void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info)
> > u8 bus = info->id >> 8;
> > u8 devfn = info->id & 0xff;
> >
> > - pci_info(dev, "%s%s error received: %04x:%02x:%02x.%d\n",
> > + pci_info(dev, "%s%s error message received from %04x:%02x:%02x.%d\n",
> > info->multi_error_valid ? "Multiple " : "",
> > aer_error_severity_string[info->severity],
> > pci_domain_nr(dev->bus), bus, PCI_SLOT(devfn),
> > @@ -929,7 +929,12 @@ static bool find_source_device(struct pci_dev *parent,
> > pci_walk_bus(parent->subordinate, find_device_iter, e_info);
> >
> > if (!e_info->error_dev_num) {
> > - pci_info(parent, "can't find device of ID%04x\n", e_info->id);
> > + u8 bus = e_info->id >> 8;
> > + u8 devfn = e_info->id & 0xff;
>
> You can use PCI_BUS_NUM(e_info->id) for getting bus number. Since
> you are extracting this info in more than one place, maybe you can
> also define a macro PCI_DEVFN(id) (following PCI_BUS_NUM()).
Thanks, both good ideas.
We already have a PCI_DEVFN() that *combines* slot + func into devfn,
so we'd have to come up with a different name.
I'll add a patch to use PCI_BUS_NUM() in the two places here and in
pme.c.
I think I'll wait with these until after the v6.7 release.
> > + pci_info(parent, "found no error details for %04x:%02x:%02x.%d\n",
> > + pci_domain_nr(parent->bus), bus, PCI_SLOT(devfn),
> > + PCI_FUNC(devfn));
> > return false;
> > }
> > return true;
>
> --
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer
next prev parent reply other threads:[~2024-01-02 22:53 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 22:42 [PATCH 0/3] PCI/AER: Clean up logging Bjorn Helgaas
2023-12-06 22:42 ` Bjorn Helgaas
2023-12-06 22:42 ` [PATCH 1/3] PCI/AER: Use 'Correctable' and 'Uncorrectable' spec terms for errors Bjorn Helgaas
2023-12-06 22:42 ` Bjorn Helgaas
2023-12-08 14:36 ` Jonathan Cameron
2023-12-08 14:36 ` Jonathan Cameron
2023-12-12 15:00 ` Terry Bowman
2023-12-12 15:00 ` Terry Bowman
2023-12-12 21:23 ` Bjorn Helgaas
2023-12-12 21:23 ` Bjorn Helgaas
2023-12-12 22:42 ` Bowman, Terry
2024-01-02 19:23 ` Kuppuswamy Sathyanarayanan
2024-01-02 19:23 ` Kuppuswamy Sathyanarayanan
2023-12-06 22:42 ` [PATCH 2/3] PCI/AER: Decode Requester ID when no error info found Bjorn Helgaas
2023-12-06 22:42 ` Bjorn Helgaas
2023-12-08 14:38 ` Jonathan Cameron
2023-12-08 14:38 ` Jonathan Cameron
2023-12-12 15:00 ` Terry Bowman
2023-12-12 15:00 ` Terry Bowman
2024-01-02 19:22 ` Kuppuswamy Sathyanarayanan
2024-01-02 19:22 ` Kuppuswamy Sathyanarayanan
2024-01-02 22:53 ` Bjorn Helgaas [this message]
2024-01-02 22:53 ` Bjorn Helgaas
2023-12-06 22:42 ` [PATCH 3/3] PCI/AER: Use explicit register sizes for struct members Bjorn Helgaas
2023-12-06 22:42 ` Bjorn Helgaas
2023-12-08 14:38 ` Jonathan Cameron
2023-12-08 14:38 ` Jonathan Cameron
2023-12-08 16:54 ` [PATCH 0/3] PCI/AER: Clean up logging Bjorn Helgaas
2023-12-08 16:54 ` 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=20240102225327.GA1739520@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mahesh@linux.ibm.com \
--cc=oohall@gmail.com \
--cc=rrichter@amd.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=terry.bowman@amd.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.