[6.18.y] Fixes for USB4/NVME hotplugging

[6.18.y] Fixes for USB4/NVME hotplugging

[Mario Limonciello]

Hi,

Some of my colleagues (on CC) have been chasing an issue where some 
percentage of the time USB4 NVME enclosures weren't working properly on 
hotplug.  They narrowed down the PCIe traces and found that it was 
caused by a race condition between multiple drivers shortly after link 
training.

This issue traces back a while, they reproduced it as far back as 6.14, 
but that's mostly because the hardware it was first reproduced on had 
graphics enabled in 6.14.  Given the root cause, I strongly hardware 
enabled with earlier kernels would also reproduce it.  Nonetheless the 
issue has actually already been fixed though by a series that went into 
6.19.

commit a2f1e22390ac ("PCI/ERR: Ensure error recoverability at all times")
commit 383d89699c50 ("treewide: Drop pci_save_state() after 
pci_restore_state()")

Can we bring this back to 6.18.y too?

If any questions about the methodology or details, they can add more.

Thanks,

Re: [6.18.y] Fixes for USB4/NVME hotplugging

[Greg KH]

On Wed, Feb 04, 2026 at 02:06:15PM -0600, Mario Limonciello wrote:
> Hi,
> 
> Some of my colleagues (on CC) have been chasing an issue where some
> percentage of the time USB4 NVME enclosures weren't working properly on
> hotplug.  They narrowed down the PCIe traces and found that it was caused by
> a race condition between multiple drivers shortly after link training.
> 
> This issue traces back a while, they reproduced it as far back as 6.14, but
> that's mostly because the hardware it was first reproduced on had graphics
> enabled in 6.14.  Given the root cause, I strongly hardware enabled with
> earlier kernels would also reproduce it.  Nonetheless the issue has actually
> already been fixed though by a series that went into 6.19.
> 
> commit a2f1e22390ac ("PCI/ERR: Ensure error recoverability at all times")
> commit 383d89699c50 ("treewide: Drop pci_save_state() after
> pci_restore_state()")
> 
> Can we bring this back to 6.18.y too?
> 
> If any questions about the methodology or details, they can add more.

Now queued up, thanks.

greg k-h