RTX PRO 6000 Blackwell Max-Q (10de:2bb4): FLR fails on vfio-pci release after KVM guest shutdown, GPU inaccessible until cold power cycle

Graphics / Linux Linux
1

Summary: On an RTX PRO 6000 Blackwell Max-Q Workstation Edition (GB202, 10de:2bb4) used with KVM/VFIO passthrough, the Function Level Reset that vfio-pci issues when the guest releases the device did not complete (not ready 65535ms after FLR; giving up). From then on the device returned all-ones on config reads, the host logged repeated soft lockups in pci_restore_state() → pci_restore_ltr_state(), and the GPU stayed unusable. Only a cold power cycle via the BMC (power off, ~35 s, power on) restored the card. After that it passed bandwidth and load tests (PCIe Gen4 x16, ~28 GB/s H2D/D2H, 300 W sustained).

The same card had completed two earlier VFIO teardowns cleanly a few hours before (rebound to nvidia normally both times), so the failure is intermittent.

This looks like the same family as open-gpu-kernel-modules issue #1442 (stale WPR2 after abnormal GSP shutdown on GB202) and the linux-pci thread “PCI: Avoid FLR for NVIDIA 5090 GPU” (April 2026), where it was described as a known device firmware defect. I am reporting it here rather than on GitHub because the GitHub issue template requires confirming the bug is specific to the open kernel module, which I cannot: at the time of failure the device was bound to vfio-pci, not to the NVIDIA driver.

Environment
GPU NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition, 10de:2bb4 (+ audio 10de:22e8)
Board part / GPU part 900-5G153-2200-000 / 2BB4-865-A1
VBIOS 98.02.6A.00.03
InfoROM image G153.0520.00.02
Host driver NVIDIA Open Kernel Module 595.99.02
Host OS / kernel Ubuntu 24.04.3 LTS, 6.8.0-147-generic (distribution kernel)
Host cmdline (relevant) amd_iommu=on iommu=pt nvidia_drm.modeset=0
Platform Supermicro H12SSL-i, BIOS 3.7 (05/13/2026), AMD EPYC 7303
Topology GPU at 0000:81:00.0, root port 0000:80:01.1 (SltCap: PwrCtrl- HotPlug-)
reset_method flr bus (default)
Hypervisor QEMU/KVM 8.2 with vfio-pci passthrough of 81:00.0 + 81:00.1; Ubuntu guest with its own NVIDIA driver (guest driver version unknown)

lspci -vvv of the GPU (after recovery):

DevCap:  ... RBE+ FLReset+
DevCap2: Completion Timeout: Range AB, TimeoutDis+ NROPrPrP- LTR+
DevCtl2: Completion Timeout: 260ms to 900ms, TimeoutDis- LTR+ 10BitTagReq- OBFF Disabled,
LnkCap:  Port #0, Speed 32GT/s, Width x16, ASPM L1

Root port 0000:80:01.1:

LnkCap:  Port #0, Speed 16GT/s, Width x16, ASPM L1
SltCap:  AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
DevCtl2: Completion Timeout: 65ms to 210ms, TimeoutDis- LTR+ 10BitTagReq+ OBFF Disabled, ARIFwd+

Timeline (UTC, 2026-10-25)

time event
03:31:36 previous guest torn down — device rebound vfio-pci → nvidia cleanly
04:01:44 device handed from nvidia to vfio-pci for a new guest; NVRM warned about a non-zero usage count (a host monitoring process was likely still querying the GPU)
04:02:50 guest started
04:30:15 guest destroyed (QEMU process terminated)
04:30:17 → 04:31:28 vfio-pci FLR wait escalated and gave up after 65535 ms
04:31:54 → 07:14 191 soft lockups, 862 “device inaccessible” power-state messages; nvidia-smi: no GPUs found; setpci -s 81:00.0 0.l → ffffffff
07:14 cold power cycle via BMC (ForceOff, 35 s, On)
07:17 card back on nvidia, healthy

Logs

Hand-over to vfio-pci (04:01):

