[SOLVED] Proxmox 9.0 + AMD Radeon iGPU (Granite Ridge) Passthrough: A Desperate Plea for Help

I have a lingering issue, perhaps someone is able to help me. My windows vm works in every way but I am unable to set display:none and primary select the Radeon Graphics card and have it succeed to display video. It works flawlessly however without no video. After normal shutdown if I add back in the vfio display back in and boot I am able to enable video card again in device manager.
 
Device not visible after shutdown/start? Or code 43? Or screen distortion?

*If there's no output and it's not visible, check via RDP.

I'd appreciate it if you could provide the dmesg output from before and after the shutdown/start.

Have you made the following settings?

https://github.com/isc30/ryzen-gpu-passthrough-proxmox/issues/131#issue-3266798285

Configure the following settings in the Windows Local Group Policy Editor.
*You can use either “pnputil”, "RadeonResetBugFix", or “devcon”.
*devcon has been replaced by pnputil, but if devcon is working correctly, there is no need to change it.

  1. Press [Windows] + [R]
  2. In the [Run] window, type "gpedit.msc" and click OK.
  3. In the [Local Group Policy Editor] window, expand the following:
     [Computer Configration] - [Windows Setting] - [Script (Startup/Shutdown)]
  4. Double-click [Startup], then click [Add].
  5. In the [Add a Script] window, set the following in [Script Name], then click [OK].
Windows 11 Guest Startup Script (RadeonResetBugFix Alternative)

Code:
pnputil /enable-device /class Display /bus PCI /connected
pnputil /enable-device /class MEDIA /connected
  1. Double-click [Sutdown], then click [Add].
  2. In the [Add a Script] window, set the following in [Script Name], then click [OK].
Windows 11 Guest Shutdown Script (RadeonResetBugFix Alternative)

Code:
pnputil /disable-device /class Display /bus PCI /connected
pnputil /disable-device /class MEDIA /connected
 
Last edited:
  • Like
Reactions: futiless
If you have time, try removing `initcall_blacklist=` and switching to `hookscript`.

I don't use blacklist myself, so I hesitate to try that configuration.
 
I started by setting up everything exactly as seen on : https://github.com/isc30/ryzen-gpu-passthrough-proxmox/issues/131#issue-3266798285

Next I added the pnputil /enable-device /class MEDIA /connected to the startup script as a batch file (*also the shutdown in the same way)


1761173878956.png1761173985212.png

I would seem that this report is somewhat preliminary but the honestly I think it is FINALLY working. Here is what I have been using;

Code:
agent: 1
args: -cpu 'host,hv_passthrough,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,-hypervisor,+svm,+invtsc'
balloon: 0
bios: ovmf
boot: order=scsi0
cores: 16
efidisk0: local-zfs:vm-400-disk-0,efitype=4m,size=1M
hostpci0: 0000:01:00.0,pcie=1,romfile=vbios_164E_graniteridge_9955hx.bin,x-vga=1
hostpci1: 0000:01:00.1,pcie=1,romfile=AMDGopDriver_164E_graniteridge_9955hx.rom
hostpci2: 0000:07:00.0,pcie=1
ide0: local:iso/virtio-win-0.1.285.iso,media=cdrom,size=771138K
machine: pc-q35-10.0+pve1,viommu=virtio
memory: 32768
meta: creation-qemu=10.0.2,ctime=1760472552
name: Win11Corp25h2Sept25
net0: virtio=BC:24:11:49:73:09,bridge=vmbr0,firewall=1,queues=12
numa: 1
ostype: win11
scsi0: local-zfs:vm-400-disk-1,aio=io_uring,cache=writeback,discard=on,size=256G,ssd=1
scsihw: virtio-scsi-pci
smbios1: uuid=9dc21911-5921-4b36-a01e-cbbcf45acfbe
sockets: 1
spice_enhancements: foldersharing=1,videostreaming=all
tags: win11
tpmstate0: local-zfs:vm-400-disk-2,size=4M,version=v2.0
unused0: local-zfs:vm-400-disk-3
usb0: host=30fa:1040
usb1: host=13d3:3604,usb3=1
usb3: host=3-2.4.4
vcpus: 12
vga: none
vmgenid: f7ae3dfb-abd8-4eb0-905d-d1e2c5026432

