GPU passthrough with a GMKTec K8 - Locks up host

[phoniclynx]

I've just bought myself this little GMKTec K8 mini PC intending to use game passthrough whilst I'm on the road. I have followed some guides on how to set this up and everything looks to be configured correctly.

But when I go to start the Windows 11 VM that I've set the pass through to it locks up the Proxmox host and the only way to get back to it is to power off the device and wait for it to load back up.

Grub config:

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"
GRUB_CMDLINE_LINUX=""

Below is the output of lspci

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14e8
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 14e9
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14ea
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14ea
00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 14ee
00:02.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 14ee
00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 14ee
00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14ea
00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 19h USB4/Thunderbolt PCIe tunnel
00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14ea
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14ea
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 14eb
00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 14eb
00:08.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 14eb
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 71)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14f0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14f1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14f2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14f3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14f4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14f5
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14f6
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 14f7
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
03:00.0 Non-Volatile memory controller: Shenzhen Longsys Electronics Co., Ltd. Lexar NM790 NVME SSD (DRAM-less) (rev 01)
64:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix3 (rev c5)
64:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt Radeon High Definition Audio Controller
64:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 19h (Model 74h) CCP/PSP 3.0 Device
64:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15b9
64:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15ba
64:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller
65:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 14ec
65:00.1 Signal processing controller: Advanced Micro Devices, Inc. [AMD] AMD IPU Device
66:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 14ec
66:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15c0
66:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Device 15c1
66:00.5 USB controller: Advanced Micro Devices, Inc. [AMD] Pink Sardine USB4/Thunderbolt NHI controller

I can see the GPU sitting at 64:00.0 along with the sound device at 64:00.1:

64:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix3 (rev c5)
64:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt Radeon High Definition Audio Controller

lspci reports:

lspci -n -s 64:00
64:00.0 0300: 1002:1900 (rev c5)
64:00.1 0403: 1002:1640
64:00.2 1080: 1022:15c7
64:00.3 0c03: 1022:15b9
64:00.4 0c03: 1022:15ba
64:00.6 0403: 1022:15e3

and I've put the line into /etc/modprobe.d/vfio.conf

options vfio-pci ids=1002:1900,1002:1640,1022:15c7,1022:15e3 disable_vga=1

Interestingly enough when I go to add the hardware, the name of the hardware doesn't show up but some of them to:

If I select this with either all functionr not unticked and start the VM it dosn't even get past the proxmox vm post before the whole host locks up.

Any ideas on what I can do?

 

[frankmanzhu]

iGPU passthrough is a little different because more stuff hanging off the gpu group. This prevent the use all function flag.

/etc/modprobe.d/vfio.conf
options vfio-pci ids=1002:1900,1002:1640

for VGA and sound only.

Also you need to extract the romfile from your gpu, luckily you one can be found here.

https://github.com/isc30/ryzen-7000-series-proxmox

This is more important, in your VM setup,
use Bios: SeaBios

Otherwise, you need to do the audio romfile too which is a big pain for me.

 

[phoniclynx]

ok.. so i followed all the instructions... it "works" then it doesn't work. RDP connects then it seems to kill the card and I get the error 43. Parsec on linux complains that there is no codec.. however on android it connects, I can see things but it's super hard to control and sometimes the mode gets out of sync and I can't click on anything because the mouse goes off the physical screen but not off the remote screen. one device sends keyboard commands through whilst the other doesn't.. this is just crazy haha. I've put the ROM on it for the 8846hs bin on it, but that didn't seem to have much of an effect. Not sure where to head next.. seems super unstable and not usable tbh

 

[frankmanzhu]

Have you installed the amd reset bug service? I haven’t tried Remote Desktop, but it requires a while to be able to login to desktop.

Also check the bios and see if there are iommu settings and make sure it’s enabled. It might improve the VFIO groupings.

The 43 error looks like you have used OVMF in the bios setting?

 

[GiorTr]

Hi,
did you managed to make the passtorught works? i am in the same situation with no chance to make it work.
i will appreciate any kind of help

 

[DerekG]

Hi,
did you managed to make the passtorught works? i am in the same situation with no chance to make it work.
i will appreciate any kind of help

