From: Bart Van Assche <bvanassche@acm.org>
To: Keith Busch <kbusch@kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Mikulas Patocka <mpatocka@redhat.com>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] nvme: Boot as soon as the boot controller has been probed
Date: Wed, 18 Nov 2020 19:08:49 -0800 [thread overview]
Message-ID: <fa3eb5e6-7864-ecce-df92-fd7a2b913f3a@acm.org> (raw)
In-Reply-To: <20201112142024.GB2573679@dhcp-10-100-145-180.wdc.com>
On 11/12/20 6:20 AM, Keith Busch wrote:
> The easiest check is something like this (as long as you're not actively
> using your nvme namespaces):
>
> # echo 1 | tee /sys/class/nvme/nvme*/device/remove
> # echo 1 > /sys/bus/pci/rescan
>
> The subsequent probes don't go through the async_schedule. They have
> this stack instead:
>
> [ 44.528906] Call Trace:
> [ 44.530512] dump_stack+0x6d/0x88
> [ 44.532373] nvme_probe+0x2f/0x59b [nvme]
> [ 44.534466] local_pci_probe+0x3d/0x70
> [ 44.536471] pci_device_probe+0x107/0x1b0
> [ 44.538562] really_probe+0x1be/0x410
> [ 44.540564] driver_probe_device+0xe1/0x150
> [ 44.542733] ? driver_allows_async_probing+0x50/0x50
> [ 44.545170] bus_for_each_drv+0x7b/0xc0
> [ 44.547172] __device_attach+0xeb/0x170
> [ 44.549163] pci_bus_add_device+0x4a/0x70
> [ 44.551182] pci_bus_add_devices+0x2c/0x70
> [ 44.553229] pci_rescan_bus+0x25/0x30
> [ 44.555126] rescan_store+0x61/0x90
> [ 44.556975] kernfs_fop_write+0xcb/0x1b0
> [ 44.558940] vfs_write+0xbe/0x200
> [ 44.560710] ksys_write+0x5f/0xe0
> [ 44.562483] do_syscall_64+0x2d/0x40
> [ 44.564354] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Hi Keith,
Thanks for the feedback. I will look further into this but I wouldn't
mind if someone else would come up with a solution before I have a
solution ready.
Bart.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-11-19 3:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-08 4:09 [PATCH] nvme: Boot as soon as the boot controller has been probed Bart Van Assche
2020-11-08 8:24 ` Greg KH
2020-11-08 22:31 ` Keith Busch
2020-11-08 23:35 ` Bart Van Assche
2020-11-09 2:35 ` Keith Busch
2020-11-09 4:00 ` Bart Van Assche
2020-11-09 15:05 ` Keith Busch
2020-11-10 2:51 ` Bart Van Assche
2020-11-10 3:12 ` Keith Busch
2020-11-08 19:13 ` Sagi Grimberg
2020-11-08 19:18 ` Greg KH
2020-11-08 23:00 ` Bart Van Assche
2020-11-09 3:04 ` Keith Busch
2020-11-11 19:19 ` Keith Busch
2020-11-12 4:26 ` Bart Van Assche
2020-11-12 14:20 ` Keith Busch
2020-11-19 3:08 ` Bart Van Assche [this message]
2020-11-19 20:18 ` 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=fa3eb5e6-7864-ecce-df92-fd7a2b913f3a@acm.org \
--to=bvanassche@acm.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mpatocka@redhat.com \
--cc=sagi@grimberg.me \
/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