aw_

You know the root cause of this is that your NVMe device is broken, right? It corrupts its own MSI-X capability on FLR. Maybe point some of your frustration at the device vendor or buy an NVMe device that just works.

This will become easier when QEMU 4.0 is released as any VM making use of the new 4.0 machine version will automatically get their PCIe root ports upgraded. The upstream patch needs to maintain backwards compatibility for migration when older machine versions are used, thus requiring XML modding in the interim.

Not to be pedantic, but this was resolved through an AGESA update, the patch never made it into the kernel, though it was helpful in identifying the issue.

I've updated the patch in https://bugzilla.kernel.org/show_bug.cgi?id=202055 for the native Silicon Motion PCI vendor and device ID, perhaps there are guides to build your own patched Unraid kernel or someone can build a test kernel for you.

Everyone experiencing this issue who has an NVMe drive making use of the SM2262 controller, please: - Report the device model - Report the PCI vendor and device IDs (lspci -nn) - Step through comments 1 and 10 in https://bugzilla.kernel.org/show_bug.cgi?id=202055 to verify the device behaves the same, particularly the MSI-X Count is initially 16, after reset it's reported as 22, but the value remains 16 if a secondary bus reset is triggered via setpci. There's also a patch there for testing, but it only includes the Intel 760p device ID, we'll need to compile a list of all affected device IDs or figure out if there's a way to interrogate the NVMe controller interface to find the these chips since it seems to be in use by Intel, Mushkin, ADATA, and WD. Thanks