[PATCH] nvme: Boot as soon as the boot controller has been probed
Keith Busch
kbusch at kernel.org
Thu Nov 19 15:18:04 EST 2020
On Wed, Nov 18, 2020 at 07:08:49PM -0800, Bart Van Assche wrote:
> 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.
I suppose you could just add the PROBE_PREFER_ASYNCHRONOUS probe_type,
and let nvme_probe() continue to attempt its own async initialization.
More information about the Linux-nvme
mailing list