Hoping someone with a professional Blackwell card has cracked this. My failure looks related to the RTX 5080/#7374 threads but is a DIFFERENT stage — my device assigns fine and reaches the guest; it's the FLR reset that never completes.
Host / software
Goal
Pass the GPU to a headless Ubuntu VM (VM 100) for compute only — no display needed.
Outcome
The recipe worked partially — one real, permanent gain, but our core wall stan
- Good - x-no-geforce-quirks=on fixed the QEMU crash. The pci_irq_handler segfaultirst session is gone — this is the professional-Blackwell GeForce-quirkNULL-deref that sunwalkers identified, and the patch genuinely resolves it.
- Good - pci=realloc applied cleanly (helped BAR allocation generally; didn't touc
- Bad - The FLR reset still times out (not ready 65535ms after FLR; giving up). Tr and bus reset methods and both fail, and it presents unreadable (7f) configspace. That's a firmware-level Blackwell reset failure — no Proxmox/QEMU/kernel setting can hand a guest a card that won't reset.
So sunwalkers' card cleared their blocker (the iommufd "No such device" bind, dn't have our blocker. We've now exhausted the documented software paths.
Current state
- Balto: running, hermes-gateway active and stable, Discord-only, no GPU attached — clean and fast-booting. - Staged for a future fix (so re-attaching is trivial): vfio binding, pci=realquirks PCI.pm patch all remain in place. When a real reset fix lands, it'sjust:
qm set 100 --hostpci0 0000:01:00,pcie=1 # + host reboot + one cold start
- All changes backed up (grub.bak-*, PCI.pm.bak-geforcequirk-*). Note the PCI.pm patch reverts on the next qemu-server package update — that's fine, it's documented.
The one thing to watch
Proxmox bugzilla #7374 (REOPENED). Check it after each PVE kernel bump — that'fix will surface. I saved the full findings to memory so we don't re-run thisinvestigation from zero.
Net: the GPU can't be passed through today, but you've lost nothing — Balto runs exactly as before, and we're one command away from success the moment upstream fixes the reset. Want me to leave the vfio binding claiming the card (ready to go), or hand it back to the host in the meantime?
✻ Sautéed for 10m 37s
❯ Could you create a copy/paste-able Proxmox Forum submission that detials our exact trouble? Then I will post that to their forum to see what they might be able to help with.
Good idea — a precise, well-scoped post will get much better help. Let me pullre identifiers so the post is credible and complete:
Ran 1 shell command
Here's a ready-to-post submission. I've written it to match the Proxmox forum's format (XenForo
Current cmdline:
VM config (q35 + SeaBIOS; guest is a BIOS-mode Ubuntu install, so OVMF is not an option without a reinstall):
The failure — FLR never completes
On VM start, vfio-pci tries to reset the card and it never comes back:
After the failed reset the card's config space is unreadable on the HOST — lspci shows a bogus header:
And the guest consequently ignores the dead device:
The card only advertises two reset methods and BOTH fail:
What I've already tried (no effect on the FLR reset)
How this differs from bug #7374 / the RTX 5080 threads
Those threads fail earlier, at device assignment ("error getting device from group N: No such device", iommufd ENODEV). I do NOT hit that — my device is assigned successfully and shows up in the guest. My only blocker is the FLR reset timeout above. So the iommufd/CDEV workarounds and szoran's 1:1-mapping kernel patch don't apply here.
Questions
Happy to provide full dmesg, lspci -vvv, or qm showcmd output. Thanks!
Host / software
- Minisforum MS-02 (board MS-02-Ultra), BIOS 1.03 (2025-10-22)
- Intel Core Ultra 9 285HX (Arrow Lake-HX)
- Proxmox VE 9.1.1, kernel 6.17.13-18-pve
- GPU: NVIDIA RTX Pro 2000 (Blackwell) — 01:00.0 VGA [10de:2d30], 01:00.1 Audio [10de:22eb], subsystem [10de:2054]
Goal
Pass the GPU to a headless Ubuntu VM (VM 100) for compute only — no display needed.
Outcome
The recipe worked partially — one real, permanent gain, but our core wall stan
- Good - x-no-geforce-quirks=on fixed the QEMU crash. The pci_irq_handler segfaultirst session is gone — this is the professional-Blackwell GeForce-quirkNULL-deref that sunwalkers identified, and the patch genuinely resolves it.
- Good - pci=realloc applied cleanly (helped BAR allocation generally; didn't touc
- Bad - The FLR reset still times out (not ready 65535ms after FLR; giving up). Tr and bus reset methods and both fail, and it presents unreadable (7f) configspace. That's a firmware-level Blackwell reset failure — no Proxmox/QEMU/kernel setting can hand a guest a card that won't reset.
So sunwalkers' card cleared their blocker (the iommufd "No such device" bind, dn't have our blocker. We've now exhausted the documented software paths.
Current state
- Balto: running, hermes-gateway active and stable, Discord-only, no GPU attached — clean and fast-booting. - Staged for a future fix (so re-attaching is trivial): vfio binding, pci=realquirks PCI.pm patch all remain in place. When a real reset fix lands, it'sjust:
qm set 100 --hostpci0 0000:01:00,pcie=1 # + host reboot + one cold start
- All changes backed up (grub.bak-*, PCI.pm.bak-geforcequirk-*). Note the PCI.pm patch reverts on the next qemu-server package update — that's fine, it's documented.
The one thing to watch
Proxmox bugzilla #7374 (REOPENED). Check it after each PVE kernel bump — that'fix will surface. I saved the full findings to memory so we don't re-run thisinvestigation from zero.
Net: the GPU can't be passed through today, but you've lost nothing — Balto runs exactly as before, and we're one command away from success the moment upstream fixes the reset. Want me to leave the vfio binding claiming the card (ready to go), or hand it back to the host in the meantime?
✻ Sautéed for 10m 37s
❯ Could you create a copy/paste-able Proxmox Forum submission that detials our exact trouble? Then I will post that to their forum to see what they might be able to help with.
Good idea — a precise, well-scoped post will get much better help. Let me pullre identifiers so the post is credible and complete:
Ran 1 shell command
Here's a ready-to-post submission. I've written it to match the Proxmox forum's format (XenForo
Code:
blocks) and framed it to attract the right help — making clear our failure is
the FLR reset, distinct from the more common iommufd bug in bug #7374. I've alyou.
Made 1 scratchpad edit +87
Here's the post — copy from the block below. It uses the Proxmox forum's [CODEll render cleanly there.
---
Title:
RTX Pro 2000 (Blackwell GB20x) passthrough — device fails FLR ("not ready 65535ms after FLR; giving up"), guest sees "unknown header type 7f". Reset bug, not the iommufd #7374 issue
Body:
Hoping someone with a professional Blackwell card has cracked this. My failure looks related to the RTX 5080/#7374 threads but is a DIFFERENT stage — my device assigns fine and reaches the guest; it's the FLR reset that never completes.
[B]Host / software[/B]
[LIST]
[*]Minisforum MS-02 (board MS-02-Ultra), BIOS 1.03 (2025-10-22)
[*]Intel Core Ultra 9 285HX (Arrow Lake-HX)
[*]Proxmox VE 9.1.1, kernel 6.17.13-18-pve
[*]GPU: NVIDIA RTX Pro 2000 (Blackwell) — 01:00.0 VGA [10de:2d30], 01:00.1 Aud[10de:2054]
[/LIST]
[B]Goal[/B]
Pass the GPU to a headless Ubuntu VM (VM 100) for compute only — no display needed.
[B]Prerequisites are all correct[/B]
[LIST]
[*]Intel VT-d enabled (kernel default; also tried explicit intel_iommu=on, with and without iommu=pt)
[*]GPU is alone in its own IOMMU group (nothing else to bind):
[/LIST]
[CODE]# ls /sys/kernel/iommu_groups/11/devices/
0000:01:00.0 0000:01:00.1- Both functions bound to vfio-pci at boot (host never touches the card):
Code:
01:00.0 ... Kernel driver in use: vfio-pci
01:00.1 ... Kernel driver in use: vfio-pciCurrent cmdline:
Code:
... quiet intel_iommu=on pci=reallocVM config (q35 + SeaBIOS; guest is a BIOS-mode Ubuntu install, so OVMF is not an option without a reinstall):
Code:
machine: q35
bios: seabios
hostpci0: 0000:01:00,pcie=1The failure — FLR never completes
On VM start, vfio-pci tries to reset the card and it never comes back:
Code:
vfio-pci 0000:01:00.0: timed out waiting for pending transaction; performing function level reset anyway
vfio-pci 0000:01:00.0: not ready 1023ms after FLR; waiting
vfio-pci 0000:01:00.0: not ready 2047ms after FLR; waiting
vfio-pci 0000:01:00.0: not ready 4095ms after FLR; waiting
vfio-pci 0000:01:00.0: not ready 8191ms after FLR; waiting
vfio-pci 0000:01:00.0: not ready 16383ms after FLR; waiting
vfio-pci 0000:01:00.0: not ready 32767ms after FLR; waiting
vfio-pci 0000:01:00.0: not ready 65535ms after FLR; giving up
vfio-pci 0000:01:00.0: reset doneAfter the failed reset the card's config space is unreadable on the HOST — lspci shows a bogus header:
Code:
# lspci -vv -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2d30 (rev a1)
!!! Unknown header type 7f
Region 0: Memory at 70000000 (32-bit, non-prefetchable) [size=64M]
Region 1: Memory at b000000000 (64-bit, prefetchable) [size=16G]
Region 3: Memory at ae10000000 (64-bit, prefetchable) [size=32M]And the guest consequently ignores the dead device:
Code:
pci 0000:01:00.0: [10de:2d30] type 7f class 0xffffff conventional PCI
pci 0000:01:00.0: unknown header type 7f, ignoring deviceThe card only advertises two reset methods and BOTH fail:
Code:
# cat /sys/bus/pci/devices/0000:01:00.0/reset_method
flr busWhat I've already tried (no effect on the FLR reset)
- Kernel 6.17.13-18-pve (also fails on earlier 6.17.x)
- pci=realloc — the physical BARs assign fine; only the unused SR-IOV VF BARs fail ("VF BAR 2 ... can't assign; no space"), which shouldn't matter for full-card passthrough
- x-no-geforce-quirks=on (patched into PCI.pm) — this DID fix a separate QEMU crash (segfault / pci_irq_handler assertion when the GeForce BAR0 quirk hit this pro card), but it does NOT fix the reset
- bus reset method — also fails
- disable_idle_d3=1 on vfio-pci
- With and without iommu=pt
How this differs from bug #7374 / the RTX 5080 threads
Those threads fail earlier, at device assignment ("error getting device from group N: No such device", iommufd ENODEV). I do NOT hit that — my device is assigned successfully and shows up in the guest. My only blocker is the FLR reset timeout above. So the iommufd/CDEV workarounds and szoran's 1:1-mapping kernel patch don't apply here.
Questions
- Has anyone gotten a professional Blackwell card (RTX Pro 2000/4000/5000, GB20x) past the "not ready after FLR; giving up" reset?
- Is there a device-specific reset quirk, a vendor-reset-style module, or a kernel patch for Blackwell reset specifically?
- Would supplying the GPU VBIOS via romfile= help if the card isn't being POSTed by the host firmware (it's a secondary, non-display GPU in a headless server)?
- Any BIOS-level lever on Intel Arrow Lake / this board (Resizable BAR / Above-4G is already on; there is no "Kernel DMA Protection" toggle) that affects device reset?
Happy to provide full dmesg, lspci -vvv, or qm showcmd output. Thanks!