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

F

futiless

Renowned Member
Jul 4, 2017
33
4
73
45
North Vancouver, British Columbia : Canada

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

Hardware:

  • Host: Minisforum MS-A2 (Ryzen 7 9800X3D, Granite Ridge iGPU 1002:13c0)
  • VM: Windows 11 Pro (24H2)
  • Proxmox Version: 9.0 (Kernel 6.14.11-2-pve)


The Problem: "Loading Initial ramdisk" Hang with Error 43​

After weeks of relentless effort, I am stuck at the most frustrating point in GPU passthrough: the VM starts (TASK OK), but then hangs indefinitely at the "Loading Initial ramdisk" screen on the physical monitor connected to my MS-A2's GPU output. The Proxmox web console shows a black screen.


I have exhausted every known solution, and I'm now reaching out for help from the community.



What I've Tried (Systematically)​

I have followed every guide, forum post, and GitHub thread I could find. Here is a detailed account of my journey:


  1. Initial Setup & Kernel Selection
    • I started with the default Proxmox kernel (6.14.11-2-pve).
    • This kernel is the latest stable version for Proxmox 9.0.
    • I confirmed that the Ubuntu Live CD boots perfectly on the passed-through GPU, proving hardware compatibility.
  2. Addressing the AMD Reset Bug with vendor-reset
    • The error writing '1' to '/sys/bus/pci/devices/0000:01:00.0/reset': Inappropriate ioctl for device message is expected and is the manifestation of the AMD reset bug.
    • To fix this, I used the ballerburg9005/vendor-reset fork, which includes patches for newer kernels.
    • I manually edited src/device-db.h to add {PCI_VENDOR_ID_ATI, 0x13c0, op, DEVICE_INFO(AMD_NAVI10)}, /* Granite Ridge iGPU */.
    • I fixed a compilation error by changing #include <asm/unaligned.h> to #include <linux/unaligned.h> in src/amd/amdgpu/atom.c.
    • The module compiled successfully and is loaded at boot (lsmod | grep vendor_reset confirms it).

3.Ensuring GPU Isolation with VFIO

  • I configured /etc/modprobe.d/vfio.conf:

options vfio-pci ids=1002:13c0,1002:1640 disable_vga=1

I blacklisted host drivers in /etc/modprobe.d/blacklist.conf:

blacklist amdgpu
blacklist radeon
blacklist snd_hda_intel
  • After rebooting, lspci -nnk -s 01:00.0 correctly shows Kernel driver in use: vfio-pci.
  1. 4.VM Configuration with Hypervisor Hiding
    • My VM config (/etc/pve/qemu-server/101.conf) includes:
bios: ovmf
machine: pc-q35-10.0+pve1
vga: none
# GPU Passthrough
hostpci0: 0000:01:00.0,pcie=1,primary-gpu=1,rombar=1
hostpci1: 0000:01:00.1,pcie=1,rombar=0
args: -cpu 'host,kvm=off,hv_vendor_id=proxmox,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time'
  • I have installed VirtIO drivers from the ISO.
  1. 5. The Clean Install Method (The "Only Way")
    • As advised, I performed a clean install of Windows 11 without GPU passthrough first.
    • I then added the GPU passthrough after a full installation and shutdown.
    • Despite this, the VM still hangs at "Loading Initial ramdisk".

  1. Testing Alternative Kernels
    • I attempted to switch to an older, more stable Proxmox kernel (6.8.12-11-pve), as recommended in several guides.
    • However, even on this kernel, the issue persists. The vendor-reset module loads, the GPU is isolated, but the VM still hangs.

  1. The SeaBIOS Fallback
    • As a last resort, I tried switching to bios: seabios and machine: pc-i440fx-9.0.
    • This bypasses UEFI entirely and forces a legacy VGA handshake.
    • Unfortunately, this did not resolve the hang.


The Current State​

  • Host Side: ✅ Perfect. All configurations are correct. vendor-reset is loaded, GPU is isolated via vfio-pci, and the kernel is stable.
  • Guest Side: ❌ Failed. The VM fails to initialize the GPU correctly during early boot, leading to the "Loading Initial ramdisk" hang.


My Theory​

This is not a configuration error. It is a UEFI GOP (Graphics Output Protocol) incompatibility between my specific Granite Ridge iGPU and QEMU/OVMF. Ubuntu works because Linux is more forgiving about early graphics initialization. Windows is not.


The vendor-reset module handles the reset bug, but it does not solve the fundamental issue of Windows failing to initialize the GPU's UEFI firmware.



Request for Help​

I have done everything possible within my knowledge. I need help from the community.


Please, can anyone who has successfully passed through a Granite Ridge iGPU (or similar AMD iGPU) on Proxmox 9.0 with a recent kernel share their exact configuration?


Specifically, I need to know:

  1. What args line they use in their VM config?
  2. Did they use vendor-reset? If so, what kernel version and patch were used?
  3. Did they use seabios or stick with ovmf?
  4. Are there any specific BIOS settings on the MS-A2 that are critical?

Any insight, suggestion, or alternative approach would be immensely appreciated. I am ready to try anything.



Links to Relevant Resources:

  • Forum Post: Working AMD RX 9070XT Support
  • GitHub: ballerburg9005/vendor-reset
  • Forum Post: Solved - Proxmox 8.3.5 Kernel 6.11.11-1 Unable to Pass Through AMD iGPU
  • GitHub: gnif/vendor-reset

