Win10 VM graphics pass-through broke after AMD BIOS update

[boris]

10 hours ago, kilobit said:

Im wanting to completely upgrade my current setup for gpu passthrough and was wanting a ryzen 9 3900x  Can anyone tell me if there is any motherboard that works correctly with passthrough on this chip?

thanks

X370 Taichi + ryzen 3900x working fine for me. 

[kilobit]

11 hours ago, boris said:

X370 Taichi + ryzen 3900x working fine for me. 

Thank you for responding,  Im curious what gpus are you passing through and whats type of ram do you have?  I guess there would be no real benefits from me to get a 470/570.

[boris]

8 minutes ago, kilobit said:

Thank you for responding,  Im curious what gpus are you passing through and whats type of ram do you have?  I guess there would be no real benefits from me to get a 470/570.

I have a 1080 ti passed through and using trident z neo 3600 32gb as RAM.

[dodgypast]

The Gigabyte AX-370 has an updated BIOS that works as well.

https://www.gigabyte.com/us/Motherboard/GA-AX370-Gaming-5-rev-10/support#support-dl-bios

Edited December 28, 2019 by dodgypast

[juan11perez]

I want to share that I had a Ryzen 2700x on an Asus x470-F initially and I did have to downgrade the board bios to 4207 from Dec 2018 to be able to pass-through.

 

Before changing the cpu  to a 3900x, I upgraded to the latest bios 5406 Nov 25, 2019 and I was able to passthrough while still using the 2700x. Meaning that bios fixed whatever problem was preventing pass-through. I immediately swapped the cpu for the 3900x and it also worked without issue.

 

I have 2 cards and I can pass both cards (at the same time) without problem.

[klingon00]

On 12/26/2019 at 9:35 PM, kilobit said:

Im wanting to completely upgrade my current setup for gpu passthrough and was wanting a ryzen 9 3900x  Can anyone tell me if there is any motherboard that works correctly with passthrough on this chip?

thanks

My 3900x on ASUS Prime x470 Pro works with GPU passthrough just fine with Nvidia cards on the latest bios with 1.0.0.4b AGESA. 

 

I’m currently running 2 VMs simultaneously with passthrough on a GTX 1650 Super (top slot) and a GTX 950 (middle). I’m working on getting a third GT 710 working if I can resolve IOMMU grouping issues with the bottom PCIe slot going through the chipset. This seems to be on all AMD motherboards however with passthrough on the chipset.

 

Some AMD GPUs experience a reset bug where rebooting a VM puts them in an unusable state and the server must be rebooted to become usable again but Nvidia cards don’t seem to have this issue. In my case, my 570 card was working fine with a 1700x on the Asus x470 motherboard but when I upgraded the bios to support the 3900x, the 570 would no longer reset giving -127 errors, forcing me to switch to Nvidia.

[mattz]

Thanks for responding with the updates on the latest mobo BIOS tests, @klingon00, @boris, @juan11perez, @dodgypast, and others.  Sounds like the AGESA AMD BIOS version 1.0.0.4 Patch B (1004 B) is fixing this pass-through issues for folks across the board (pun intended) for x370 and x470 mobos!  So, after 9 months from this issue first popping up, AMD has solved it!  Better late than never...

 

Just a note: if you update to this latest BIOS from a working old BIOS your CPU pinnings and IOMMU groups will change, so you will have to update your UnRaid configurations.

[mojotaker]

With the latest bios for my board:

• Asus strix x470-F
• Bios: 5406 : Update AM4 combo PI 1.0.0.4 patch B
• Gpu: Asus strix gpu gtx 1070
• Processor: Ryzen 2700x
• Unraid: 6.80

Gpu passthrough not working, No error message. just blank screen.

Log:

-cpu host,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=none \
-drive file=/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/etc/libvirt/qemu/nvram/fc0e2c3c-8ea7-754a-298e-9c6867155fc6_VARS-pure-efi.fd,if=pflash,format=raw,unit=1 \
-m 4096 \
-overcommit mem-lock=off \
-smp 4,sockets=1,cores=4,threads=1 \
-uuid fc0e2c3c-8ea7-754a-298e-9c6867155fc6 \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=33,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=localtime \
-no-hpet \
-no-shutdown \
-boot strict=on \
-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x7.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x7 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x7.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x7.0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \
-drive 'file=/mnt/user/domains/Windows 10 Graphics Design/vdisk1.img,format=raw,if=none,id=drive-virtio-disk2,cache=writeback' \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk2,id=virtio-disk2,bootindex=1,write-cache=on \
-drive file=/mnt/user/isos/Windows.iso,format=raw,if=none,id=drive-ide0-0-0,readonly=on \
-device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 \
-drive file=/mnt/user/isos/virtio-win-0.1.160-1.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
-netdev tap,fd=36,id=hostnet0,vhost=on,vhostfd=37 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:35:ba:5b,bus=pci.0,addr=0x2 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=38,server,nowait \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-device vfio-pci,host=0000:0a:00.0,id=hostdev0,bus=pci.0,multifunction=on,addr=0x5,romfile=/mnt/user/domains/vbios/Asus.GTX1070.8192.160531.rom \
-device vfio-pci,host=0000:0a:00.1,id=hostdev1,bus=pci.0,addr=0x5.0x1 \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
2020-01-03 17:19:04.721+0000: Domain id=5 is tainted: high-privileges
2020-01-03 17:19:04.721+0000: Domain id=5 is tainted: host-cpu

New windows 10 vm.

Other info:

• Never downgraded the bios, cause i didn't need gpu pasthrough at the time.

Thank you.

 

Edited January 3, 2020 by mojotaker

[boris]

42 minutes ago, mojotaker said:

With the latest bios for my board:

• Asus strix x470-F
• Bios: 5406 : Update AM4 combo PI 1.0.0.4 patch B
• Gpu: Asus strix gpu gtx 1070
• Processor: Ryzen 2700x
• Unraid: 6.80

Gpu passthrough not working, No error message. just blank screen.

Log:

-cpu host,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=none \
-drive file=/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/etc/libvirt/qemu/nvram/fc0e2c3c-8ea7-754a-298e-9c6867155fc6_VARS-pure-efi.fd,if=pflash,format=raw,unit=1 \
-m 4096 \
-overcommit mem-lock=off \
-smp 4,sockets=1,cores=4,threads=1 \
-uuid fc0e2c3c-8ea7-754a-298e-9c6867155fc6 \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=33,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=localtime \
-no-hpet \
-no-shutdown \
-boot strict=on \
-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x7.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x7 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x7.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x7.0x2 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \
-drive 'file=/mnt/user/domains/Windows 10 Graphics Design/vdisk1.img,format=raw,if=none,id=drive-virtio-disk2,cache=writeback' \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk2,id=virtio-disk2,bootindex=1,write-cache=on \
-drive file=/mnt/user/isos/Windows.iso,format=raw,if=none,id=drive-ide0-0-0,readonly=on \
-device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 \
-drive file=/mnt/user/isos/virtio-win-0.1.160-1.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
-device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 \
-netdev tap,fd=36,id=hostnet0,vhost=on,vhostfd=37 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:35:ba:5b,bus=pci.0,addr=0x2 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=38,server,nowait \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-device vfio-pci,host=0000:0a:00.0,id=hostdev0,bus=pci.0,multifunction=on,addr=0x5,romfile=/mnt/user/domains/vbios/Asus.GTX1070.8192.160531.rom \
-device vfio-pci,host=0000:0a:00.1,id=hostdev1,bus=pci.0,addr=0x5.0x1 \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
2020-01-03 17:19:04.721+0000: Domain id=5 is tainted: high-privileges
2020-01-03 17:19:04.721+0000: Domain id=5 is tainted: host-cpu

New windows 10 vm.

Other info:

• Never downgraded the bios, cause i didn't need gpu pasthrough at the time.

Thank you.

 

Did you modify the GPU Bios with a HEX Editor?

[mattz]

30 minutes ago, boris said:

Did you modify the GPU Bios with a HEX Editor?

@mojotaker - Agree with @boris.  It sounds unrelated to the pass-through issues.  If this is the first time you are using the GPU for pass-through, you may need to double-check the Vbios is properly set up.  Use this as a reference: 

 