NVRM: Attempting to remove device 0000:81:00.0 with non-zero usage count!
NVRM: Continuing with GPU removal for device 0000:81:00.0
vfio-pci 0000:81:00.0: vgaarb: VGA decodes changed: olddecodes=none,decodes=io+mem:owns=none
snd_hda_intel 0000:81:00.1: GPU sound probed, but not operational: please add a quirk to driver_denylist
vfio-pci 0000:81:00.0: Enabling HDA controller

Release after guest teardown (04:30):

04:30:17 vfio-pci 0000:81:00.0: not ready 1023ms after FLR; waiting
04:30:18 vfio-pci 0000:81:00.0: not ready 2047ms after FLR; waiting
04:30:20 vfio-pci 0000:81:00.0: not ready 4095ms after FLR; waiting
04:30:25 vfio-pci 0000:81:00.0: not ready 8191ms after FLR; waiting
04:30:33 vfio-pci 0000:81:00.0: not ready 16383ms after FLR; waiting
04:30:50 vfio-pci 0000:81:00.0: not ready 32767ms after FLR; waiting
04:31:28 vfio-pci 0000:81:00.0: not ready 65535ms after FLR; giving up
04:31:34 clocksource: Long readout interval, skipping watchdog check: cs_nsec: 1318454778 wd_nsec: 1318454440

First soft lockup (module list trimmed):

watchdog: BUG: soft lockup - CPU#9 stuck for 28s! [worker:361063]
CPU: 9 PID: 361063 Comm: worker Tainted: G           O       6.8.0-147-generic #147-Ubuntu
Hardware name: Supermicro Super Server/H12SSL-i, BIOS 3.7 05/13/2026
RIP: 0010:pci_mmcfg_read+0xba/0x110
RAX: 00000000ffffffff RBX: 0000000008100000 RCX: 0000000000000ffc
Call Trace:
 <TASK>
 pci_read+0x55/0x90
 pci_bus_read_config_dword+0x4a/0x90
 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]
 vfio_df_close+0x5a/0xa0 [vfio]
 vfio_df_group_close+0x37/0x80 [vfio]
 vfio_device_fops_release+0x25/0x50 [vfio]
 __fput+0xa3/0x2e0
 ____fput+0xe/0x20
 task_work_run+0x61/0xa0
 do_exit+0x2be/0x530
 do_group_exit+0x35/0x90
 get_signal+0x96e/0x9b0
 ...

Afterwards, repeating until the power cycle (862 occurrences):

vfio-pci 0000:81:00.1: Unable to change power state from D0 to D3hot, device inaccessible
vfio-pci 0000:81:00.0: Unable to change power state from D3cold to D0, device inaccessible

Host side while in this state:

$ nvidia-smi
Failed to initialize NVML: No supported GPUs were found
$ sudo setpci -s 81:00.0 0.l
ffffffff
$ lspci -nn | grep 10de
81:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2bb4] (rev a1)
81:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22e8] (rev a1)
$ lspci -s 81:00.0 -vv | grep driver
	Kernel driver in use: vfio-pci

What recovered it

  • Cold power cycle (BMC power off ~35 s, then on): recovered fully. Post-recovery: nvidia driver bound, PCIe Gen4 x16 under load, CUDA bandwidthTest H2D 27.7 GB/s / D2H 27.6 GB/s / D2D 1439 GB/s, Result = PASS, sustained 300 W at 100 % utilization.
  • No secondary bus reset, rescan or driver reload was attempted while the device was in this state (the root port has no slot power control).

Attachments

  • nvidia-bug-report.log.gz — collected after recovery, on the current (healthy) boot. Journal lines from unrelated host-management services were removed; hostname, GPU serial and MAC addresses are redacted.
  • kernel-log-previous-boot-2026-10-25.log.gz — complete journalctl -k of the boot in which the failure happened, 03:30–07:16 UTC (the FLR timeout, all soft lockups and the power-state messages).

