From: Sinan Kaya <okaya@codeaurora.org>
To: Keith Busch <keith.busch@intel.com>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Maik Broemme <mbroemme@libmpq.org>,
Pawandeep Oza <poza@codeaurora.org>
Subject: Re: [PATCH 4/4] PCI/DPC: Print AER status in DPC event handling
Date: Wed, 10 Jan 2018 10:52:23 -0500 [thread overview]
Message-ID: <ea609f8a-1d79-c2fe-e9e5-5993e418f9cc@codeaurora.org> (raw)
In-Reply-To: <20171221051256.GA15276@localhost.localdomain>
Hi Keith,
On 12/21/2017 12:12 AM, Keith Busch wrote:
> On Wed, Dec 20, 2017 at 11:43:07PM -0500, Sinan Kaya wrote:
>> +Oza
>>
>> On 12/19/2017 4:06 PM, Keith Busch wrote:
>>> A DPC enabled device will suppress sending ERR_FATAL and ERR_NONFATAL,
>>> which prevents the AER handler from reporting the details of the
>>> error. This patch will have the DPC driver get the AER status registers
>>> from the downstream port that detected the uncorrectable error, and
>>> print out additional information.
>>>
>>> Signed-off-by: Keith Busch <keith.busch@intel.com>
>>> ---
>>
>> Oza is doing some restructuring to unify DPC and AER error handling path per
>> feedback from Bjorn. It is almost done. He is testing it.
>>
>> Can this patch wait until you review his version? I'm thinking this could
>> be something that can be added to his series instead.
>
> No problem.
>
>> Coming back to this patch. The interrupt number for DPC and AER could be the
>> same or different.
>
> Only if you're talking about root ports. DPC is also a feature of
> switch downstream ports, which don't generate interrupts on AER events
> (they don't have a Root Error Command register).
>
>> According to the spec, AER errors are always reported
>> regardless of DPC driver presence (see the famous flow chart).
>
>> If the interrupt IDs are the same for AER and DPC, your patch would introduce
>> double printing for AER errors.
>
> The AER Uncorrectable Status Register of the detecting port would
> indeed be set with the appropriate status if that's the type of error
> that occured, but when DPC is enabled, the root port never observes an
> ERR_FATAL/ERR_NONFATAL message required for it to get set the Root Error
> Status Register. The Linux AER handler requires the Root Error Status
> be set in order for it to print anything, so I don't think we're at risk
> of double printing with this patch even if the root port is DPC capable.
>
Coming back to this. Oza posted his patch that integrates DPC into PORTDRV similar
to AER driver.
"[PATCH v3 0/4] Address error and recovery for AER and DPC"
We are looking for feedback on the series.
The idea in a nut shell is to collect all endpoint error recovery code into a
new file called pcie-err.c and then invoke callbacks before DPC driver shuts down
the currently active driver.
There is however, still one more problem that has not been tacked.
Since the AER status is set when we observe DPC event and nobody is clearing these
we won't observe another DPC event until somebody clears these. We can say that
we are resetting the endpoints as part of the DPC but we are not touching the
switch downstream port or the root port registers.
Somebody still needs to clear these in addition to printing whatever information
is available in the AER registers.
Do you agree?
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2018-01-10 15:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 21:06 [PATCH 1/4] PCI/AER: Return approrpiate value when AER is not supported Keith Busch
2017-12-19 21:06 ` [PATCH 2/4] PCI/AER: Provide API for getting AER information Keith Busch
2017-12-19 21:06 ` [PATCH 3/4] PCI/DPC: Enable DPC in conjuction with AER Keith Busch
2018-01-15 14:43 ` Sinan Kaya
2018-01-16 1:33 ` Keith Busch
2018-01-16 3:04 ` Sinan Kaya
2017-12-19 21:06 ` [PATCH 4/4] PCI/DPC: Print AER status in DPC event handling Keith Busch
2017-12-21 4:43 ` Sinan Kaya
2017-12-21 5:12 ` Keith Busch
2018-01-10 15:52 ` Sinan Kaya [this message]
2018-01-16 2:47 ` Keith Busch
2018-01-17 0:56 ` Bjorn Helgaas
2018-01-17 1:34 ` Keith Busch
2018-01-17 13:36 ` Sinan Kaya
2018-01-12 23:03 ` Bjorn Helgaas
2018-01-14 1:35 ` Keith Busch
2018-01-15 14:32 ` Sinan Kaya
2018-01-17 0:36 ` Bjorn Helgaas
2018-01-17 0:14 ` Bjorn Helgaas
2017-12-21 1:04 ` [PATCH 1/4] PCI/AER: Return approrpiate value when AER is not supported Bjorn Helgaas
2017-12-21 3:53 ` Dongdong Liu
2017-12-21 14:59 ` Keith Busch
2018-03-20 23:02 ` Bjorn Helgaas
2018-03-21 22:27 ` Keith Busch
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=ea609f8a-1d79-c2fe-e9e5-5993e418f9cc@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=bhelgaas@google.com \
--cc=keith.busch@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=mbroemme@libmpq.org \
--cc=poza@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox