Don’t know if you saw my edit, setting up mountpoints did the trick, thank you for all your help
1 Like
Ah, yes I did. Glad to hear it’s all set up.
Just so you know, some rx 480’s suffer from the bus reset issue, according to forum results. If you have issues, there’s a workaround thread somewhere. I’ll see if I can find it.
1 Like
Bus reset issue being that I have to shut down the whole system before I can start up the VM again?
I remember having that problem on my old passthroughs, was really annyoing
I’d appreciate it!
1 Like
Yep. I’m having trouble finding it, but the gist of it is you configure a scheduled task to disable the GPU device on OS shutdown and re-enable the GPU device on OS startup.
You should absolutely enable RDP while you’re testing this because you don’t want to get stuck with the GPU disabled.
That goes beyond my knowledge, I’ll go digging aswell^^
What’s RDP and where do I enable it?
1 Like
Remote Desktop Protocol. This article should help you with enabling it.
The Linux client I use is Remmina. It’s available in Fedora repos as remmina-gtk
.
Yeah, if I knew how to do it, I’d just tell you, but I’m definitely not a windows guy. I can barely remember how to change a password on Windows.
2 Likes
How would the RDP help me? I don’t quite understand that part yet
Also, I found the thread
I noticed in Wendell’s recent GPU pass-through live stream, that he mentioned that there isn’t a reliable solution for the AMD GPU reinitialization problem. He mentioned that once a Windows guest VM on linux is shut down, the AMD GPU will refuse to reinitialize, and that this requires a reboot of the Host machine to fix.
In my personal experience, this actually seemed to be rather random. Sometimes the VM would be able to boot back up, sometimes not. I found that it was not actually the shut down of the VM, but if the host machine enters a sleep state, while the VM was shut down, after having run at least once.
The root issue I suspect has less to do with how Linux is treating the GPU, but the behaviour of the Windows OS while it is a guest. Mainly the Windows guest OS is not sending a signal to the GPU to shut-down or start up while it is running in a VM. I assume this is because when on bare-metal, when a Windows OS shuts down, power is actually killed to the GPU from the motherboard/PSU but when in a guest VM, this does not happen, leaving the GPU in an initialized state. Then if/when the host machine enters a low power state, and power is significantly reduced to the GPU, it enters a non-responsive state after the host machine wakes up.
Anyway, I found a fix/work-around. I’ve borrowed bits from around the web for this. I don’t write how-to’s often, so bare with me.
(note, all these steps take place inside the Windows Guest OS)
Step 1
We are going to need the Windows Device Console (DevCon)
It is included bundled with the Windows Driver Kit , which you can download and install like a chump, but you don’t require all the added bloat.
So, instead download and install Chocolatey , so you can install it from terminal like a bad-ass. Follow the instructions on the Chocolatey website to install.
Once Chocolatey is installed open a Windows command prompt and run this command to install DevCon:
choco install devcon.portable
DevCon is rather straight fo…
1 Like
That’s the thread!
If you get the system stuck with the GPU disabled, you can RDP in (it creates a virtual display) and manually enable the GPU.
1 Like
I see, thank you! First I gotta get the VM set up though, so I’ll get to it^^
1 Like