Attention: FLR Kernel Patch fixes USB/Audio passthrough issues on AGESA 1.0.0.4B

Many of you still don’t know about this patch since the discussion on it got buried last year. With this patch you can now safely upgrade to Ryzen 3000 and the latest AGESA 1.0.0.4 Patch B and get USB and Realtek Audio passthrough working again.

1004_FLR.mypatch.zip (512 Bytes)
The easiest way to use the patch if running arch is to run TKG’s build script. Just throw the attached .mypatch file into the same linux54-tkg folder as the script and run it. Make sure to select ‘Y’ when it asks about the patch.


Then I also recommend selecting PDS scheduler NO MATTER WHAT YOU DO ON YOUR PC.

Note that you may not need to patch the kernel, it might be enough to simply add the following to the boot parameters:

pcie_no_flr=1022:149c,1022:1487

Description of problem: https://www.reddit.com/r/VFIO/comments/eba5mh/workaround_patch_for_passing_through_usb_and/

I have confirmed on even my old X370 Pro Gaming board that I can pass through realtek audio perfectly as soon I applied the patch and the flr parameter using grub customizer. I didn’t yet test the USB passthrough although USB passthrough works fine on AGESA 1.0.0.4 Patch B without needing this patch. (you can pass through the other usb controller listed just fine)

So technically I think we now have better IOMMU with more passthrough options with AGESA Combo 1.0.0.4 Patch B then even before with the older AGESA PI 1.0.0.6 from last year. I am able to also pass through for example the Aquantia 5G network card, and possibly some other devices that I couldn’t pass through before. So putting all of this together you should be able to passthrough 2 different USB controllers to 2 different VMs even on older x370 mobos. Then we have more cores and per CCX OC now also to play with. :slight_smile:

3 Likes

hopefully Gigabyte will bring their to older x399 boards… last bios release was like 2018?

This is extremely important, as Windows DCH drivers will mean the Renesas USB controllers will stop working in new Windows 10 builds soon.

Source? I know DCH is the new thing in windows drivers, but I have heard zero about removal or deprecation of normal drivers.

In newer Windows builds, they will one by one start removing legacy hardware support with the built in WDDM drivers and force you to DCH to get the latest version of those drivers. I heard it on r/VFIO.

Is there an equivalent fix for ESXi?

I’m seeing some oddities on ESXi 6.7u on Threadripper and wonder if it is related. USB passthru just simply won’t work and audio via the monitor that GPU passthru is on is extremely choppy.

Ok, so no source, just an unsubstantiated rumor.

Well, considering M$ crippled DX9 from 1803 onwards, I don’t doubt they’re gonna remove legacy supports once the build numbers reach the 2000s.

DirectX version support and driver type support are unrelated. Even if MS broke DX9, that means nothing for older drivers.

What I did hear from r/VFIO is that Renesas controller drivers (been in the Windows install since Windows 8) may not get DCH drivers and would be deprecated if legacy drivers are no longer in the base Windows install. Where the confusion in that lies is will they continue to allow legacy drivers? I have no doubts DCH will be the only option on Windows 10 S, but I’m cautiously optimistic the full version of 10 will forever allow legacy drivers and DCH to coexist.

For those who don’t want to download a zip file and just copy + paste your own quick .patch

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 35d0d638d..3555ccf1c 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5095,6 +5095,10 @@ static void quirk_intel_no_flr(struct pci_dev *dev)
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_intel_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_intel_no_flr);
 
+/* FLR causes Ryzen 3000s built-in HD Audio & USB Controllers to hang on VFIO passthrough */
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x149c, quirk_intel_no_flr);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1487, quirk_intel_no_flr);
+
 static void quirk_no_ext_tags(struct pci_dev *pdev)
 {
        struct pci_host_bridge *bridge = pci_find_host_bridge(pdev->bus);

Wendel should reconfigure the forum so we can attach .patch files and .mypatch files to posts. Would save some time. That is the only reason I posted zip, to save the trouble of having to open the text editor and create file manually. But being forced to use zip on forum kinda ruins that.

1 Like

Patch should work?

Tag your devices for passthrough in the GUI, go to CLI, and edit /etc/vmware/passthru.map. Add the lines for each device by vendorid productid d3d0 false. Example: 1022 149c d3d0 false for the USB ports available for passthrough on at least my x470 Taichi Ultimate with 3700x. Reboot once applied and you should be good