Thank you all for your input.
After much testing back and forth, eight Windows installs etc. This is
what I've found:
Deleting <vmport state='off' /> via "sudo virsh edit my_machine" fixes
random reboots which start appearing as soon as I pass my R9 290 GPU
through.
It also makes Win 10 list my passed through GPU as "AMD Radeon R9 200
series" instead of "Microsoft Basic Display Adapter", which in turn
makes higher resolutions available.
I am able to install AMD's driver version 14.12
(amd-catalyst-omega-14.12-with-dotnet45-win7-64bit.exe), but the newer
Crimson drivers cause reboots.
Also a lot of my initial headaches might have come from the lack of host
reboots. Power the Win10 guest on/off a sufficient number of times,
suspend the host etc. and things stop working before the host reboots.
Is this something to with power management of the vfio-pci claimed gpu?
Dos deleting <vmport state='off' /> make sense? It should result in
<vmport state='on' /> which is the default. This vmport is some VMware
IO port as far as I understand. Why do I need this turned on (i.e.
remove the directive which turns it off)?
Thank you for all your inputs
/ Jonas
P.S. Had a game of Rocket League (without sound, not yet confired) with
mouse and keyboard provided by Synergy. Worked like a dream.
On 04/19/2016 08:22 AM, Quentin Deldycke wrote:
What do you mean by : "I have a start up script that sorts out the
registers and means I almost never have to hard reset".
Can we have a peak at it :) ? I have sometimes bsod at boot (when the
windows desktop loads, all time i need to go to safe mode, uninstall,
reboot, reinstal)
--
Deldycke Quentin
On 18 April 2016 at 15:40, Bob Dawes <xochipil...@yahoo.com
<mailto:xochipil...@yahoo.com>> wrote:
This guy has got it exactly. Could hardly do any reboot related
task without at least one bsod until I used an ioh3420 root port
and both functions of the card together under the root port.
In the end I tracked it down to the registers and the root port
having different link description registers after some reboots.
Since they share the same physical link this could have
unpredictable results plus I even caught the windows drivers
making direct accesses to the root port registers during link
setup. You are stuck with certain config parameters defined by the
fake root port but they aren't important assuming your card can
handle a minimal link payload.
I have a start up script that sorts out the registers and means I
almost never have to hard reset, but suggest you try a simple set
up first as it's not great practice to setpci your registers. The
other thing I can recommend if you are having problems is to force
all your pcie cards to have safe MaxPayload parameters by adding
pci=pcie_bus_peer2peer to your kernel command line - as making
those vary between root / both card functions is a guaranteed qemu
boot BSOD for me. The problem we're having tends to emerge because
the cards can't be fully reset and so tend to go out of line.
Keeping them together in the client etc. really helps as does
having minimal non-agressive parameters for things such as MaxPayload.
For the avoidance of doubt - I can do whatever the hell I want and
it still works. I can even boot with fglrx and then rebind to
vfio. I have to bind the root port to pci-stub if I put ASPM on
the root port as the linux drivers start messing with stuff - but
even that is manageable.
It's a bit different with PCI-e2 boards vs the 100 series board I
have, but I suspect the principles hold regardless. Good luck!
On 18/04/16 01:47, Stewart Adam wrote:
I faced similar issues with my R270, in my case *entirely
removing* the vmport=off option (its presence alone caused
issues) and attaching the GPU to a ioh3420 device instead of
directly to the PCI bus fixed the issue:
https://www.redhat.com/archives/vfio-users/2015-December/msg00211.html
Like many of you mention, I tried several versions from both
Catalyst and Crimson and all failed without those two elements
in my configuration. Without them, I experienced all sorts of
hangs and BSODs on driver installation or boot-up. It's worked
flawlessly, even after several guest reboots, since adding them.
This thread from January is also be relevant:
https://www.redhat.com/archives/vfio-users/2016-January/msg00191.html
Regards,
Stewart
On 2016-04-17 6:15 PM, Ryan Flagler wrote:
I ran an R9 280 with only the reboot issue. I believe the
most important settings for me were using the i440fx
chipset and the uefi bios.
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com <mailto:vfio-users@redhat.com>
https://www.redhat.com/mailman/listinfo/vfio-users
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
