From: Bjorn Helgaas <helgaas@kernel.org>
To: JD Zheng <jiandong.zheng@broadcom.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
linux-pci@vger.kernel.org, keith.busch@intel.com,
bcm-kernel-feedback-list@broadcom.com,
Lukas Wunner <lukas@wunner.de>
Subject: Re: SSD surprise removal leads to long wait inside pci_dev_wait() and FLR 65s timeout
Date: Mon, 3 Jun 2019 18:05:12 -0500 [thread overview]
Message-ID: <20190603230512.GD58810@google.com> (raw)
In-Reply-To: <78f95dfe-ac2b-408f-0e2a-b3b9d69575dd@broadcom.com>
On Mon, Jun 03, 2019 at 02:17:36PM -0700, JD Zheng wrote:
> > On Sun, 2 Jun 2019 19:44:14 -0500
> > Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > Would you mind opening a report at https://bugzilla.kernel.org and
> > > attaching the complete dmesg log and "lspci -vv" output?
>
> I submitted one as https://bugzilla.kernel.org/show_bug.cgi?id=203797
>
> > > Out of curiosity, why do you use "pciehp.pciehp_poll_time=5"?
>
> This was chosen by other engineer. I tried shorter polling time, which
> doesn't make difference.
>
> I also tried pciehp.pciehp_poll_mode=0 but hotplug doesn't seem working.
> Should I use poll mode or not?
This is just a tangent to the real issue you're working; I'm not
suggesting any changes here to fix that issue.
In my mind, the existence of the pciehp.pciehp_poll_mode and
pciehp.pciehp_poll_time parameters is a defect in pciehp. I would far
rather that pciehp figured out by itself whether it needed to poll. I
don't know whether that's actually feasible, or if there's some reason
why pciehp can't be that smart.
Bjorn
prev parent reply other threads:[~2019-06-03 23:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 16:55 SSD surprise removal leads to long wait inside pci_dev_wait() and FLR 65s timeout JD Zheng
2019-06-03 0:44 ` Bjorn Helgaas
2019-06-03 1:40 ` Alex Williamson
2019-06-03 21:17 ` JD Zheng
2019-06-03 22:40 ` Alex Williamson
2019-06-03 23:05 ` Bjorn Helgaas [this message]
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=20190603230512.GD58810@google.com \
--to=helgaas@kernel.org \
--cc=alex.williamson@redhat.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=jiandong.zheng@broadcom.com \
--cc=keith.busch@intel.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 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.