Questions

  1. Is this the known Blackwell firmware defect discussed on linux-pci in April 2026, and does it also affect the Max-Q (10de:2bb4) with VBIOS 98.02.6A.00.03?
  2. Is there a VBIOS / firmware version for the RTX PRO 6000 Blackwell Max-Q that fixes FLR after passthrough, and how should a Max-Q owner obtain it?
  3. Is there a recommended host-side mitigation (reset method, driver/kernel version, guest-side setting) until a firmware fix is available?

Happy to provide more logs or test a build.
kernel-log-previous-boot-2026-10-25.log.gz (82.1 KB)
nvidia-bug-report.log.gz (342.3 KB)

2

Follow-up after reading the open-source side (Linux v6.8 / v7.3, open-gpu-kernel-modules 595.99.02 / 615.78.08, nova-core and the linux-pci threads). I think this is two separate problems.

1. The card not coming back (firmware)

My reading of the code, happy to be corrected:

  1. The guest was terminated, so its driver never sent GSP-RM the unload message. On GB202 the WPR2 region is torn down only by firmware after that message; the host-side open code has no Booter-unload / FWSEC-SB path for GB20x (that path is Turing–Ada only).
  2. vfio-pci then issued an FLR. After FLR the device answers “not ready” until FSP finishes booting (comments in kernel_bif.c and kernel_bif_gb202.c). With GSP/WPR2 left up, that boot apparently never finished → not ready 65535ms after FLR; giving up.
  3. This matches the nova-core unload series (merged in v7.2), where the cover letter mentions “a nasty bug in the Blackwell VBIOS that sometimes borks the GPU upon PCI reset”, and the linux-pci thread on 5090 FLR where it was called a known device firmware defect with good and bad firmware versions.
  4. A secondary bus reset did not help either: the kernel tried one about 90 minutes later and the link never came back.

Questions:

  • Is there (or will there be) firmware where the post-FLR FSP boot tolerates GSP/WPR2 left running by a guest that was not shut down cleanly? Which VBIOS versions are the “good” ones, and does any of them cover the Max-Q (10de:2bb4, currently 98.02.6A.00.03)?
  • Until then, would NVIDIA consider a GB20x vfio-pci variant driver (similar to nvgrace-gpu) that checks the GPU state before FLR and quarantines the device instead of letting the host lock up?
  • Is a clean guest shutdown (guest driver unloads before the VM is destroyed) the recommended mitigation for hypervisors today?

2. The host locking up on the dead device (Linux)

Separately, the 191 soft lockups come from Linux itself: after the failed reset, vfio_pci_core_disable() still calls pci_restore_state(), which walks the extended capability list and rewrites config space on a device that returns ~0, each access stalling for a completion timeout. pci_save_state() and pcie_flr() already bail out via pci_dev_config_accessible(); pci_restore_state() does not (still true in v7.3).

A minimal RFC I intend to offer on linux-pci (written against v7.3 master, not yet tested on hardware):

--- 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);

It does not revive the card (it still needs a cold power cycle), but it turns ~2.7 hours of soft lockups into about 65 seconds and one log line.

Any guidance on the firmware side would be much appreciated.

3

Please do provide a link to the posting on linux-pci after you submit the proposal there. Thanks! :)

4

Posted to linux-pci (Cc kvm) as an RFC:

First review comment already came in (the commit message needs rewording: the stall comes from the config reads in the extended-capability walk, not the writes). A v2 with a corrected description will follow in the same thread.

To be clear, that patch only stops the host from soft-locking on a device that no longer answers after a failed reset. The reset failure itself is the firmware question in this topic.

5

[Fix] Blackwell GPU passthrough: “No devices were found” / “WPR2 already up” after a guest reboot. For headless Linux guests, blacklist nvidia_drm + nvidia_modeset (RTX PRO 4000, FreeBSD bhyve host)

TL;DR: the fix
Symptom: an NVIDIA Blackwell card passed through to a Linux VM works on the first VM boot after the host boots. Any guest reboot or shutdown then hangs. After that, the card is dead inside the VM (nvidia-smi: “No devices were found”; dmesg: unexpected WPR2 already up, cannot proceed with booting GSP) until the whole host is rebooted. FLR and PCIe link resets from the host don’t bring it back.

