From: Sinan Kaya <okaya@kernel.org>
To: Alex_Gagniuc@Dellteam.com, lukas@wunner.de
Cc: mr.nuke.me@gmail.com, keith.busch@intel.com,
linux-pci@vger.kernel.org, Austin.Bolen@dell.com,
Stuart.Hayes@dell.com, Narendra.K@dell.com,
Christopher.Arzola@dell.com, David.Chalfant@dell.com
Subject: Re: Should a PCIe Link Down event set the PCI_DEV_DISCONNECTED bit?
Date: Fri, 27 Jul 2018 11:34:53 -0700 [thread overview]
Message-ID: <7182b371-320c-6578-cc70-7c32220ac827@kernel.org> (raw)
In-Reply-To: <37ee3fa4e6334b5c8139a8d148fcf26a@ausx13mps321.AMER.DELL.COM>
On 7/27/2018 11:23 AM, Alex_Gagniuc@Dellteam.com wrote:
>> Completion timeouts are typically in the orders of 50ms. If you have a
>> lot of outstanding non-posted requests, it will take time for SW to
>> flush all requests.
> That's why we check pci_dev_is_disconnected() in pci/access.c
> But if the DISCONNECTED bit doesn't get set, it makes me wonder how
> solid things currently are.
I don't see any problem by setting this bit as long as the link is
down regardless of the drive presence state and clearing it on link
recovery.
Is there a problem with this approach? I'm catching up with this
thread.
pcie_do_fatal_recovery() doesn't query presence as an example.
next prev parent reply other threads:[~2018-07-27 19:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-26 22:38 Should a PCIe Link Down event set the PCI_DEV_DISCONNECTED bit? Alex G.
2018-07-26 23:00 ` Rajat Jain
2018-07-27 0:04 ` Alex_Gagniuc
2018-07-27 7:18 ` Lukas Wunner
2018-07-27 15:52 ` Alex_Gagniuc
2018-07-27 17:05 ` Lukas Wunner
2018-07-27 17:51 ` Alex_Gagniuc
2018-07-27 18:17 ` Sinan Kaya
2018-07-27 18:23 ` Alex_Gagniuc
2018-07-27 18:34 ` Sinan Kaya [this message]
2018-07-28 18:31 ` Lukas Wunner
2018-07-29 0:26 ` Sinan Kaya
2018-07-29 12:09 ` Lukas Wunner
2018-07-29 16:59 ` Sinan Kaya
2018-07-30 13:28 ` David Laight
2018-07-30 13:54 ` Lukas Wunner
2018-07-30 16:06 ` David Laight
2018-07-30 21:38 ` Alex_Gagniuc
2018-07-31 9:28 ` Lukas Wunner
2018-07-31 16:35 ` Alex_Gagniuc
2018-08-01 8:58 ` David Laight
2018-08-01 19:06 ` Alex_Gagniuc
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=7182b371-320c-6578-cc70-7c32220ac827@kernel.org \
--to=okaya@kernel.org \
--cc=Alex_Gagniuc@Dellteam.com \
--cc=Austin.Bolen@dell.com \
--cc=Christopher.Arzola@dell.com \
--cc=David.Chalfant@dell.com \
--cc=Narendra.K@dell.com \
--cc=Stuart.Hayes@dell.com \
--cc=keith.busch@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mr.nuke.me@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).