Fixing Proxmox GPU Passthrough That Breaks After a Kernel Update (September 2026)

I learned this the hard way. After a routine apt dist-upgrade rebooted my home lab into kernel 6.14, my gaming VM refused to start, my host froze solid twice, and my ZFS pool suspended itself when I tried to reset the GPU. If your Proxmox GPU passthrough kernel update fix is what you are looking for right now, this guide walks through exactly what broke, how to diagnose it, and how to make sure it never happens again.

GPU passthrough depends on a stack of moving parts: the kernel, the vfio-pci driver, IOMMU groups, and the NVIDIA or AMD userland driver. Any kernel bump can change one of those layers. Most issues fall into three buckets: kernel parameter changes (IOMMU or pcie_acs_override behavior), module compilation issues (DKMS not rebuilding), and driver mismatches (NVIDIA module loaded but incompatible). I will cover all three, plus prevention so your next upgrade is boring.

Understanding Why GPU Passthrough Breaks After a Kernel Update

GPU passthrough breaks after kernel updates because the NVIDIA driver is compiled against a specific kernel version. When the kernel updates, the driver module is no longer compatible, and in some cases kernel parameter handling or IOMMU behavior changes.

The vfio-pci module is the bridge that hands a PCIe device over to a VM. Its behavior can shift between kernel releases, especially around ACS (Access Control Services) and reset handling. Kernel 6.14 in particular has known PCI passthrough regressions that show up on AMD Ryzen platforms.

There are three common ways passthrough dies after an update:

• The kernel boots fine, but the NVIDIA module fails to load with Exec format error or disagrees about version of symbol module_layout. This is a DKMS problem.

• The kernel boots and the VM starts, but the host freezes a few seconds later. This is an IOMMU grouping problem exposed by a kernel-side change.

• The VM starts, the GPU resets, and the SATA or NVMe controller behind the same IOMMU group takes down the root pool. This is the dreaded ZFS suspension scenario.

If you see any of these symptoms, work through the steps below in order. I will start with the cheapest checks and move into the heavier fixes.

How to Check Your IOMMU Groups in Proxmox?

IOMMU groups define which devices can be isolated together. For passthrough to work, your GPU needs to live alone in its own group. If the GPU shares a group with the SATA controller, passing through the GPU will also pass through your disks, and a reset will hang the host.

Run this command as root to list every IOMMU group on the host:

find /sys/kernel/iommu_groups/ -type l | sort -V

For a more readable output grouped by IOMMU ID:

for d in /sys/kernel/iommu_groups/*/devices/*; do
  n=${d#*/iommu_groups/*}; n=${n%%/*}
  printf 'IOMMU group %s: ' "$n"
  lspci -nns "${d##*/}" | awk -F': ' '{print $2}'
done | sort -V

Look for your GPU by its vendor ID. NVIDIA cards show 10de: and AMD cards show 1002:. The output line that contains your GPU should list only the GPU itself. If it also contains a SATA, NVMe, or USB controller, you have an unfriendly IOMMU group. This is most often seen on B550 and X570 motherboards where the chipset does not implement ACS properly.

Kernel Parameters for GPU Passthrough

Kernel parameters tell the kernel to enable IOMMU at boot and to isolate PCIe devices for passthrough. Without these, vfio-pci has nothing to bind to.

Open /etc/default/grub and find the GRUB_CMDLINE_LINUX_DEFAULT line. Replace it with the parameters that match your CPU vendor.

For Intel CPUs:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt video=efifb:off"

For AMD CPUs:

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt video=efifb:off"

What each flag does:

• intel_iommu=on or amd_iommu=on turns on IOMMU in the kernel.

• iommu=pt enables pass-through mode for devices the host does not need (faster than full translation).

• video=efifb:off stops the kernel from claiming the EFI framebuffer so the GPU can be unbound cleanly.

After saving, update GRUB and reboot:

update-grub
reboot

Confirm the parameters took effect:

dmesg | grep -i -e DMAR -e IOMMU

If you see DMAR: IOMMU enabled or AMD-Vi: IOMMU performance counters supported, the kernel is ready for passthrough.

The pcie_acs_override Solution for Stuck IOMMU Groups

When the host freezes during GPU passthrough, the most common cause is that your motherboard’s IOMMU groups are not split cleanly. Some PCIe bridges do not advertise ACS, so the kernel groups more devices together than the hardware actually requires. The pcie_acs_override parameter forces the kernel to act as if every bridge supports ACS.

Add this to your GRUB_CMDLINE_LINUX_DEFAULT line:

pcie_acs_override=downstream,multifunction

A complete Intel line with the override looks like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction video=efifb:off"

Rebuild GRUB and reboot, then re-run the IOMMU group listing. You should see your GPU now isolated into its own group, with the SATA and NVMe controllers in separate groups. I used this exact parameter on my B550 board and the host freeze disappeared on the next VM start.

Warning: this is a workaround, not a hardware fix. Some older PCIe devices rely on the lack of ACS for legacy behavior, and forcing it can occasionally cause odd resets on capture cards or USB controllers. If your setup works without it, leave it off.

