Dear Maintainer, I configured AMD RX-7900XTX GPU passthrough to a KVM virtual machine running Windows 10 on Debian 13.1.0. After shutting down the Windows 10 VM, the Linux host kernel reports errors related to vfio_pci and AMD GPU passthrough. This causes virt-manager to freeze and become unresponsive; virsh commands also hang. The GPU fails to reset, and rebooting the host system often hangs, requiring a forced reboot via hardware reset or power off. Previously, on Debian 12.12.0 with the same hardware and GPU passthrough setup, no such issues occurred; the GPU reset properly every time. I expected the VM shutdown to complete cleanly without freezing host control tools or causing kernel crashes, and for the GPU to reset so it could be reused without reboot. I have also tested kernels from Debian testing (linux-image-6.16.3+deb14-amd6) and unstable (linux-image-6.16.5+deb14-amd64) branches, but the same errors occur.
Hello, Can you please provide a full bootlog? Also can you please provide the output of: ls -l /sys/devices/pci0000:00/0000:03:00.0/driver when run a) before kvm starts, b) while kvm is running and c) after the problem triggered? I suspect that somehow there are two different threads that access the hardware: Both vfio_pci and the amdgpu driver. I guess before you start kvm, the amdgpu driver is loaded already. Does it help to blacklist it (i.e. pass module_blacklist=amdgpu on the kernel commandline and verify using lsmod | grep amdgpu that the module isn't loaded before kvm is started.) Not knowing how pci passthrough works exactly, I'd expect that the host driver is unbound when kvm is started with a passed through pci device. So if the above helps the likely problem is that the amdgpu fails to completely free all resources. Does it produce any kernel or shell output if you do: echo 0000:03:00.0 > /sys/bus/pci/drivers/amdgpu/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers/amdgpu/bind instead of/before starting kvm? Best regards Uwe
I experienced this same bug, and in my troubleshooting worked around it with the following steps: 1. Added vfio_pci.ids=[pair of Radeon 6800 ids here] to my cmdline 2. Added softdep drm pre: vfio-pci to new file /etc/modprobe.d/vfio.conf 3. Regenerate initramfs Making vfio-pci load before amdgpu at boot, so that it can effectively get bound to the GPU instead of amdgpu as specified by the cmdline argument Since the bug occurs when the host attempts to reclaim the GPU from a VM with the amdgpu driver, adjusting it so that the host never loads amdgpu on it and always has the card on vfio-pci prevents all hanging and errors. Allowing for it to be freely booted with another VMs after the VM using it shuts down This works as a solution on my setup where the host uses the CPU's iGPU for its display output, and uses the discrete GPU exclusively for passthrough to VMs. But this wouldn't work on a system where there's only one GPU and single GPU passthrough is being done
Hi Uwe, Thank you your response and advices. Please find below a summary(by AI) of the system logs and additional observations related to the AMDGPU driver issue on Debian 13 (Stable 13.1) running Linux kernel 6.12.43+deb13-amd64. Logs without blacklisting: * The system was booted with the AMDGPU driver loaded normally. * Kernel messages show AMDGPU initialization along with errors such as "failed to clear page tables on GEM object close" and "leaking bo va." * A kernel oops involving null pointer dereference was observed related to runtime PM suspend in vfio_pci_core module. Logs with AMDGPU driver blacklisted: * The system was booted with the amdgpu module blacklisted via grub (module_blacklist=amdgpu). * No AMDGPU initialization logs appear, and no related kernel crashes occur. * The rest of the boot process and device initialization proceed normally. Summary: * Errors correlate directly with the AMDGPU driver being loaded. * Blacklisting the AMDGPU module prevents these errors, indicating the problem lies within the driver. * The issue appears linked to resource handling and runtime PM interaction with VFIO PCI. * Further investigation into the AMDGPU and vfio_pci_core driver interaction is needed. Unreproducible issue: * I remember that before submitting this bug report, I tested blacklisting amdgpu on Debian 13 for GPU passthrough. Initially, blacklisting successfully blocked the GPU audio PCI device only, while the graphics PCI device still used the amdgpu driver instead of vfio-pci. However, in the current tests, blacklisting works on both PCI devices. I have tried all known blacklisting approaches to reproduce the original error but have been unsuccessful. On Debian 12 (12.11, 12.12), it is not necessary to blacklist amdgpu because the driver resets automatically when the KVM virtual machine shuts down. In Debian 13.1, blacklisting amdgpu prior to GPU passthrough seems to be a temporary workaround. While not ideal, it effectively "solves" the problem for now. Please let me know if any additional information or further testing is required. Best regards, Naunte
On Tue, 23 Sep 2025 00:55:40 +0000 Christopher W <sun-chris@outlook.com> wrote: > I experienced this same bug, and in my troubleshooting worked around it with the following steps: > > 1. Added > vfio_pci.ids=[pair of Radeon 6800 ids here] > to my cmdline > 2. Added > softdep drm pre: vfio-pci > to new file /etc/modprobe.d/vfio.conf > 3. Regenerate initramfs > > Making vfio-pci load before amdgpu at boot, so that it can effectively get bound to the GPU instead of amdgpu as specified by the cmdline argument > > Since the bug occurs when the host attempts to reclaim the GPU from a VM with the amdgpu driver, adjusting it so that the host never loads amdgpu on it and always has the card on vfio-pci prevents all hanging and errors. Allowing for it to be freely booted with another VMs after the VM using it shuts down > > This works as a solution on my setup where the host uses the CPU's iGPU for its display output, and uses the discrete GPU exclusively for passthrough to VMs. But this wouldn't work on a system where there's only one GPU and single GPU passthrough is being done Here is the translated and grammar-optimized English version: *** Hi Christopher, Thank you for your reply and suggestions. However, the parameters `vfio_pci.ids=` and `softdep drm pre: vfio-pci` are not available on Debian 13. Instead, it is necessary to use `options vfio-pci ids=` and either `softdep drm pre: vfio-pci` or `softdep amdgpu pre: vfio-pci`. This is indeed a temporary workable solution. Since I need to switch the GPU between different VMs, although it is possible to automate the switching via scripts, it would be best if native support and switching were available without the reset bug. Regards, Naunte
Hello, I think what happens when you start kvm (or whatever virtual machine manager you're using) is that the amdgpu driver is unbound and after Windows shut down the driver is bound again to the hardware. I guess unbinding fails to release all resources. Can you try without the virtual windows to just do: echo 0000:03:00.0 > /sys/bus/pci/drivers/amdgpu/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers/amdgpu/bind Does this result in error messages, or a working driver? Best regards Uwe