[mojotaker]

1 hour ago, boris said:

Did you modify the GPU Bios with a HEX Editor?

Hmm very weird, I responded to you, but i guess the post didnt got through.

 

Thank you all for your time.

 

Yes i did edit the bios with a hex editor. Lol thats the video i followed.

 

Im going to redo it again, and will post back.

 

Thanks again.

[mojotaker]

WOOOOOOOOOOOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

 

Thank you, thank you, thank you, thank you.

 

You were correct.

 

I redit the vbios modifications, and its working now.

 

Thank you again. 

 

4hrs wasted on that.

 

 

[A_Fat_Duck]

Can confirm passthrough works on the ASRock B450M Pro4 Mobo and 2700x with BIOS v3.90 (Update AMD AGESA Combo-AM4 1.0.0.4 Patch B) I just ignored the warnings about not upgrading to this version if I had a pinnacle ridge CPU and it seems to run fine so far?

 

I was originally having weird issues (On BIOS v3.50 which was the latest 'supported' version for my 2700x) where the bottom PCIE slot would passthrough a Win10 VM correctly with my single GTX770 but when in the primary PCIE slot I would get the D3 error until I did the v3.90 BIOS update.

[wbsmolen]

Was anyone hitting this bug with the x570 taichi board from asrock? I'm hitting similar symptoms. Before I start trial/error downgrading to various revisions, I'm hoping someone else knows which bios ver works

[mattz]

10 hours ago, wbsmolen said:

Was anyone hitting this bug with the x570 taichi board from asrock? I'm hitting similar symptoms. Before I start trial/error downgrading to various revisions, I'm hoping someone else knows which bios ver works

There were some x570's that had the issue... can't remember which ones.

 

However, you should be good with any BIOS after November 2019.  Anything this version or later:  AGESA AMD BIOS version 1.0.0.4 Patch B (1004 B) fixes

[wbsmolen]

On 3/26/2020 at 11:37 PM, mattz said:

There were some x570's that had the issue... can't remember which ones.

 

However, you should be good with any BIOS after November 2019.  Anything this version or later:  AGESA AMD BIOS version 1.0.0.4 Patch B (1004 B) fixes

then my "power state d3" failures aren't related to bios. I'm up to date there 

[mattz]

22 minutes ago, wbsmolen said:

then my "power state d3" failures aren't related to bios. I'm up to date there 

@wbsmolen - I agree- I think it is unrelated to this particular BIOS issue.  I found this post about an x570 earlier in this thread to confirm it's probably not this issue, but it also may be related to your problem... ?  Good luck.

On 8/18/2019 at 7:52 PM, Leoyzen said:

Yes, I'm using 3700x and MSI X570 ACE with AGESA 1.0.0.3AB BIOS( which is the newest, MSI did not update 1.0.0.3AB for my board），and passthrough GPU works fine for me (I dont have meet the situation which the thread describe. I'm using RTX2070 for a Win 10/Ubuntu and RX560 for Win10/Hackintosh).

 

I'm fighting with some other problems the Zen 2 platform have, such as :

1. when restarting or hibrating the vm, the vm enter pause state and cant be resume anymore, I must force stop the vm and start again to make it work

 

 

[wbsmolen]

On 3/28/2020 at 4:21 PM, mattz said:

@wbsmolen - I agree- I think it is unrelated to this particular BIOS issue.  I found this post about an x570 earlier in this thread to confirm it's probably not this issue, but it also may be related to your problem... ?  Good luck.

 

Appreciate it, sincerely. That sounds like the standard AMD reset but that can be fixed via kernel path or user scripts. I’m hitting something that may be specific to my board

[killeriq]

Hi guys,

I've switched today from Ryzen 1700 to 3700x (on Asus Crosshair VI Hero, latest bios 7704) and soon as i enable SVM , system is freezing after booting or keyboard via USB-C monitor hub is randomly not being detected.
I have F4-3200C14D-32GTZ (G.Skill Trident Z 2x16GB DDR4 3200MHz CL14, DIMM, 1.35V) set on 3200Mhz over DOCP, but even if i leave all on default 2133Mhz still the same result 

