regression on aarch64? panic on boot
Ville Syrjälä
ville.syrjala at linux.intel.com
Tue Jan 24 09:11:39 PST 2023
On Thu, Jan 19, 2023 at 09:48:56AM -0700, Keith Busch wrote:
> On Tue, Jan 17, 2023 at 07:37:35AM +0100, Christoph Hellwig wrote:
> > On Tue, Jan 17, 2023 at 07:31:59AM +0100, Klaus Jensen wrote:
> > > Good morning Christoph,
> > >
> > > Yep, the above works.
> >
> > Context for the newly added: This is dropping the newly added
> > PROBE_PREFER_ASYNCHRONOUS in nvme, which causes Klaus' arm64 (but not
> > other boot tests) to fail. Any idea what could be going wrong there
> > probably in userspace?
>
> Prior to 6.2, the driver would do it's own async_schedule, and that
> async probe function would flush the first scan work.
> wait_for_device_probe() was then forced to wait for the scan_work to
> complete, which brings up the root device.
>
> We're not flushing the scan_work anymore from our probe, so this should
> fix it for 6.2:
Appears to fix my Tigerlake Thinkpad T14 gen2.
Tested-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
>
> ---
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index b294b41a149a7..ff97426749976 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -3046,6 +3046,7 @@ static int nvme_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>
> nvme_start_ctrl(&dev->ctrl);
> nvme_put_ctrl(&dev->ctrl);
> + flush_work(&dev->ctrl.scan_work);
> return 0;
>
> out_disable:
> --
>
--
Ville Syrjälä
Intel
More information about the Linux-nvme
mailing list