Cause (in our case): NVIDIA’s display modules (nvidia_modeset, nvidia_drm) hang while unloading in a VM that has no display (stuck in nvRmVTSwitch). So the driver never gets to shut the GPU’s GSP firmware down. Its protected memory region (WPR2) stays up, and the next driver start refuses the card.

Fix (headless / compute guests): never load those two modules:

# /etc/modprobe.d/nvidia-headless.conf
blacklist nvidia_drm
blacklist nvidia_modeset
install nvidia_drm /bin/false
install nvidia_modeset /bin/false

sudo update-initramfs -u

Then reboot the host once, to get a clean card.

After that only nvidia and nvidia_uvm load (all that CUDA needs). Guest reboot, guest poweroff and an ACPI shutdown from the host all work, and the card comes back every time without a host reboot, including when the VM autostarts after a host reboot.

What it does NOT fix: hard-killing the VM while the driver is loaded (vm poweroff -f, virsh destroy, and so on) still leaves WPR2 up, and only a host reboot clears that. Shut the guest down properly.

Setup

  • Host: FreeBSD 15.1-RELEASE, stock bhyve (no patches), vm-bhyve, UEFI guest firmware (BHYVE_UEFI.fd). Intel i7-7700T (Kaby Lake), B250 chipset, VT-d enabled, 64 GB RAM.
  • GPU: NVIDIA RTX PRO 4000 Blackwell SFF Edition, 24 GB (10de:2c33, GB203GL), plus its audio function (10de:22e9), in the CPU’s x16 slot.
  • Guest: Ubuntu Server 24.04.5, kernel 6.8.0-147-generic, 4 vCPU, 32 GB (wired), headless.
  • Guest driver: 615.71.09, open kernel module (nvidia-headless-no-dkms-615-server-open, linux-modules-nvidia-615-server-open-generic, nvidia-utils-615-server), CUDA 13.4.

Passthrough config

Host, /boot/loader.conf:

vmm_load="YES"
pptdevs="1/0/0 1/0/1"

vm-bhyve guest config:

passthru0="1/0/0"
passthru1="1/0/1"
wired_memory="yes"

That gives bhyve -S (wired memory) and -s 0:6:0,passthru,1/0/0 -s 0:6:1,passthru,1/0/1.

Host after a reboot:

$ pciconf -l | grep ppt
ppt0@pci0:1:0:0: class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x2c33 subvendor=0x10de subdevice=0x2053
ppt1@pci0:1:0:1: class=0x040300 rev=0xa1 hdr=0x00 vendor=0x10de device=0x22e9 subvendor=0x10de subdevice=0x0000

Guest:

$ lspci | grep -i nvidia
00:06.0 VGA compatible controller: NVIDIA Corporation Device 2c33 (rev a1)
00:06.1 Audio device: NVIDIA Corporation Device 22e9 (rev a1)

Driver install (Blackwell needs the open driver):

sudo apt update
ubuntu-drivers list --gpgpu
sudo ubuntu-drivers install --gpgpu nvidia:615-server-open
sudo apt install nvidia-utils-615-server   # --gpgpu leaves out nvidia-smi

The first boot with the driver works:

$ nvidia-smi
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 615.71.09              KMD Version: 615.71.09     CUDA UMD Version: 13.4     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|=========================================+========================+======================|
|   0  NVIDIA RTX PRO 4000 Blac...    Off |   00000000:00:06.0 Off |                  Off |
| 30%   36C    P8              9W /   70W |       1MiB /  24467MiB |      0%      Default |
+-----------------------------------------+------------------------+----------------------+

The problem: what we saw

  1. sudo reboot inside the guest: the guest never finishes going down. The bhyve process stays alive, there’s no network, and vm-bhyve logs no exit.
  2. ACPI shutdown from the host (vm stop): the same. Still “Running” after several minutes.
  3. A guest reboot before the NVIDIA driver had ever loaded (right after installing it) worked fine. That was the first hint that the driver was involved.
  4. vm poweroff -f, then vm start right away: bhyve exited with status 4. This one turned out to be a red herring: vm list still showed “Locked” because the old instance was still being torn down. Wait for “Stopped” before starting again.
  5. vm poweroff -f, wait for “Stopped”, vm start: the guest boots, but