Thank you in advance for your time and expertise.
 
My virtual machine is operating based solely on the URL configuration procedure.

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

I have never used a vendor reset nor added it to a blacklist, so I cannot confirm if those methods would work.

The vbios and gop files are required, so you will need to obtain them.

https://github.com/isc30/ryzen-gpu-passthrough-proxmox/blob/main/vbios_9800x3d.bin

https://github.com/isc30/ryzen-gpu-passthrough-proxmox/blob/main/AMDGopDriver_9800x3d.rom

If you shut down or stop the virtual machine before completing the configuration, restart the host and verify that code 43 no longer appears before continuing with the configuration.

* You can proceed in whichever order you prefer. If using a blacklist or vendor reset works for you, that's perfectly fine.
The URL configuration process differs significantly from the standard procedure most people typically follow.
 
Last edited:
  • Like
Reactions: futiless
Thank you for the response and for pointing out the VBIOS/GOP requirement. You are absolutely correct, and it's a detail I had overlooked in my initial troubleshooting marathon.


The fact that an Ubuntu Live CD boots successfully on the passed-through GPU indicates that Linux can initialize the hardware via a different, more flexible path. However, Windows, particularly during its UEFI boot sequence, seems to require the specific firmware information contained within the VBIOS or a compatible GOP driver to successfully hand off control to the guest operating system.


This perfectly explains the persistent "Loading Initial ramdisk" hang – Windows is likely waiting for a display signal or firmware handshake that cannot be completed without the correct VBIOS blob being presented by QEMU.


Could you, or anyone else who has successfully passed through a Granite Ridge iGPU, please share:


  1. Where did you obtain the VBIOS file? Was it dumped directly from the hardware using tools like amdvbflash or radeonvbflash under Linux, or did you find a compatible one from a repository like TechPowerUp?
  2. How did you integrate it into your Proxmox VM configuration? Is it simply a matter of adding romfile=your_vbios.rom to the hostpci0 line in /etc/pve/qemu-server/VMID.conf?
  3. Did you need to do anything specific with GOP files? The mention of GOP files is new to me in this context. Is this related to OVMF firmware versions or specific QEMU parameters?

Any specific examples or pointers to resources on correctly dumping, verifying, and using the VBIOS for this specific iGPU would be incredibly valuable. This seems to be the missing piece of the puzzle.


I have vendor-reset working and vfio-pci isolation confirmed. Adding the correct firmware might be the final step to make Windows happy.
 
Please try the version distributed on GitHub.

If that doesn't work, instructions for extracting it are also provided, so please refer to those to create it.

Https://github.com/isc30/ryzen-gpu-passthrough-proxmox/blob/main/vbios_9800x3d.bin

https://github.com/isc30/ryzen-gpu-passthrough-proxmox/blob/main/AMDGopDriver_9800x3d.rom

Specify as follows

Code: 
cp vbios_9800x3d.bin /usr/share/kvm/
cp AMDGopDriver_9800x3d.rom /usr/share/kvm/


Code: 
qm set 101 -hostpci0 0000:01:00.0,pcie=1,romfile=vbios_9800x3d.bin
qm set 101 -hostpci1 0000:01:00.1,pcie=1,romfile=AMDGopDriver_9800x3d.rom
 
Last edited:
  • Like
Reactions: futiless
Hi Uzomo / everyone,


Just a quick update on the VBIOS file (AMDGopDriver_9800x3d.rom) investigation.


I tested the romfile= parameter extensively, primarily using the Ubuntu Live CD as a diagnostic tool, and here's what I observed:


  1. Without romfile=: The Ubuntu Live CD boots successfully and displays the desktop on the physical screen connected to the MS-A2's HDMI port. This confirms that standard VFIO passthrough is working correctly at the hardware and Proxmox level. Albeit only on Ubuntu.
  2. With romfile=/usr/share/kvm/AMDGopDriver_9800x3d.rom (and various combinations of x-vga=1 or primary-gpu=1): The Ubuntu Live CD fails to produce any output on the physical screen. The boot process appears to hang or get stuck very early (likely at "Loading Initial ramdisk" or a similar stage).

This leads me to conclude that, while the AMDGopDriver_9800x3d.rom file from the isc30/ryzen-gpu-passthrough-proxmox repository seemed promising (and might work for others with exactly the same hardware revision and Proxmox/QEMU version), it unfortunately prevents any OS from booting successfully in my specific setup.


This finding actually simplifies the path forward. Since standard passthrough works (proven by Ubuntu), the focus is now entirely on getting Windows 11 to cooperate with this standard method. This means continuing with the "Clean Windows Install" approach (installing Windows without the GPU passed through first, then adding passthrough) and ensuring all hypervisor hiding (args) and primary GPU flags (primary-gpu=1) are correctly configured in the VM.


Thanks again for all the suggestions and the VBIOS lead – it was a crucial test to eliminate that variable.
 
You should read the GitHub page provided.

https://github.com/isc30/ryzen-gpu-passthrough-proxmox

You want to use it on Windows 11, right?

You don't need to try Ubuntu at all if you want to use Windows 11.

I don't understand why you're specifying only gop.

