From: muhlemmer@gmail.com (Tim Mohlmann)
Subject: nvme device timeout
Date: Tue, 29 Mar 2016 20:17:11 +0300 [thread overview]
Message-ID: <56FAB897.30201@gmail.com> (raw)
In-Reply-To: <20160329143818.GC27195@localhost.localdomain>
The last patch worked and made my nvme device to show again, with UEFI
disabled. Tested against vanilla 4.5.0 sources
Like I wrote in other messages in this thread, before upgrading to 4.5 I
ran into problems about the nvme not showing when UEFI boot is enabled.
I assume this is something completely different. Should I open a new
thread in this ML, file a bug at kernel.org or use the lkml?
On 03/29/2016 05:38 PM, Keith Busch wrote:
> Thanks, good catch!
>
> Have you confirmed that this controller is indeed relying on polling
> completions during early init, or do you want to try a fix for kthread
> polling? The test patch is appeneded below if you still need to confirm
> it.
>
> If the controller really doesn't work with legacy interrupts, would it
> be possible to permanently set the PCI interrupt pin register to 0? You
> shouldn't advertise the capability if it doesn't work, and the driver
> would have used MSI-x if that was the case.
>
> If we absolutely need to add a quirk, either polling or force using
> MSI-x sound like possible solutions.
>
> ---
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 680f578..05eb152 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -1371,12 +1371,6 @@ static int nvme_kthread(void *data)
> int i;
> u32 csts = readl(dev->bar + NVME_REG_CSTS);
>
> - /*
> - * Skip controllers currently under reset.
> - */
> - if (work_pending(&dev->reset_work) || work_busy(&dev->reset_work))
> - continue;
> -
> if ((dev->subsystem && (csts & NVME_CSTS_NSSRO)) ||
> csts & NVME_CSTS_CFS) {
> if (queue_work(nvme_workq, &dev->reset_work)) {
> @@ -1945,17 +1939,16 @@ static void nvme_reset_work(struct work_struct *work)
> if (result)
> goto out;
>
> - result = nvme_init_identify(&dev->ctrl);
> + dev->ctrl.event_limit = NVME_NR_AEN_COMMANDS;
> + result = nvme_dev_list_add(dev);
> if (result)
> goto out;
>
> - result = nvme_setup_io_queues(dev);
> + result = nvme_init_identify(&dev->ctrl);
> if (result)
> goto out;
>
> - dev->ctrl.event_limit = NVME_NR_AEN_COMMANDS;
> -
> - result = nvme_dev_list_add(dev);
> + result = nvme_setup_io_queues(dev);
> if (result)
> goto out;
>
> --
>
next prev parent reply other threads:[~2016-03-29 17:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1604554248.106551459228253752.JavaMail.weblogic@epmlwas03c>
2016-03-29 14:38 ` nvme device timeout Keith Busch
2016-03-29 17:17 ` Tim Mohlmann [this message]
2016-04-01 16:02 ` Derrick, Jonathan
2016-04-01 16:25 ` Derrick, Jonathan
2016-03-28 16:44 Tim Mohlmann
2016-03-28 17:24 ` Keith Busch
2016-03-28 22:30 ` Judy Brock-SSI
2016-03-28 22:54 ` Keith Busch
2016-03-29 7:03 ` Christoph Hellwig
2016-03-29 11:04 ` Judy Brock-SSI
2016-03-29 11:06 ` Christoph Hellwig
2016-03-29 14:42 ` Matthew Wilcox
2016-03-29 16:52 ` Tim Mohlmann
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=56FAB897.30201@gmail.com \
--to=muhlemmer@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 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.