$ nvidia-smi
No devices were found

$ sudo dmesg | grep -i -e nvrm -e wpr -e gsp | head -15
NVRM: GPU0 objClInitPcieChipset: *** Unable to get PCI port handles
NVRM: Xid (PCI:0000:00:06): 62, 324f892d 0002e740 00000000 2067ede2 2067f180 2067f0c2 20680598 20680a06
NVRM: GPU0 _kgspProcessRpcEvent: Attempted to process RPC event from GPU0: 0x1022 (RECOVERY_ACTION) during bootup without API lock
NVRM: GPU0 _kgspProcessRpcEvent: Attempted to process RPC event from GPU0: 0x1029 (PMU_HALTED) during bootup without API lock
NVRM: GPU0 kgspSendInitRpcs_IMPL: GMCAPI_CMD_GSP_INIT failed: 0x65
NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Call timed out [NV_ERR_TIMEOUT] (0x00000065) returned from kgspSendInitRpcs(pGpu, pKernelGsp) @ kernel_gsp_gh100.c:1091
NVRM: GPU0 _kgspBootGspRm: unexpected WPR2 already up, cannot proceed with booting GSP
NVRM: GPU0 _kgspBootGspRm: (the GPU is likely in a bad state and may need to be reset)
NVRM: GPU0 RmInitAdapter: Cannot initialize GSP firmware RM
NVRM: GPU 0000:00:06.0: RmInitAdapter failed! (0x62:0x40:2130)
NVRM: GPU 0000:00:06.0: rm_init_adapter failed, device minor number 0
NVRM: GPU 0000:00:06.0 init failed during probe (ret=-5).

Only a full host reboot brought the card back.

(objClInitPcieChipset: *** Unable to get PCI port handles shows on every boot, including the good ones. bhyve puts the GPU straight on the guest’s bus 0, with no PCIe root port above it. It seems harmless.)

Troubleshooting

Does the card support FLR? On the host:

$ pciconf -lc pci0:1:0:0
...
cap 10[60] = PCI-Express 2 legacy endpoint max data 256(256) FLR RO
             max read 512
             link x8(x16) speed 2.5(32.0) ASPM disabled(L1) ClockPM disabled
...

Yes, it does.

FLR from the host, with the VM stopped: devctl reset ppt0 and devctl reset ppt1 (both silent). Then vm start: still “No devices were found”.

A PCIe link reset from the host: devctl reset pci1. That’s the bus under the root port, and FreeBSD’s bridge reset disables the link and retrains it (a hot reset), saving and restoring the devices’ config around it. First we checked that bus 1 holds only the GPU’s two functions:

$ pciconf -l | grep 'pci0:1:'
$ devinfo -p pci1
pci1 pcib1 pci0 pcib0 acpi0 nexus0

Result: no change. The guest dmesg showed unexpected WPR2 already up again.

Research: this matches the known Blackwell “reset bug” reported for the RTX 5090 and RTX PRO 6000 under Linux KVM/VFIO. GSP firmware sets up a protected region (WPR2) that survives FLR, so the next driver start refuses to boot GSP. Links at the end.

The idea: if the guest’s driver unloaded properly, GSP would tear WPR2 down itself. On a fresh card (after a host reboot), inside the guest:

$ lsmod | grep nvidia
nvidia_uvm           2088960  0
nvidia_drm            155648  0
nvidia_modeset       1556480  1 nvidia_drm
nvidia              16875520  2 nvidia_uvm,nvidia_modeset

$ sudo systemctl stop nvidia-persistenced                    # fine
$ sudo rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia      # hangs forever

From a second SSH session:

$ sudo dmesg | grep -i nvrm
NVRM: Xid (PCI:0000:00:06): 56, pid=..., name=(udev-worker), CMDre 00000000 00000000 00000400 00000001 00000000
...
 nvRmApiControl+0x46/0x60 [nvidia_modeset]
 ? nvRmVTSwitch+0x2d/0x40 [nvidia_modeset]