The big deal after your pnputil script fix was I absolutely needed;

machine: pc-q35-10.0+pve1,viommu=virtio

In all honesty I wasn't sure its full purpose as I understood iommu but not viommu. For me unless I come back here and edit it later was the only way out of catastrophic failure eventually at random intervals.

The only little snag left is that Windows Device Manager keeps disabling a couple of my audio devices on every boot. Once I re-enable those, it's all smooth sailing. It's honestly getting so close to perfect that I might actually get to use my free time for, you know, fun stuff instead of constant tinkering.

Thank you ; Uzumo, I couldn't do it without your guidance. :)
 
Last edited:
  • Like
Reactions: uzumo
The only little snag left is that Windows Device Manager keeps disabling a couple of my audio devices on every boot.

It's possible that the MEDIA command in the enable script for startup is not executing.

try deleting the following.
*This line isn't strictly necessary, but I added it since someone mentioned needing it.
*This toggles audio on/off.

Code:
pnputil /enable-device /class MEDIA /connected
pnputil /disable-device /class MEDIA /connected
 
Last edited:
Ah, spoke too soon... eventually it started having video failure to the point the entire video card was in a crash reset loop. That is until I closed the browser, launched it again, then refreshed all pages and cleared the cache on the pages that failed.

Although it is the best it has ever been, I feel as though this could mean more tweaking... again... Unfortunately, tweaking like this makes it hard to tell what actually works, as the problem is so heavily intermittent and elusive to my abilities and foresight. By the time symptoms arise and become clearly apparent, it can last a very long time on non-functional settings but show no sign of it for literally hours or even days. On the other hand, there is some kind of gradient to the results as well because sometimes the symptoms are far worse and much more obvious, sometimes even immediately.
 
I need the specific details of the current issue and the dmesg output.

*Please attach the dmesg file.
 
Last edited:
Is it correct that the following log appears when the issue occurs?

Code:
[116549.246293] vfio-pci 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0002 address=0x164f342ea0 flags=0x0020]

Please change the RAM allocation settings for the integrated graphics processor (IGPU) in the BIOS configuration.

The target is items related to VRAM, such as UMA_SPECIFIED.

You will need to try various combinations and verify their functionality.

I recall experiencing a similar issue on my motherboard before the BIOS update if automatic allocation was enabled.
*On the motherboard I use, this issue no longer occurs with any settings when using the latest BIOS.

Meanwhile, others have reported encountering the same error unless they manually specify a fixed amount of memory.


*I don't have an MS-A2, so I don't know how to specify RAM in the MS-A2 BIOS...
 
Last edited:
I have specified it to 16GB, I don't think 8GB was better. I disabled the 2 settings related to dGPU. Presently I have Hybrid Graphics enabled. I guess I could turn that off again. Although I don't think that affected anything either.. I hope I get a BIOS update and everything is fixed. That would be great. I think it is starting to feel like modding the bios is my only hope.
 
  • Like
Reactions: uzumo
  • Using the hookscript method from isc30/ryzen-gpu-passthrough-proxmox issue #131 for my Ryzen 9 9955HX (integrated Radeon 610M) -> Windows 11 VM setup.


    Issue: I need help identifying why modern CPU models cause instability.

    • cpu: host, cpu: EPYC-v4, cpu: EPYC-v3: Lead to severe artifacts, screen blackouts, and AMD driver crashes in Windows, especially under load (e.g., multi-4K video).
    • cpu: kvm64: Initially shows minor artifacts that clear after boot/cache. After this initial period, the system is stable for demanding tasks (no driver crashes/blackouts like with the models above).

  • Goal: Achieve the stability of kvm64 (post-initial-clear) while getting the features of cpu: host or EPYC-*.


    Setup: 9955HX, MS-A2, hookscript, iommu=pt.


    Question: Has anyone encountered needing kvm64 for stability on Zen 5 with GPU passthrough? Are there specific flags or settings to make EPYC-* models stable for this hardware combo, or is this a known QEMU/Zen 5 interaction quirk?


    Thanks!
 
Last edited: