From: poza@codeaurora.org
To: Keith Busch <keith.busch@intel.com>
Cc: Linux PCI <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Sinan Kaya <okaya@codeaurora.org>,
linux-pci-owner@vger.kernel.org
Subject: Re: [PATCH 5/7] PCI/DPC: Print AER status in DPC event handling
Date: Fri, 22 Jun 2018 15:41:50 +0530 [thread overview]
Message-ID: <f25c5f839166d0f94fc8a1b6def2fe14@codeaurora.org> (raw)
In-Reply-To: <20180621140525.GB26623@localhost.localdomain>
On 2018-06-21 19:35, Keith Busch wrote:
> On Thu, Jun 21, 2018 at 02:46:10PM +0530, poza@codeaurora.org wrote:
>> On 2018-06-21 03:08, Keith Busch wrote:
>> > @@ -185,6 +187,10 @@ static void dpc_work(struct work_struct *work)
>> > /* show RP PIO error detail information */
>> > if (dpc->rp_extensions && reason == 3 && ext_reason == 0)
>> > dpc_process_rp_pio_error(dpc);
>> > + else if (reason == 0 && aer_get_device_error_info(pdev, &info)) {
>> > + aer_print_error(pdev, &info);
>> > + pci_cleanup_aer_uncorrect_error_status(pdev);
>>
>> 6.2.10 for Downstream Port Containment:
>>
>> When DPC is triggered due to receipt of an uncorrectable error
>> Message,
>> the Requester ID from the Message is recorded in the DPC Error
>> Source ID register and that Message is discarded and not forwarded
>> Upstream. When DPC is triggered by an unmasked uncorrectable error,
>> that error will not be signaled with an uncorrectable error Message,
>> even if otherwise enabled.
>>
>> Inst the message is discarded and not forwarded to upstream.
>> which means that we should not find AER status set in RP or Switch.
>> in other words, at time either we will find DPC or AER triggered but
>> not
>> both at the same time.
>> then when DPC is triggered why do we need to
>> pci_cleanup_aer_uncorrect_error_status(pdev); ?
>
> According to the sequence diagram in 6.2.5, an uncorrectable error has
> the cooresponding bits set in the Device Status and AER Uncorrectable
> Error Status registers before DPC specifics are considered. DPC just
> suppresses the ERR_[NON]FATAL messages, but the detecting ports AER
> status, if implemented, should reflect what occured.
Hi Keith,
was thinking that current code
pcie_do_fatal_recovery already does call
if ((service == PCIE_PORT_SERVICE_AER) &&
(dev->hdr_type == PCI_HEADER_TYPE_BRIDGE)) {
/*
* If the error is reported by a bridge, we think this error
* is related to the downstream link of the bridge, so we
* do error recovery on all subordinates of the bridge instead
* of the bridge and clear the error status of the bridge.
*/
pci_cleanup_aer_uncorrect_error_status(dev);
}
instead of calling it here in dpc driver, can we make use of that
existing call ?
probably we just might need to remove
if ((service == PCIE_PORT_SERVICE_AER) condition
Regards,
Oza.
next prev parent reply other threads:[~2018-06-22 10:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 21:38 [PATCH 1/7] PCI/DPC: Leave interrupts enabled while handling event Keith Busch
2018-06-20 21:38 ` [PATCH 2/7] PCI/DPC: Defer event handling to work queue Keith Busch
2018-06-21 7:27 ` Christoph Hellwig
2018-06-21 7:28 ` Christoph Hellwig
2018-06-21 13:58 ` Keith Busch
2018-06-20 21:38 ` [PATCH 3/7] PCI/DPC: Remove rp_pio_status from dpc struct Keith Busch
2018-06-20 21:38 ` [PATCH 4/7] PCI/AER: API for obtaining AER information Keith Busch
2018-06-20 21:38 ` [PATCH 5/7] PCI/DPC: Print AER status in DPC event handling Keith Busch
2018-06-21 9:16 ` poza
2018-06-21 14:05 ` Keith Busch
2018-06-22 5:25 ` poza
2018-06-22 10:11 ` poza [this message]
2018-06-22 14:10 ` Keith Busch
2018-06-20 21:38 ` [PATCH 6/7] PCI/DPC: Use threaded IRQ for bottom half handling Keith Busch
2018-06-21 7:29 ` Christoph Hellwig
2018-06-20 21:38 ` [PATCH 7/7] PCI/DPC: Remove indirection waiting for inactive link Keith Busch
2018-06-20 21:42 ` [PATCH 1/7] PCI/DPC: Leave interrupts enabled while handling event Sinan Kaya
2018-06-20 21:54 ` Keith Busch
2018-06-20 21:59 ` Sinan Kaya
2018-06-22 5:26 ` poza
2018-07-16 22:07 ` 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=f25c5f839166d0f94fc8a1b6def2fe14@codeaurora.org \
--to=poza@codeaurora.org \
--cc=bhelgaas@google.com \
--cc=keith.busch@intel.com \
--cc=linux-pci-owner@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=okaya@codeaurora.org \
/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.