After a failed reset, vfio_pci_core_disable() unconditionally calls pci_restore_state(). When the device did not come back (FLR timed out, config reads return ~0), restoring state walks the extended capability list and rewrites the whole config space. Every one of those accesses stalls for a completion timeout, so the host spends minutes in soft lockups instead of failing fast. Seen with an NVIDIA RTX PRO 6000 Blackwell Max-Q (10de:2bb4) on vfio-pci after the guest was terminated (Ubuntu 6.8.0-147, code path unchanged in v7.3): vfio-pci 0000:81:00.0: not ready 65535ms after FLR; giving up watchdog: BUG: soft lockup - CPU#9 stuck for 28s! [worker:361063] RIP: 0010:pci_mmcfg_read+0xba/0x110 Call Trace: pci_read_config_dword+0x27/0x50 pci_find_next_ext_capability+0x83/0xe0 pci_find_ext_capability+0x12/0x20 pci_restore_ltr_state+0x29/0x60 pci_restore_state+0x16/0x270 vfio_pci_core_disable+0x339/0x440 [vfio_pci_core] vfio_pci_core_close_device+0x68/0xe0 [vfio_pci_core] 191 soft lockups followed over ~2.7 hours, until the host was power cycled. The device itself is a separate (firmware) problem and stays dead either way; this patch only stops the host from hammering it. pci_save_state() and pcie_flr() already bail out through pci_dev_config_accessible(); do the same in pci_restore_state(). Signed-off-by: Patryk Janik --- RFC: written against v7.3 (master 21a7f44fd076); not tested on hardware yet. Happy to test a revised version on the affected machine. Full report, timeline, nvidia-bug-report.log and the complete kernel log of the failing boot are attached to the NVIDIA forum topic: https://forums.developer.nvidia.com/t/386790 Related: - "PCI: Avoid FLR for NVIDIA 5090 GPU" (linux-pci, 2026-04-16), where the underlying FLR failure was described as a known device firmware defect. - nova-core "run unload sequence" series (merged v7.2), which mentions a Blackwell VBIOS bug that sometimes breaks the GPU upon PCI reset. drivers/pci/pci.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1883,6 +1883,16 @@ */ void pci_restore_state(struct pci_dev *dev) { + /* + * A device that did not come back from reset (e.g. an FLR that + * timed out) returns ~0 for every config read. Restoring state + * would walk the extended capability list and write the whole + * config space, each access stalling for a completion timeout, + * which shows up as minutes of soft lockups. Bail out instead. + */ + if (!pci_dev_config_accessible(dev, "restore state")) + return; + pci_restore_pcie_state(dev); pci_restore_pasid_state(dev); pci_restore_pri_state(dev); -- 2.47.0