AMDGopDriver_9800x3d.rom is not a vbios.

U

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

Please try the version distributed on GitHub.

If that doesn't work, instructions for extracting it are also provided, so please refer to those to create it.

Https://github.com/isc30/ryzen-gpu-passthrough-proxmox/blob/main/vbios_9800x3d.bin

https://github.com/isc30/ryzen-gpu-passthrough-proxmox/blob/main/AMDGopDriver_9800x3d.rom

Specify as follows

Code: 
cp vbios_9800x3d.bin /usr/share/kvm/
cp AMDGopDriver_9800x3d.rom /usr/share/kvm/


Code: 
qm set 101 -hostpci0 0000:01:00.0,pcie=1,romfile=vbios_9800x3d.bin
qm set 101 -hostpci1...
  • Like
 
Last edited:
  • Like
Reactions: DerekG and futiless
Success! Thank you uzumo!


I wanted to provide a final update: passthrough is now working perfectly!


After many days of extensive troubleshooting, trying various kernels (6.8.12-11-pve, 6.14.11-2-pve), meticulously configuring vfio-pci binding, blacklists, complex GRUB parameters, and wrestling with the vendor-reset module (which was correctly handling the AMD reset bug, thankfully), I was still hitting the "Loading Initial ramdisk" hang.

Flawed concepts that I read early on plagued me till the bitter end when uzumo came along and pointed out that he knew it worked and despite it being a integrated graphics card ; iGPU or NOT this was only possible with vBIOS and GOP file for audio.

The breakthrough came thanks to uzumo's persistent guidance and pointing me back to the isc30/ryzen-gpu-passthrough-proxmox repository. The critical misunderstanding was how to use the files provided in that repository, specifically confusing the roles of the vbios_9800x3d.bin and AMDGopDriver_9800x3d.rom files.


What Worked:


  • Host Configuration (Surprisingly Minimal):
    • Kernel: Default Proxmox kernel (6.14.11-2-pve).
    • GRUB: Default settings, only GRUB_CMDLINE_LINUX_DEFAULT="quiet" was necessary. No explicit amd_iommu=on, iommu=pt, video=... or initcall_blacklist=... was needed.
    • VFIO/Blacklist: No specific vfio.conf or blacklist.conf entries for the GPU were required. Standard Proxmox IOMMU and isolation handled it.
    • vendor-reset: While installed and patched, its role might have been less critical once the correct VBIOS/GOP files were used, though it was part of the stable setup.
  • VM Configuration (/etc/pve/qemu-server/101.conf):
    • Crucially, following the repository's README:
      • The main GPU passthrough line (hostpci0) uses the full VBIOS file:

hostpci0: 0000:01:00.0,pcie=1,primary-gpu=1,rombar=1,romfile=vbios_9800x3d.bin

The audio device passthrough line (hostpci1) uses the specific GOP driver file:

hostpci1: 0000:01:00.1,pcie=1,rombar=0,romfile=AMDGopDriver_9800x3d.rom

Other essential settings:

bios: ovmf
machine: q35
vga: none
args: -cpu 'host,kvm=off,-hypervisor,hv_vendor_id=proxmox' # Hypervisor hiding
boot: order=virtio0;ide0;net0 # Or appropriate disk/boot order
# ... (CPU, memory, disk, network settings) ...

The key was understanding that the isc30 repository provides two distinct files for two distinct purposes within the VM configuration:

  1. The complete VBIOS (vbios_9800x3d.bin) for the main GPU to handle full initialization.
  2. The specific GOP driver (AMDGopDriver_9800x3d.rom) for the audio device, likely to resolve UEFI compatibility or Error 43 issues related specifically to that function.

Once the correct files were placed in /usr/share/kvm/ and the VM config was updated precisely as shown in the repository's README (contrary to my earlier incorrect attempts of putting the GOP file on hostpci0 or using it without the VBIOS file), Windows booted successfully and displayed output on the physical screen.


This solution feels remarkably simple in hindsight compared to the complex configurations I was attempting, but it highlights how crucial it is to follow the specific instructions for the provided tools. The isc30/ryzen-gpu-passthrough-proxmox repository, combined with uzumo's corrections and insistence on reading the README properly, was the absolute key.


Huge thanks to uzumo for the patience and the critical pointer that ultimately solved this. Your contributions to figuring this out for the Granite Ridge iGPU are invaluable. I hope this summary helps anyone else facing the same challenge.


Cheers! ; if we helped remind us with a like .

https://github.com/isc30/ryzen-gpu-passthrough-proxmox


1758207748029.png
 
  • Like
Reactions: DerekG and uzumo
I'm glad it's resolved.
I hope you can help others facing similar challenges.

You should enable iommu=pt. It improves performance.
Enabling or disabling amd_iommu=on is fine either way. It's now the kernel's default setting.

Additionally, you should configure the following items.

Without these, the VM may not function properly after shutdown or restart.
*There is no way to respond to a forced shutdown.
*If you're running it 24/7, you might not need it.

While Microsoft's test tool devcon can be used, pnputil is the official replacement tool.
* Unlike devcon, which Microsoft has deprecated, pnputil is a standard Windows command.

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

Windows 11 Guest Startup Script (RadeonResetBugFix Alternative)

pnputil /enable-device /class Display /bus PCI /connected

Windows 11 Guest Shutdown Script (RadeonResetBugFix Alternative)

pnputil /disable-device /class Display /bus PCI /connected
Click to expand...
 
Last edited:
  • Like
Reactions: futiless and DerekG
uzumo said:
I'm glad it's resolved.
I hope you can help others facing similar challenges.

You should enable iommu=pt. It improves performance.
Enabling or disabling amd_iommu=on is fine either way. It's now the kernel's default setting.

Additionally, you should configure the following items.

Without these, the VM may not function properly after shutdown or restart.
*There is no way to respond to a forced shutdown.
*If you're running it 24/7, you might not need it.

While Microsoft's test tool devcon can be used, pnputil is the official replacement tool.
* Unlike devcon, which Microsoft has deprecated, pnputil is a standard Windows command.

https://github.com/isc30/ryzen-gpu-passthrough-proxmox/issues/131#issue-3266798285
Click to expand...
Hi @uzumo

Thanks to your guides I did manage to get a Win 11 VM fully functional on Promox 9. That is a task I would deem almost impossible for the average homelabber without your valuable input.

Could you please elabourate on the pnputil script mensioned, how best to implement it on the guest.
I have the shutdown / restart working with the devcon.exe but it seems like an extremely hacky solution, even just the getting hold of the exicutable was a task in itself.

Thanks

Derek
 
If devcon.exe can handle it, there's no need to switch to pnputil.

If you haven't set it up, it simply saves you the trouble of obtaining devcon.
 
uzumo said:
I'm glad it's resolved.
I hope you can help others facing similar challenges.

You should enable iommu=pt. It improves performance.
Enabling or disabling amd_iommu=on is fine either way. It's now the kernel's default setting.

Additionally, you should configure the following items.

Without these, the VM may not function properly after shutdown or restart.
*There is no way to respond to a forced shutdown.
*If you're running it 24/7, you might not need it.

While Microsoft's test tool devcon can be used, pnputil is the official replacement tool.
* Unlike devcon, which Microsoft has deprecated, pnputil is a standard Windows command.

https://github.com/isc30/ryzen-gpu-passthrough-proxmox/issues/131#issue-3266798285
Click to expand...
Very wise indeed. Pnputil is a fantastic idea. As stupid and as simple as it is would be, might be good to make it into a background process with a watchdog. Not like its necessary but that would be a default go to when building a vm ;) ... Thanks for the advice I will have more time to tinker in a couple days. The server is causing a home rewiring. :)
 
uzumo said:
If devcon.exe can handle it, there's no need to switch to pnputil.

If you haven't set it up, it simply saves you the trouble of obtaining devcon.
Click to expand...


Hi uzumo

First and foremost, thank you. Your guidance and the resources you pointed to were absolutely critical in finally getting this working. After weeks of struggle, we have a stable passthrough setup on our Minisforum MS-A2 with the Granite Ridge iGPU (`1002:13c0`). Your patience and expertise are genuinely appreciated.

We wanted to share our final, working configuration and some key insights that might help others (or even yourself) in the future.

### ✅ Our Final, Working Configuration

The core of our success was following the `isc30/ryzen-gpu-passthrough-proxmox` repository's README to the letter:
* **VBIOS File:** `vbios_9800x3d.bin` applied to the main GPU (`hostpci0`).
* **GOP Driver File:** `AMDGopDriver_9800x3d.rom` applied to the audio device (`hostpci1`).

This combination, which you correctly emphasized, was the magic key. I was initially misled by trying to use the GOP driver on the main GPU, which caused the "Loading Initial ramdisk" hang. Your clarification was the breakthrough.

### Critical Insights & Tweaks for Stability

1. **Integrated Graphics Memory Allocation (BIOS):** This was a major, non-obvious hurdle. The "Auto" setting for UMA Frame Buffer Size in the BIOS caused severe visual corruption, screen tearing, and system instability during passthrough. **Setting it to a fixed value (I used 8/16GB) was essential for a stable image.** Anyone attempting this with an iGPU should check this BIOS setting first.

2. **Kernel Parameters:** I amcurrently running with a minimal, stable set:
```bash
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"
```
Do you think more aggressive parameters like `initcall_blacklist=sysfb_init video=vesafb:off,efifb:off,simplefb:off` are necessary for our working setup with the correct VBIOS/GOP files. The `pcie_acs_override=downstream,multifunction` parameter also proved unnecessary but those lingering blackscreen hangs on rare occation.

3. **VM CPU Args:** I am using a standard, clean hypervisor hiding configuration:
```bash
args: -cpu 'host,kvm=off,-hypervisor,hv_vendor_id=proxmox'
```
This has been sufficient to avoid Error 43 in Windows 11 without needing the extensive list of `hv_*` flags.

4. **The "Occasional Reboot" Issue:** You are right that the AMD reset bug is never *fully* eradicated.I am still encounter a situation roughly every 3-5 VM reboots where a full host reboot is required to get the GPU to reinitialize correctly for the VM. This is the final frontier. I am are NOT currently using the `vendor-reset` module, which may help but isn't 100% perfect so its are to say what is the best option from my novice perspective. We are actively seeking any guides, tools, or tricks (like the `hookscript` you mentioned in your other post) to make this even more robust. Any further insights you have on completely eliminating this would be the holy grail.

