VM hangs and host freezes when passing audio controller

I’ve created a windows 10 vm and got gpu passthrough working just fine on ubuntu 20.04. For some reason I couldn’t get audio to work so I decided that the easiest solution is to just sacrifice the host’s audio and pass the motherboard’s audio controller to the vm.
Now when the vm doesn’t have the pci device everything works fine but with it, when I start the vm I lose control of my mouse as expected but the virtual machine manager never says that it started and then the host will start to lag and after about a minute it completely freezes.
I’ve made sure that it’s using the vfio driver and it’s in its own IOMMU group and all other audio is completely disabled. I’ve also checked the log for the vm and there are no errors or anything weird.
Any idea what’s going on?

linked below is the xml
https://ybin.me/p/219a1b73846cbf44#84BmrthkWvVHxZlscwVliCkBRYGmKKFN2fy7sT40Y3Y=

memory unit=“KiB” 25165824

25gb! This caught my eye. Are you sure you have enough memory to run both win10 and linux host?

I was able to get audio working with HDA (ich6). No microphone tho - that was nigh impossible I just ran discord inside linux.

Could you also post your iommu groups?

it’s all by itself in group 31
https://ybin.me/p/8a39dfc5d23bdb1c#LhA6G8glWuih7VueiXVFWotGGf99JrwhYOv+zuKZm0g=
and 8gb should be plenty for ubuntu with barely anything running

Yes It is. And true 8gb is enough, was not aware you had 32gb’s of ram :stuck_out_tongue:

I’m stumped, hopefully someone can help.
You could try passing through a usb-soundcard or a usb-dac. Or try to fiddle with the audio settings again inside virtual machine manager. As I said I was able to get sound working with the ich6 -option. Make sure your vm is not muted inside pulseaudio.

Welcome to the forums.

This sounds like the FLR bug with certain components on X470 and X570 motherboards. Specifically, the USB controller (1022:149c) and audio device (1022:1487) advertise function level reset capabilities, but end up bringing down the system when issued a reset command. So you’ll see this kind of thing in your syslog (tip: ssh in from another machine, start watching the logs, then start your VM)

  xhci_hcd 0000:10:00.3: not ready 1023ms after FLR; waiting
  xhci_hcd 0000:10:00.3: not ready 2047ms after FLR; waiting
  xhci_hcd 0000:10:00.3: not ready 4095ms after FLR; waiting
  xhci_hcd 0000:10:00.3: not ready 8191ms after FLR; waiting
  xhci_hcd 0000:10:00.3: not ready 16383ms after FLR; waiting
  xhci_hcd 0000:10:00.3: not ready 32767ms after FLR; waiting
  xhci_hcd 0000:10:00.3: not ready 65535ms after FLR; giving up

The good news: a formal fix has been implemented in the linux mainline.

The bad news: the fix will land in 5.8, so probably not in a kernel you’re using, or will be able to use any time soon.

If you’re running a supported version of Ubuntu (19.10, 20.04), the fix has been backported and will likely be generally available in the next SRU patch cycle (a few days time). Otherwise open a support issue with your distribution, or patch and comple your own kernel.