Unsure which AMD APU you have (mine is the 8845HS), but the https://github.com/isc30/ryzen-7000-series-proxmox guide carefully (don't miss any steps) the passthrough will work. There are 2 additions steps, also detailed on the same github page, where once you do get the passthrough operational, you need to resolve the AMD reset bug on both the host and within the VM guest.

One more thing I've noticed, I installed on Proxmox 8.4 and when I upgrades to 9.0 the Kernel was not upgraded & remained on 'Linux 6.8.12-14-pve', so I would check on 8.4 if I were you.

I have a Windows 11 working perfectly by following that guide (choosing the correct BIOS for video and audio). Although I haven't checked the video out via HDMI, my windows guest is detecting the dummy HDMI which I have plugged in.

 

[cshifer12]

I have the same GMKTec K8 mini PC. I also had windows 11 VM for gaming (This IGD is so powerfull for me) and linux VM for working. Both with iGPU passthrough. In windows 11 i had amd reset bug fix installed and it did work 4 times out of 10. But it was painfully slow to start and shutdown the windows VM.

Though i never was able to use any method for reset bug fix in linux VM. So everytime i turned off windows VM and started linux VM i had to reboot host to be able to start windows VM again. So i just removed amd reset bug fix from windows VM and every time i wanted to switch from windows VM to linux VM or vice versa i just reboot the host. This way it works 10 out of 10 time. But this is of course stupid. If you are rebooting host why not just dual boot then. So i eventually removed windows VM and started playing games in linux VM (Thank you Valve for proton)

I suggest look into intel B50 GPU. That has SR-IOV working and we have oculink port on this mini PC. With that GPU you will be able to have 8 VMs all running with GPU passthrough with 2 GB VRAM each. Or 2 of them with 8 GB VRAM. As far as i know this is the only GPU apart from B60 (Way too expensive) that does this in an affordable and mainstream hardware.

I am mad at AMD. Why the hell does it take them soooo much time to fix this crappy reset bug?

BTW intel had this vGPU technology for their IGPUs back then. I had thinkpad t440 and t450s and in both i had small script which created vGPU and passed through to vms which i was running with qemu/KVM. I do not know why they removed this tech from iGPUs but thank god they gave it back with this B50 GPU.

 

[GiorTr]

Hi, thank for your kind and useful response.
At the moment i managed to passtorught the GPU but I am facing the AMD reboot bug even after have installed the fix on the windows machine.
It seems that the reboot made inside the VM I mean by windows reboot is less stressfull and generally doesn't cause the crash, not the same if I rebout the VM from Proxmox interface.
Did you manage to solve the AMD reboot bug both by rebooting the vm by proxmox and even rebooting form inside the win machine?

Have also made the usb controller passtrought?

thank for any helps

 

[cshifer12]

I have not noticed difference rebooting from inside windows VM or proxmox. TBH i did not think about it at the time. I remember that i used to shutdown windows VM from both places but as i mentioned this fix worked 4 times out of 10. It was not reliable and it was painfully slow. That's why i got rid of it. If it was reliable i would wait those 5-7 minutes to reboot/shutdown VM.

No luck with usb controller passthrough either. But i did not try it for long. Just a few hours and then stopped trying. I just put USB device ids inside conf file for VM and use usb devices inside VM this way. Of course passing through whole controller is much better solution. I do get some strange errors from time to time with usb devices. But they still work no problems. It's just if i ever want to connect some new device i need to reboot VM hence reboot the host and change conf file. With controller passed through one would just connect to port for it and it would show up in VM.

Please if you manage to passthrough usb controller ping me here so i can also do it. Thank you!

 

[GiorTr]

About USB controller passtorught at te moment is seems (but not sure) that it worked. But I belive the problem now is related to drivers. even using ADM install manger I am not abel to do it.

 

[DerekG]

Hi, thank for your kind and useful response.
At the moment i managed to passtorught the GPU but I am facing the AMD reboot bug even after have installed the fix on the windows machine.
It seems that the reboot made inside the VM I mean by windows reboot is less stressfull and generally doesn't cause the crash, not the same if I rebout the VM from Proxmox interface.
Did you manage to solve the AMD reboot bug both by rebooting the vm by proxmox and even rebooting form inside the win machine?