5.
Windows 11 Guest Startup Script (RadeonResetBugFix Alternative)
pnputil /enable-device /class Display /bus PCI /connected

Windows 11 Guest Shutdown Script (RadeonResetBugFix Alternative)
pnputil /disable-device /class Display /bus PCI /connected

ABSOLUTELY the best option, forget older methods.

### Final Thanks and Question

Again, thank you. Your insistence on using the files from the repository correctly was the turning point.

**Do you have any specific recommendations for tools, scripts (like the cockpit for additional add-ons), or advanced `args` parameters that could help us achieve 100% stability/performance and eliminate the occasional host reboot?** I am eager to optimize this final piece.

Best regards,
 
Last edited:
It will function normally unless the following operations are performed.

Proxmox Windows 11 Virtual Machine force stop (stop)
Proxmox Windows 11 Virtual Machine force reset (reset)
Windows OS BSOD

These operations do not perform proper termination procedures, preventing pass-through PCI devices from shutting down correctly. This behavior is considered unavoidable under any circumstances.

Proxmox Windows 11 Virtual Machine force reset (reset) * Proxmox VE hosts automatically reboot due to issues.
Code: 
Sep 21 11:47:32 pve2 kernel: vfio-pci 0000:10:00.1: resetting
Sep 21 11:47:33 pve2 kernel: vfio-pci 0000:10:00.1: reset done
Sep 21 11:47:33 pve2 pvedaemon[2129]: <root@pam> end task UPID:pve2:000036C7:0002867C:68CF6744:qmreset:822:root@pam: OK
Sep 21 11:47:44 pve2 kernel: usb 3-2: reset high-speed USB device number 2 using xhci_hcd
Sep 21 11:47:52 pve2 kernel: usb 3-2: reset high-speed USB device number 2 using xhci_hcd