VM Configuration for Passthrough (q35, OVMF, hostpci0)

The VM side of passthrough needs three matching pieces: the q35 machine type, OVMF firmware, and a hostpci0 line that points to the GPU. Get any of these wrong and the VM will refuse to start, even when the host is configured perfectly.

In the Proxmox web UI, edit the VM and under System set:

• Machine: q35

• BIOS: OVMF (UEFI)

• EFI Storage: your storage, with a disk image selected

• CPU: host (passes through the CPU flags the guest needs)

Then under Hardware, click Add and choose PCI Device. Pick the GPU, select All Functions, check Primary GPU, and set PCI-Express to yes. Proxmox writes this into the VM config as something like:

hostpci0: 0000:01:00.0,pcie=1,x-vga=1

One more thing that catches people: if you are running a ZFS root, set the VM’s BIOS to OVMF (UEFI) and pre-enroll the EFI disk. Otherwise the VM will boot to a black screen with no way to install an OS.

Reinstalling NVIDIA Drivers After a Kernel Update

NVIDIA drivers are not part of the kernel. They ship as out-of-tree modules that get rebuilt against the running kernel via DKMS. When a kernel update skips the DKMS rebuild (often because headers were missing), the old module will fail to load on the next boot.

The cleanest way to fix it is to purge the existing NVIDIA packages and reinstall:

apt purge nvidia-*
apt install nvidia-driver
reboot

The installer will warn you if the nouveau driver is loaded. Reboot after purging, run the install, reboot again. After the second reboot, verify:

nvidia-smi

If nvidia-smi returns driver and GPU info, the host-side NVIDIA stack is healthy.

For long-term stability, install dkms and the matching kernel headers so future kernel updates trigger an automatic module rebuild:

apt install dkms pve-headers-$(uname -r)

AMD GPUs do not need this step. The amdgpu driver lives inside the kernel, so a kernel update brings the new driver with it. You only need to handle NVIDIA and a few niche vendors like Intel Arc (which uses DKMS).

Recovering a Suspended ZFS Pool After a Passthrough Crash

When a GPU resets and shares an IOMMU group with the SATA or NVMe controller, ZFS will mark the pool as suspended to protect data. After you fix the IOMMU grouping (with pcie_acs_override or by moving the card to a different slot), you still need to bring the pool back online.

Check pool status first:

zpool status

If you see a state of SUSPENDED, import the pool explicitly:

zpool import -f rpool
zpool mount -a

The -f flag forces the import because ZFS remembers the suspended state from the crash. Once mounted, verify the dataset shows up under zfs list and the services that depend on it (PVE storage, LXC, etc.) come back. In my case, this was the final step after I fixed the IOMMU groups and the host stopped freezing.

Rolling Back to a Previous Kernel as a Temporary Fix

If a new kernel is just plain broken for passthrough on your hardware, you can boot into the previous kernel and pin it until the upstream issue is fixed. Proxmox exposes this through proxmox-boot-tool:

proxmox-boot-tool kernel list

Pick the previous working kernel, then pin the current one to prevent it from being the default:

apt-mark hold pve-kernel-6.14.x
proxmox-boot-tool refresh

Reboot and select the working kernel from the GRUB menu (or set it as default). This is a temporary measure. Watch the Proxmox forum threads for the kernel version you skipped and unhold it once a fix lands.

Preventing GPU Passthrough from Breaking on Future Kernel Updates

Prevention is where most guides fall short. After you have your passthrough working again, do these four things and you will rarely see this issue reappear.

1. Install pve-headers before any kernel upgrade so DKMS has what it needs.

2. Keep DKMS enabled for every out-of-tree module you use (NVIDIA, Intel Arc, vhost).

3. Test kernel upgrades on a non-critical VM or a test host first.

4. Subscribe to the Proxmox mailing list or subreddit and check for kernel-related bug reports on the day you plan to upgrade.

If you run a production gaming VM, pin the kernel with apt-mark hold after each successful upgrade. It removes the surprise factor entirely.

Verifying the Fix Works

After applying any of the steps above, verify the whole chain works end-to-end. Start the VM and watch the host for five minutes; a stable host will not freeze or log PCIe bus errors.

Useful verification commands:

dmesg | grep -i -e iommu -e vfio -e pci
lspci -nnv -s 01:00.0
journalctl -u pvedaemon -e

Inside the VM, run nvidia-smi (NVIDIA) or glxinfo | grep renderer on Linux to confirm the GPU is bound. For Windows guests, open Device Manager and confirm the GPU shows under Display Adapters with no Code 43.

If everything is clean, you have your Proxmox GPU passthrough kernel update fix. Save the working kernel version and the exact /etc/default/grub line somewhere safe. You will thank yourself next time you run apt upgrade.

Frequently Asked Questions

Final Thoughts

GPU passthrough in Proxmox is powerful, but it is fragile across kernel upgrades because three different subsystems have to agree. The shortest path back to a working VM is usually IOMMU grouping first, then NVIDIA drivers, then ZFS recovery. Lock the kernel in place after you get it working, and your next Proxmox GPU passthrough kernel update fix is a 10-minute job, not an all-night one.