Have also made the usb controller passtrought?

thank for any helps

If the original AMD reset fix doesn't work try another.
I have an 8845HS working perfectly in a Win 11 guest, so I am able to reboot from the host or from within Windows without delay.
There is a 'hook-script' which works on the host and 2 different functional fixes in the Windows guest.

 

[GiorTr]

Hi DerekG,
tanks for your clarification. When you speak about hook script you refear to the vendor-reset script?

 

[DerekG]

Hi DerekG,
tanks for your clarification. When you speak about hook script you refear to the vendor-reset script?

Hi GioTr,

It might well depend on your APU, but if you already have the passthrough functioning correctly, then this page should help with the AMD reset bug:

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

Note: As stated previously, a Proxmox hook-script is required to enable a clean reset from the Proxmox interface.

Then the pnputil script is required in the guest OS to enable the Windows restart to work correctly. If that fails, there is also another method utilising the older devcon.exe device reset (that is what I am using), but getting the devcon.exe file is complicated, so I suggest trying the pnputil script first.

If you really want to understand what is causing the issue (rather than just getting it to work), there is a great write-up which covers a lot of the details of the problem here:
https://github.com/xiongyw/docs/blo...rum-um880pro/pve-8.4-1_minisforum-um880pro.md

i hope that helps.

 

[GiorTr]

Hi DerekG
Thanks to your precious informations I finally got the passtrought working, I have also been able to passtorugh USB controllers, even if I am not shure if for this is still required some tuning.

Thank you so much for the information shared.

 

[DerekG]

@GioTr,

Happy to hear that you eventually got the passthrough working there.

Please mark this thread as 'Solved' so that others who can find the solution in these threads.

 

[cshifer12]

Hi DerekG
Thanks to your precious informations I finally got the passtrought working, I have also been able to passtorugh USB controllers, even if I am not shure if for this is still required some tuning.

Thank you so much for the information shared.

Could you please share the conf file for the VM?

Did you use that hook script? If yes did it work for linux VM or you only used it for windows VM?

What steps did you follow for passthrough to work?

 

[DerekG]

Could you please share the conf file for the VM?

Did you use that hook script? If yes did it work for linux VM or you only used it for windows VM?

What steps did you follow for passthrough to work?

"Could you please share the conf file for the VM?"

My conf file is specific for a Windows VM. If you follow that you are likely going to confuse yourself and go around in circles.

"Did you use that hook script? If yes did it work for linux VM or you only used it for windows VM?"

Some of the steps are not required for a Linux VM, but I only have the one AMD unit so never tried on Linux.

"What steps did you follow for passthrough to work?"

I am unable to advise. This will be a trial and error case in Linux, I suggest that you try it with your Linux VM and then refer to the guide when you hit an error. There are 3 distinct steps in the process, 1) passthrough the GPU to VM, 2) solve the reset bug on the Host, 3) solve the reset bug in the VM.

Note: The reset bug manifests itself on the VM restart/reboot either from the Host or from within the VM, so you should focus purely on getting the passthrough working before worrying about the reset bug and the scripts.

I have read that some users have got the passthrough working in Linux without the use of the .rom files, but I'm unable to verify that.

Good luck out there,

 

[cshifer12]

Good luck out there,

Thank you for giving me nothing and not helping at all.

I hope OP can help me a little bit more.

 

[DerekG]

Thank you for giving me nothing and not helping at all.

I hope OP can help me a little bit more.

This is a place where the assistance is provided on a voluntary basis, I have provided what advise I can, but I cannot help you with something I have no experience with.

I hope that you'll bear that in mind and adjust your attitude.

 

[cshifer12]

This is a place where the assistance is provided on a voluntary basis, I have provided what advise I can, but I cannot help you with something I have no experience with.

I hope that you'll bear that in mind and adjust your attitude.

So you do not have an experience in copying file and pasting text in here? Ok BYE.

I have not even asked you anything at all. I do not know why you even quoted me and help with nothing. I quoted OP not you.