Proxmox Windows 11 Virtual Machine force stop (stop) * A reboot of the Proxmox VE host is required. If a virtual machine is started, the Proxmox VE host will reboot due to an issue.
Code: 
Sep 21 11:09:11 pve2 pvedaemon[2117]: <root@pam> starting task UPID:pve2:00060674:00733410:68CF5E47:qmstop:822:root@pam:
Sep 21 11:09:11 pve2 pvedaemon[394868]: stop VM 822: UPID:pve2:00060674:00733410:68CF5E47:qmstop:822:root@pam:
Sep 21 11:09:11 pve2 kernel:  zd32: p1 p2 p3 p4
Sep 21 11:09:12 pve2 qmeventd[1403]: read: Connection reset by peer
Sep 21 11:09:12 pve2 pvedaemon[2118]: VM 822 qmp command failed - unable to open monitor socket
Sep 21 11:09:12 pve2 kernel: usb 3-2: reset high-speed USB device number 2 using xhci_hcd
Sep 21 11:09:12 pve2 kernel: input: sipeed NanoKVM as /devices/pci0000:00/0000:00:08.1/0000:10:00.3/usb3/3-2/3-2:1.0/0003:3346:1009.0005/input/input17
Sep 21 11:09:12 pve2 kernel: hid-generic 0003:3346:1009.0005: input,hidraw0: USB HID v1.01 Keyboard [sipeed NanoKVM] on usb-0000:10:00.3-2/input0
Sep 21 11:09:12 pve2 kernel: input: sipeed NanoKVM as /devices/pci0000:00/0000:00:08.1/0000:10:00.3/usb3/3-2/3-2:1.1/0003:3346:1009.0006/input/input18
Sep 21 11:09:12 pve2 kernel: hid-generic 0003:3346:1009.0006: input,hidraw1: USB HID v1.01 Mouse [sipeed NanoKVM] on usb-0000:10:00.3-2/input1
Sep 21 11:09:12 pve2 kernel: input: sipeed NanoKVM as /devices/pci0000:00/0000:00:08.1/0000:10:00.3/usb3/3-2/3-2:1.2/0003:3346:1009.0007/input/input19
Sep 21 11:09:12 pve2 kernel: hid-generic 0003:3346:1009.0007: input,hidraw2: USB HID v1.01 Mouse [sipeed NanoKVM] on usb-0000:10:00.3-2/input2
Sep 21 11:09:12 pve2 systemd-logind[1399]: Watching system buttons on /dev/input/event3 (sipeed NanoKVM)
Sep 21 11:09:12 pve2 qmeventd[394911]: Starting cleanup for 822
Sep 21 11:09:12 pve2 qmeventd[394911]: trying to acquire lock...
Sep 21 11:09:12 pve2 systemd[1]: 822.scope: Deactivated successfully.
Sep 21 11:09:12 pve2 systemd[1]: 822.scope: Consumed 1min 49.560s CPU time, 27G memory peak.
Sep 21 11:09:13 pve2 qmeventd[394911]:  OK
Sep 21 11:09:13 pve2 pvedaemon[2117]: <root@pam> end task UPID:pve2:00060674:00733410:68CF5E47:qmstop:822:root@pam: OK
Sep 21 11:09:13 pve2 qmeventd[394911]: Phase is post-stop
Sep 21 11:09:18 pve2 kernel: vfio-pci 0000:10:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=none
Sep 21 11:09:25 pve2 kernel: [drm] initializing kernel modesetting (IP DISCOVERY 0x1002:0x164E 0x1849:0x364E 0xC5).
Sep 21 11:09:25 pve2 kernel: [drm] register mmio base: 0xF4D00000
Sep 21 11:09:25 pve2 kernel: [drm] register mmio size: 524288
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 0 <nv_common>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 1 <gmc_v10_0>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 2 <navi10_ih>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 3 <psp>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 4 <smu>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 5 <dm>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 6 <gfx_v10_0>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 7 <sdma_v5_2>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 8 <vcn_v3_0>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: detected ip block number 9 <jpeg_v3_0>
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: Fetched VBIOS from VFCT
Sep 21 11:09:25 pve2 kernel: amdgpu: ATOM BIOS: 102-RAPHAEL-008
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: vgaarb: deactivate vga console
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: Trusted Memory Zone (TMZ) feature disabled as experimental (default)
Sep 21 11:09:25 pve2 kernel: [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: VRAM: 16384M 0x0000FFFFFF000000 - 0x00010003FEFFFFFF (16384M used)
Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF


***** issue *****



> Sep 21 11:09:25 pve2 kernel: ------------[ cut here ]------------
> Sep 21 11:09:25 pve2 kernel: memtype_reserve failed: [mem 0xfffffff000000-0x3feffffff], req write-combining
> Sep 21 11:09:25 pve2 kernel: WARNING: CPU: 10 PID: 394937 at arch/x86/mm/pat/memtype.c:536 memtype_reserve+0x2f0/0x340
> Sep 21 11:09:25 pve2 kernel: Modules linked in: cmac nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 netfs ebtable_filter ebtables ip_set ip6table_raw iptable_raw ip6table_filter ip6_tables iptable_filter nf_tables nfnetlink_cttimeout softdog sunrpc binfmt_misc bonding openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nfnetlink_log amd_atl intel_rapl_msr intel_rapl_common amdgpu mt7921e mt7921_common snd_hda_codec_realtek edac_mce_amd mt792x_lib kvm_amd mt76_connac_lib snd_hda_codec_generic amdxcp mt76 snd_hda_scodec_component snd_hda_codec_hdmi gpu_sched snd_hda_intel drm_panel_backlight_quirks drm_buddy snd_intel_dspcfg snd_intel_sdw_acpi drm_ttm_helper kvm mac80211 ttm snd_hda_codec btusb polyval_clmulni drm_exec polyval_generic drm_suballoc_helper btrtl ghash_clmulni_intel snd_hda_core drm_display_helper btintel sha256_ssse3 sha1_ssse3 btbcm snd_hwdep cec btmtk snd_pcm aesni_intel snd_timer rc_core crypto_simd cryptd cfg80211 snd i2c_algo_bit bluetooth wmi_bmof rapl pcspkr spd5118
> Sep 21 11:09:25 pve2 kernel:  soundcore k10temp ccp libarc4 input_leds joydev mac_hid sch_fq_codel vhost_net vhost vhost_iotlb tap nct6775 nct6775_core hwmon_vid vfio_pci vfio_pci_core irqbypass vfio_iommu_type1 vfio iommufd nvme_tcp nvme_fabrics nvme_keyring efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 zfs(PO) spl(O) btrfs blake2b_generic xor raid6_pq mlx5_ib ib_uverbs macsec ib_core uas usb_storage hid_generic usbhid hid mlx5_core xhci_pci mlxfw nvme psample i2c_piix4 ahci r8169 i2c_smbus xhci_hcd tls libahci pci_hyperv_intf realtek nvme_core nvme_auth video wmi gpio_amdpt
> Sep 21 11:09:25 pve2 kernel: CPU: 10 UID: 0 PID: 394937 Comm: ryzen_igpu_rese Tainted: P           O       6.14.11-2-pve #1
> Sep 21 11:09:25 pve2 kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE
> Sep 21 11:09:25 pve2 kernel: Hardware name: ASRock B850M-X WiFi R2.0/B850M-X WiFi R2.0, BIOS 3.40 08/27/2025
> Sep 21 11:09:25 pve2 kernel: RIP: 0010:memtype_reserve+0x2f0/0x340
> Sep 21 11:09:25 pve2 kernel: Code: 84 83 fa 05 77 0b 41 89 d6 4e 8b 04 f5 20 e7 40 84 48 89 d9 4c 89 e2 48 c7 c6 50 e7 40 84 48 c7 c7 50 ff 9c 84 e8 d0 1c 02 00 <0f> 0b 41 b9 ea ff ff ff e9 92 fd ff ff 4d 85 ed 0f 84 86 fd ff ff
> Sep 21 11:09:25 pve2 kernel: RSP: 0018:ffffccc96402f830 EFLAGS: 00010246
> Sep 21 11:09:25 pve2 kernel: RAX: 0000000000000000 RBX: 00000003feffffff RCX: 0000000000000000
> Sep 21 11:09:25 pve2 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> Sep 21 11:09:25 pve2 kernel: RBP: ffffccc96402f870 R08: 0000000000000000 R09: 0000000000000000
> Sep 21 11:09:25 pve2 kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 000fffffff000000
> Sep 21 11:09:25 pve2 kernel: R13: ffffccc96402f8d4 R14: 0000000000000001 R15: 0000000400000000
> Sep 21 11:09:25 pve2 kernel: FS:  00007cdda3761740(0000) GS:ffff89d10dd00000(0000) knlGS:0000000000000000
> Sep 21 11:09:25 pve2 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Sep 21 11:09:25 pve2 kernel: CR2: 00007cdda394d7b0 CR3: 0000001197c29000 CR4: 0000000000f50ef0
> Sep 21 11:09:25 pve2 kernel: PKRU: 55555554
> Sep 21 11:09:25 pve2 kernel: Call Trace:
> Sep 21 11:09:25 pve2 kernel:  <TASK>
> Sep 21 11:09:25 pve2 kernel:  memtype_reserve_io+0x5e/0x120
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  arch_io_reserve_memtype_wc+0x2f/0x50
> Sep 21 11:09:25 pve2 kernel:  amdgpu_bo_init+0x5a/0xb0 [amdgpu]
> Sep 21 11:09:25 pve2 kernel:  gmc_v10_0_sw_init+0x342/0x5b0 [amdgpu]
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  amdgpu_device_init.cold+0x183b/0x254e [amdgpu]
> Sep 21 11:09:25 pve2 kernel:  ? pci_read_config_word+0x27/0x50
> Sep 21 11:09:25 pve2 kernel:  amdgpu_driver_load_kms+0x1a/0x80 [amdgpu]
> Sep 21 11:09:25 pve2 kernel:  amdgpu_pci_probe+0x1d3/0x480 [amdgpu]
> Sep 21 11:09:25 pve2 kernel:  local_pci_probe+0x44/0xa0
> Sep 21 11:09:25 pve2 kernel:  pci_device_probe+0xea/0x290
> Sep 21 11:09:25 pve2 kernel:  really_probe+0xf6/0x370
> Sep 21 11:09:25 pve2 kernel:  ? pm_runtime_barrier+0x55/0xa0
> Sep 21 11:09:25 pve2 kernel:  __driver_probe_device+0x8c/0x140
> Sep 21 11:09:25 pve2 kernel:  device_driver_attach+0x55/0xe0
> Sep 21 11:09:25 pve2 kernel:  bind_store+0x77/0xd0
> Sep 21 11:09:25 pve2 kernel:  drv_attr_store+0x21/0x50
> Sep 21 11:09:25 pve2 kernel:  sysfs_kf_write+0x3b/0x60
> Sep 21 11:09:25 pve2 kernel:  kernfs_fop_write_iter+0x149/0x1f0
> Sep 21 11:09:25 pve2 kernel:  vfs_write+0x299/0x460
> Sep 21 11:09:25 pve2 kernel:  ksys_write+0x70/0xf0
> Sep 21 11:09:25 pve2 kernel:  __x64_sys_write+0x19/0x30
> Sep 21 11:09:25 pve2 kernel:  x64_sys_call+0x2a3/0x2310
> Sep 21 11:09:25 pve2 kernel:  do_syscall_64+0x7e/0x170
> Sep 21 11:09:25 pve2 kernel:  ? syscall_exit_to_user_mode+0x38/0x1d0
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? do_syscall_64+0x8a/0x170
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? arch_exit_to_user_mode_prepare.isra.0+0x22/0x120
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? syscall_exit_to_user_mode+0x38/0x1d0
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? do_syscall_64+0x8a/0x170
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? __handle_mm_fault+0xb43/0x1040
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? syscall_exit_to_user_mode+0x38/0x1d0
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? get_close_on_exec+0x34/0x50
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? do_fcntl+0x2ed/0x750
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? __x64_sys_fcntl+0x9f/0x110
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? arch_exit_to_user_mode_prepare.isra.0+0x22/0x120
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? syscall_exit_to_user_mode+0x38/0x1d0
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? do_syscall_64+0x8a/0x170
> Sep 21 11:09:25 pve2 kernel:  ? filp_flush+0x5a/0xb0
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? arch_exit_to_user_mode_prepare.isra.0+0x22/0x120
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? syscall_exit_to_user_mode+0x38/0x1d0
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? do_syscall_64+0x8a/0x170
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? irqentry_exit+0x43/0x50
> Sep 21 11:09:25 pve2 kernel:  ? srso_alias_return_thunk+0x5/0xfbef5
> Sep 21 11:09:25 pve2 kernel:  ? exc_page_fault+0x96/0x1e0
> Sep 21 11:09:25 pve2 kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> Sep 21 11:09:25 pve2 kernel: RIP: 0033:0x7cdda37f3687
> Sep 21 11:09:25 pve2 kernel: Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
> Sep 21 11:09:25 pve2 kernel: RSP: 002b:00007fff34e86770 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
> Sep 21 11:09:25 pve2 kernel: RAX: ffffffffffffffda RBX: 00007cdda3761740 RCX: 00007cdda37f3687
> Sep 21 11:09:25 pve2 kernel: RDX: 000000000000000d RSI: 00005a09baca1560 RDI: 0000000000000001
> Sep 21 11:09:25 pve2 kernel: RBP: 00005a09baca1560 R08: 0000000000000000 R09: 0000000000000000
> Sep 21 11:09:25 pve2 kernel: R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d
> Sep 21 11:09:25 pve2 kernel: R13: 00007cdda394c5c0 R14: 00007cdda3949e80 R15: 0000000000000000
> Sep 21 11:09:25 pve2 kernel:  </TASK>
> Sep 21 11:09:25 pve2 kernel: ---[ end trace 0000000000000000 ]---
> Sep 21 11:09:25 pve2 kernel: [drm:amdgpu_bo_init [amdgpu]] *ERROR* Unable to set WC memtype for the aperture base
> Sep 21 11:09:25 pve2 kernel: [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* sw_init of IP block <gmc_v10_0> failed -22
> Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: amdgpu_device_ip_init failed
> Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: Fatal error during GPU init
> Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: amdgpu: amdgpu: finishing device.
> Sep 21 11:09:25 pve2 kernel: amdgpu 0000:10:00.0: probe with driver amdgpu failed with error -22


***** issue *****



Sep 21 11:09:25 pve2 kernel: snd_hda_intel 0000:10:00.1: Handle vga_switcheroo audio client
Sep 21 11:09:25 pve2 kernel: input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:08.1/0000:10:00.1/sound/card0/input20
Sep 21 11:09:25 pve2 kernel: input: HD-Audio Generic HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:08.1/0000:10:00.1/sound/card0/input21
Sep 21 11:09:25 pve2 kernel: input: HD-Audio Generic HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:08.1/0000:10:00.1/sound/card0/input22
Sep 21 11:09:25 pve2 kernel: input: HD-Audio Generic HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:08.1/0000:10:00.1/sound/card0/input23
Sep 21 11:09:27 pve2 qmeventd[394911]: Finished cleanup for 822


Proxmox Windows 11 Virtual Machine force stop (start after force stop) * virtual machine is started, the Proxmox VE host will reboot due to an issue.
Code: 
Sep 21 11:18:21 pve2 systemd[1]: Received SIGINT.


Windows OS BSOD * Proxmox VE hosts automatically reboot due to issues.
Code: 
Sep 21 12:13:15 pve2 kernel: vfio-pci 0000:10:00.1: resetting
Sep 21 12:13:15 pve2 kernel: vfio-pci 0000:10:00.1: reset done
Sep 21 12:13:27 pve2 kernel: usb 3-2: reset high-speed USB device number 2 using xhci_hcd
Sep 21 12:13:36 pve2 kernel: usb 3-2: reset high-speed USB device number 2 using xhci_hcd

These operations have been verified in the following configuration environment.

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

Attachments

Last edited:
Have you tried VFIO passthrough (what vender-reset enables) with recent kernels to know if they can get it from 80 % - > 100%. depleting that one or two failures i get to display passthrough going solid green color. That is until host pve is reset.. anyways .. Or can you confirm this is fools gold. I just get these forest green screens sometimes preventing vm boot (I can shutdown via QEMU service mind you. So its not stalled, just video passthrough.) .. Maybe you can sympathize with my need to waste forever tweaking..

; should I also stay away from `initcall_blacklist=sysfb_init video=vesafb:off,efifb:off,simplefb:off? .. I just get the impression its not always the same protocol.
 
futiless said:
Integrated Graphics Memory Allocation (BIOS)
Click to expand...

This appears to be a BIOS-related issue, and depending on the BIOS version, it may have been fixed.



Kernel options should only be specified when necessary.

futiless said:
pcie_acs_override=downstream,multifunction
Click to expand...

If the IOMMU group is split, it's not needed.

futiless said:
`initcall_blacklist=sysfb_init video=vesafb:off,efifb:off,simplefb:off`
Click to expand...

These are mixed up with past options.
I feel saddened that so many sites provide guidance using such specifications.
* By not being able to configure it, they reference various information and mix procedures from past versions with those from the latest version.
* AI learns these and responds with a mixture of them.

An option to disable frame buffer initialization or something like that.

5.15.64-1-pve and later
Code: 
initcall_blacklist=sysfb_init

Before 5.15.64-1-pve
Code: 
nofb video=vesafb:off video=efifb:off video=simplefb:off
 
Last edited:
  • Like
Reactions: futiless
futiless said:
what vender-reset enables
Click to expand...

I apologize. I make a conscious effort to avoid using external modules unless absolutely necessary.
I deliberately refrain from using them in areas that function perfectly well without them. (This is purely my personal opinion.)
Therefore, I have never used vendor-resets before.


I recall that on Proxmox VE 8, the screen was green before performing a Proxmox Windows 11 Virtual Machine force reset (reset) or configuring the settings below.

Windows 11 Guest Startup Script (RadeonResetBugFix Alternative)
Windows 11 Guest Shutdown Script (RadeonResetBugFix Alternative)

I'm not sure if it will work, but if a problem occurs, it would be great if we could improve the situation without restarting Proxmox VE by executing the following command while the virtual machine is stopped.

Code: 
echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
echo 1 > /sys/bus/pci/rescan


Proxmox Windows 11 Virtual Machine force stop (stop)
Proxmox Windows 11 Virtual Machine force reset (reset)
Windows OS BSOD
Click to expand...

We are only verifying issues related to the patterns described above (they are likely unavoidable). If you are experiencing other issues, please try using URL settings.
* Only use this if you are confident you can revert changes should the URL procedure not yield the expected result.
* Please use it only when you have time to spare.

https://github.com/isc30/ryzen-gpu-passthrough-proxmox/issues/131#issue-3266798285
 
Last edited:
  • Like
Reactions: futiless
You must log in or register to reply here.
Top Bottom