Without touching SVM (Virtualization) is all working fine seems like, but without this option Enabled im not able to run VMs via Unraid OS 

With ryzen 1700, was all fine.

 

EDIT:

Just tried 

1.

SVM - Enable

IOMMU - Disable

it Works

 

2.

SVM - Disable

IOMMU - Enable

it works

 

3.

SVM - Enable

IOMMU - Enable

it doesnt work

Any clue what to do? Thanks

Edited April 23, 2020 by killeriq
update

[killeriq]

upgraded to unraid 6.9.0 beta 1

I was able to boot up with 

SVM - Enable

IOMMU - Enable

 

1. But VM on OS was disabled, soon as i enabled it and checked log, getting this and then is freeze whole OS and need to manually reboot

 

Apr 23 23:02:22 unRAIDTower kernel: vfio-pci 0000:0c:00.0: not ready 1023ms after FLR; waiting
Apr 23 23:02:24 unRAIDTower kernel: vfio-pci 0000:0c:00.0: not ready 2047ms after FLR; waiting
Apr 23 23:02:27 unRAIDTower kernel: vfio-pci 0000:0c:00.0: not ready 4095ms after FLR; waiting
Apr 23 23:02:32 unRAIDTower kernel: vfio-pci 0000:0c:00.0: not ready 8191ms after FLR; waiting
Apr 23 23:02:41 unRAIDTower kernel: vfio-pci 0000:0c:00.0: not ready 16383ms after FLR; waiting
Apr 23 23:02:59 unRAIDTower kernel: vfio-pci 0000:0c:00.0: not ready 32767ms after FLR; waiting
Apr 23 23:03:34 unRAIDTower kernel: vfio-pci 0000:0c:00.0: not ready 65535ms after FLR; giving up
Apr 23 23:03:34 unRAIDTower kernel: clocksource: timekeeping watchdog on CPU1: Marking clocksource 'tsc' as unstable because the skew is too large:
Apr 23 23:03:34 unRAIDTower kernel: clocksource: 'hpet' wd_now: a9d6f73e wd_last: a80c745e mask: ffffffff
Apr 23 23:03:34 unRAIDTower kernel: clocksource: 'tsc' cs_now: 1c4ec8e5fec cs_last: 1c40186b0f8 mask: ffffffffffffffff
Apr 23 23:03:34 unRAIDTower kernel: tsc: Marking TSC unstable due to clocksource watchdog
Apr 23 23:03:34 unRAIDTower kernel: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
Apr 23 23:03:34 unRAIDTower kernel: sched_clock: Marking unstable (498609729347, -14912016)<-(498630463494, -35648793)
Apr 23 23:03:37 unRAIDTower kernel: clocksource: Switched to clocksource hpet
Apr 23 23:04:50 unRAIDTower kernel: rcu: INFO: rcu_sched detected stalls on CPUs/tasks:

 

2. Also this seems new in VM machine Setup

Any clue what is it for? per MAC address is the same device which is system waiting for

When i opened VM setup didn't uncheck it, getting this msg

 

3. over here i discovered this setting which help unraid to not completely freeze with SVM/IOMMU enabled

 

So like

label unRAID OS
  menu default
  kernel /bzimage
  append initrd=/bzroot

would become

label unRAID OS
  menu default
  kernel /bzimage
  append initrd=/bzroot clocksource=hpet

 

 

4. After unticking AMD Starship i was able to run VM and got floaded with this, but Server didnt freeze (luckily)

 

