RTX 4090 on a Minisforum DEG2: USB4 Passthrough on Proxmox
My Beelink SER9 kept hanging with a DEG2 eGPU. After VFIO and power fixes, disabling NVIDIA GSP got CUDA working in Ubuntu.
I wanted to reuse my RTX 4090 for inference, so I connected a Minisforum DEG2 to my Beelink SER9 over USB4 and passed the GPU through to Ubuntu.
The GPU showed up, but Proxmox stopped responding when I tried to use it. Several attempts ended with me hard-restarting the box.
1. Getting the VM to boot
My setup: SER9 with a Ryzen AI 9 HX 370, RTX 4090 24 GB, Proxmox 8.4.14, and Ubuntu 24.04 with 8 vCPUs and 8 GB RAM.
The GPU initially disappeared during host boot. Disabling the Thunderbolt driver's host reset kept it visible. Early VFIO binding stopped the host from claiming it, but the next start exposed devices stuck in D3, a low-power state.
Host settings that got me past those failures
In /etc/modprobe.d/thunderbolt-egpu.conf:
options thunderbolt host_reset=0
In /etc/modprobe.d/vfio-egpu.conf:
options vfio-pci ids=10de:2684,10de:22ba disable_idle_d3=1
softdep nouveau pre: vfio-pci
softdep snd_hda_intel pre: vfio-pci
I added vfio, vfio_iommu_type1 and vfio_pci to the initramfs module list. Udev rules kept the GPU, audio and upstream bridges awake with power/control=on and d3cold_allowed=0. Those rules depend on your PCI addresses.
I rebuilt the host initramfs before rebooting. BIOS settings and USB4 security stayed unchanged.
2. Driver initialization hung the host
Installing NVIDIA in Ubuntu brought the problem back. Proxmox sometimes showed the VM as running while Ubuntu was stuck. That status cost me time: QEMU running didn't mean the guest had booted.
Live logs caught:
DPC: containment event
UnsupReq
ACSViol
AER: device recovery failed
Updating the host kernel from 6.8.12-17-pve to 6.8.12-43-pve didn't help. Ubuntu booted fine without the GPU. Some failed attempts left the PCIe path inaccessible until a restart.
I still couldn't tell whether the cable or BIOS was involved. The agent had been too confident about USB4 reset: that fix only addressed the GPU disappearing during boot.
3. Disabling GSP in the guest
Credit to morgwai666 for this NVIDIA forum report. Their AMD Strix laptop, DEG2 and RTX 3090 rebooted during NVIDIA initialization. They reported better stability using the proprietary driver with GSP disabled.
GSP is NVIDIA's GPU System Processor, used for initialization and management. NVIDIA documents the disabling option here.
Inside Ubuntu, I checked the module:
modinfo -F license nvidia
# NVIDIA
My driver was the proprietary 595.99.02 module. The reported workaround didn't work with the open module.
I added /etc/modprobe.d/98-egpu-gsp-test.conf:
options nvidia NVreg_EnableGpuFirmware=0
Then rebuilt the guest initramfs:
sudo update-initramfs -u
After recovering from the previous failed state, I loaded NVIDIA manually with logs running. nvidia-smi showed the 4090, GSP Firmware Version read N/A, and Proxmox stayed reachable.
Persistent settings for my compute-only guest
I kept these in /etc/modprobe.d/99-egpu-diagnostic.conf:
blacklist nouveau
blacklist nvidia_drm
blacklist nvidia_modeset
install nouveau /bin/false
install nvidia_drm /bin/false
install nvidia_modeset /bin/false
options nvidia_drm modeset=0 fbdev=0
In /etc/modules-load.d/nvidia-compute.conf:
nvidia
nvidia_uvm
The GSP setting stays in its own file. I rebuilt the guest initramfs after these edits. This setup keeps NVIDIA display modules blocked because I only need compute.
Check after boot:
cat /proc/driver/nvidia/params | grep EnableGpuFirmware
nvidia-smi -q
4. CUDA and restart checks
A 2-minute CUDA test completed 1,374,000 kernel launches, with 1,374 full readback checks. Every output matched. I shut down the VM, started it again, and confirmed NVIDIA loaded automatically with GSP disabled. CUDA passed again.
No new PCIe errors appeared in that validation capture. Earlier receiver errors still need attention, and this was a light correctness test. I haven't measured inference performance or long-term stability. VM autostart stays off for now.
The dock firmware is unchanged. GSP doesn't explain every earlier failure, but disabling it let me use CUDA and start the VM again successfully.
If your DEG2 hangs on AMD USB4 with Linux, morgwai666's report is worth checking. I wish I'd found it before all those restarts.
Continue in Homelab