So the unload hangs in nvidia_modeset’s VT switch (handing the console back), in a VM where nothing is attached to the GPU’s outputs. The same thing happens on reboot or shutdown. GSP never shuts down, WPR2 stays up, and the next start fails. (The Xid 56 is a display-engine error, logged as udev-worker loaded the display modules at boot.)

The fix

f=/etc/modprobe.d/nvidia-headless.conf
echo 'blacklist nvidia_drm' | sudo tee $f
echo 'blacklist nvidia_modeset' | sudo tee -a $f
echo 'install nvidia_drm /bin/false' | sudo tee -a $f
echo 'install nvidia_modeset /bin/false' | sudo tee -a $f
sudo update-initramfs -u
sync

Then one host reboot for a clean card. After it:

$ lsmod | grep nvidia
nvidia_uvm           2088960  0
nvidia              16875520  1 nvidia_uvm
Test Before the fix After the fix
sudo poweroff in the guest, then vm start hang card back, about 45 s from poweroff to nvidia-smi
sudo reboot in the guest hang card back, about 40 s
vm stop (ACPI) from the host, then vm start hang card back
host reboot, VM autostarts (vm_list) n/a card back

Notes and caveats

  • Headless/compute only. No display from the passed-through GPU in the guest. If you need the display modules, this isn’t your fix. We didn’t test a guest with a monitor on the GPU, where the VT switch might behave differently.
  • Don’t hard-kill the VM while the driver is loaded. That still leaves WPR2 up.
  • After a guest driver upgrade, check the modprobe file is still there and lsmod shows only nvidia and nvidia_uvm.
  • So far this is tested with nvidia-smi and repeated restarts.
  • KVM/Proxmox users with Linux guests: we haven’t tested on KVM, but if your guest is headless and you hit the Blackwell reset bug, this might be the same mechanism, and it’s cheap to try.
  • For FreeBSD folks: on the same host, a Maxwell GTX 960 couldn’t be initialized in a bhyve guest at all (RmInitAdapter failed), as others report for older NVIDIA cards without the community bhyve patches. This Blackwell card with the open/GSP driver needed no bhyve patches on 15.1.

Bonus: the same card on the FreeBSD host itself

Before passing it through, we ran the card on the FreeBSD host (Vulkan, for whisper.cpp). Two gotchas:

  1. nvidia-driver-580 hung at the first open: nvidia-smi sat in state D, Ctrl-C did nothing, and shutdowns hung after “All buffers synced”. The port’s pkg message says GSP firmware is off by default, and some GPUs don’t work without it. We switched to nvidia-driver 595.104.02 and added hw.nvidia.registry.EnableGpuFirmware="1" to /boot/loader.conf, and nvidia-smi worked. (Both changed together; GSP is the likely one.)
  2. Non-root processes couldn’t use the card (root could). The Vulkan loader said Could not get 'vkCreateInstance' via 'vk_icdGetInstanceProcAddr' for ICD libGLX_nvidia.so.0, and dmesg said firmware_get_flags: insufficient privileges to load firmware image nvidia_gsp_ga10x_fw and RmInitAdapter failed! (0x61:0x56:2726). Without persistence, the driver powers the GPU down when the last client closes and loads the GSP firmware module again on the next open, and only root may load kernel modules. The fix is to keep it loaded: sysrc kld_list+=nvidia_gsp_ga10x_fw.

References

6

Thanks, useful data point: same mechanism (WPR2 left up after an unclean driver exit, card dead after the reset) on GB203 under bhyve, so it is not specific to Linux vfio or KVM.

For this topic it is a workaround, not a fix: it only helps when the guest shuts down cleanly. Here the guest is destroyed by the hypervisor (and in production I do not control the guest image), which is exactly the “hard-kill still leaves WPR2 up” case you mention. The questions to NVIDIA in post #2 stand: a VBIOS/FSP that tolerates WPR2 after FLR, and which versions, if any, cover 10de:2bb4.