23:51:04 unRAIDTower kernel: vfio-pci 0000:0b:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
Apr 23 23:51:04 unRAIDTower kernel: br0: port 2(vnet0) entered blocking state
Apr 23 23:51:04 unRAIDTower kernel: br0: port 2(vnet0) entered disabled state
Apr 23 23:51:04 unRAIDTower kernel: device vnet0 entered promiscuous mode
Apr 23 23:51:04 unRAIDTower kernel: br0: port 2(vnet0) entered blocking state
Apr 23 23:51:04 unRAIDTower kernel: br0: port 2(vnet0) entered forwarding state
Apr 23 23:51:05 unRAIDTower kernel: vfio-pci 0000:0b:00.0: vfio_ecap_init: hiding ecap 0x19@0x900
Apr 23 23:51:05 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:05 unRAIDTower kernel: vfio-pci 0000:0b:00.0: No more image in the PCI ROM
Apr 23 23:51:05 unRAIDTower avahi-daemon[8306]: Joining mDNS multicast group on interface vnet0.IPv6 with address fe80::fc54:ff:fef2:6195.
Apr 23 23:51:05 unRAIDTower avahi-daemon[8306]: New relevant interface vnet0.IPv6 for mDNS.
Apr 23 23:51:05 unRAIDTower avahi-daemon[8306]: Registering new address record for fe80::fc54:ff:XXXX on vnet0.*.
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]
Apr 23 23:51:24 unRAIDTower kernel: vfio-pci 0000:0b:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff 64bit pref]

whole OS become laggy and i need to reboot

Edited April 23, 2020 by killeriq

[bugsysiegals]

I've a Asus ROG Strix B450 with 2600X CPU.  It's new and I've just added Nvidia 1650 Super.  I was unable to do GPU passthrough and was receiving D3 errors.  I've got Code 43 issue and TV flickering on and off but the Windows VM will at least boot now after updating the BIOS to version 3003 which includes 1.0.0.4 patch B.

 

FWIW - I used to have IOMMU in the BIOS but can no longer find it...

Edited April 25, 2020 by bugsysiegals

[J89eu]

A lot of these issues seem like what I have been facing on these 2 threads:

 

I don't even know where to go next but seems I am not alone...

[killeriq]

@J89eu : reading your post - seems like u have similar issues like i did few days ago when i switch from Ryzen 1700 to Ryzen 3700x

First i was also suspecting RAM , bios settings etc. I did many things and not sure what really fix it but i assume as i moved to 6.9.0 beta 1 it upgraded kernel and fix it somehow.

And ive also tried this : 

As i was getting the same error, added it into the Start menu...later i removed it.

 

Try also play with (if u have such setting in Bios)

SVM - Enable/Disable

IOMMU - Enable/Disable

 

how it behaves

 

[J89eu]

Tg

On 4/30/2020 at 1:55 PM, killeriq said:

@J89eu : reading your post - seems like u have similar issues like i did few days ago when i switch from Ryzen 1700 to Ryzen 3700x

First i was also suspecting RAM , bios settings etc. I did many things and not sure what really fix it but i assume as i moved to 6.9.0 beta 1 it upgraded kernel and fix it somehow.

And ive also tried this : 

As i was getting the same error, added it into the Start menu...later i removed it.

 

Try also play with (if u have such setting in Bios)

SVM - Enable/Disable

IOMMU - Enable/Disable

 

how it behaves

 

Tried all those... SVM disabled stops any VM from working at all, IOMMU beeing enabled or disabled didn't seem to change anything!

[mattz]

On 4/23/2020 at 1:00 PM, killeriq said:

Hi guys,

I've switched today from Ryzen 1700 to 3700x (on Asus Crosshair VI Hero, latest bios 7704) and soon as i enable SVM , system is freezing after booting or keyboard via USB-C monitor hub is randomly not being detected.

Without touching SVM (Virtualization) is all working fine seems like, but without this option Enabled im not able to run VMs via Unraid OS 

 

@killeriq- I think I'm in the same boat now.  I just upgraded my x470 board to the Ryzen 3900x from the 2700x (wanted the cores!).  However, I am no longer able to pass through my motherboard's USB Controller 3.0 the same way I did with the 2700x.  I now get the same error you had and the whole system will lock up, requiring a hard reboot:

 

kernel: vfio-pci 0000:0c:00.0: not ready 1023ms after FLR; waiting

It is something others are encountering--the only way to fix it is to avoid passing through that particular USB controller, and use other USB Controllers, if you can: 

There is also a Kernel patch, it appears, that could fix it.  So, I am not sure, does the latest Unraid BIOS fix it for you?  It could be the kernel patch made it in... 

 

 

Edited June 3, 2020 by mattz
added descriptions