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