From: Keith Busch <keith.busch@intel.com>
To: Alex_Gagniuc@Dellteam.com
Cc: linux-pci@vger.kernel.org, bhelgaas@google.com, lukas@wunner.de,
Austin.Bolen@dell.com
Subject: Re: PCI: hotplug: Erroneous removal of hotplug PCI devices
Date: Wed, 23 Jan 2019 11:44:53 -0700 [thread overview]
Message-ID: <20190123184453.GB6629@localhost.localdomain> (raw)
In-Reply-To: <356432a0556d4da59f8ba5cf1d750019@ausx13mps317.AMER.DELL.COM>
On Wed, Jan 23, 2019 at 06:20:57PM +0000, Alex_Gagniuc@Dellteam.com wrote:
> Hi all,
>
> This may be a mind-twisting explanation, so pleas bear with me.
>
> In PCIe, the presence detect bit (PD) in the slot status register should
> be a logical OR of in-band and out-of band presence. In-band presence is
> the data link layer status. So one would expect that a link up event,
> would be accompanied by a PD changed event with PD set. Not everyone
> follows that.
>
> I have a system here with the following order of events:
> * 0 ms : Link up
> * 400 ms : Presence detect up
> On the first event, the device is probed as expected, and on the second
> event, the device is removed as a SURPRISE!!!_REMOVAL. This is a bug.
>
> The logic is that on every change of presence detect:
> /* Even if [the slot]'s occupied again, we cannot assume the card is the
> same. */
> Reasonable, but the resulting behavior is a bug.
>
> Solution 1 is to say it's a spec violation, so ignore it. They'll change
> the "logical OR" thing in the next PCIe spec, so we still will have to
> worry about this.
When's that changing? 5.0 is the next spec, and it still says:
Presence Detect State - This bit indicates the presence of an adapter
in the slot, reflected by the logical “OR” of the Physical Layer
in-band presence detect mechanism and, if present, any out-of-band
presence detect mechanism defined for the slot’s corresponding
form factor.
> It's obvious that just relying on presence detect state is prone to race
> conditions. However, if a device is replaced, we'd expect the data link
> layer state to change as well. So I think the best way to proceed is to
> skip the SURPRISE!!!_REMOVAL if the following are true:
> * presence detect is set
> * DLL changed is not set
> * presence detect was not previously set
>
> Thoughts?
What is the value of PDS on the Link up event? If it's still "Slot
Empty", could we just ignore the Link event instead and wait for the PDC
event?
next prev parent reply other threads:[~2019-01-23 18:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 18:20 PCI: hotplug: Erroneous removal of hotplug PCI devices Alex_Gagniuc
2019-01-23 18:44 ` Keith Busch [this message]
2019-01-23 19:02 ` Lukas Wunner
2019-01-23 19:07 ` Keith Busch
2019-01-23 19:15 ` Lukas Wunner
2019-01-23 19:33 ` Keith Busch
2019-01-24 22:43 ` Austin.Bolen
2019-01-24 22:52 ` Austin.Bolen
[not found] ` <b32e6ca62ae2494f98450df81ca1ee14@AUSX13MPC131.AMER.DELL.COM>
2019-01-24 20:20 ` Keith Busch
2019-01-24 22:00 ` Austin.Bolen
2019-01-25 8:22 ` Lukas Wunner
2019-01-25 22:39 ` Austin.Bolen
2019-01-26 12:12 ` Lukas Wunner
2019-01-30 14:28 ` Austin.Bolen
2019-01-23 18:54 ` Lukas Wunner
2019-01-23 19:07 ` Lukas Wunner
2019-01-23 19:09 ` Keith Busch
2019-01-23 19:28 ` Lukas Wunner
2019-01-23 19:47 ` Keith Busch
2019-01-23 20:10 ` Alex_Gagniuc
2019-01-23 23:50 ` Alex_Gagniuc
2019-01-24 9:25 ` Lukas Wunner
2019-01-24 22:33 ` Austin.Bolen
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=20190123184453.GB6629@localhost.localdomain \
--to=keith.busch@intel.com \
--cc=Alex_Gagniuc@Dellteam.com \
--cc=Austin.Bolen@dell.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
/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