ghost82

In order, in my opinion, and only if there are conflicts: - gpu video and gpu audio - nvme/sata controllers (take care with this, in some cases enabling msi on these may result in unbootable systems) - network - usb

Try to uncheck all, reboot, look at how devices are arranged about irq, check if you still have spikes, enable msi for conflicting devices (if any) or post the new screenshot.

Is this a completely new install?And it's this one that has 15-20% spikes on cpu with fast mouse movements? It seems strange because usually msi is not enabled by default. There's no irq sharing here, but the issue could be related with msi. Where is your mouse attached?You could try to uncheck msi for the usb controller to which your mouse is attached. It works like this: in the irq column if you read a number with the minus in front of it, it is using msi. in the irq column if you read a positive number it is using irq and the interrupt priority column applies. in the irq column if you read positive numbers, and you have the same positive numbers for different devices, then there's an irq conflict: depending on devices you can enable msi to avoid conflicts. linebased means irq, msi/msix means msi compatible (msix being a "more recent version" of msi) Usually it is not recommended to enable msi for all the devices.

Nice that you got it working. Linux is not bug free, without debugging the issue in details it's not possible to know what happened, maybe the driver, maybe the kernel, maybe the firmware, who knows..sometimes "old" is better then "new". Reading more about this, firmware named a0-xx are not the same firmware for the same device(s), that's why you got an error when you renamed a0-68 to a0-66 and try to force load it: ax200 should load the a0-46; it's iwlwifi driver that should look for the a0-46 firmware, but it is looking for other firmwares, in my opinion the issue is with iwlwifi driver, not with the firmware, or with the kernel which is misdetecting the wifi card and tells to iwlwifi to load a wrong firmware. In particular this current kernel is looking for firmware a0-66 going down till a0-39: [ 5.807892] iwlwifi 0000:04:00.0: minimum version required: iwlwifi-cc-a0-39 [ 5.807894] iwlwifi 0000:04:00.0: maximum version supported: iwlwifi-cc-a0-66 For the kernel that wifi card can be used with that range of firmwares. If you delete all iwlwifi-cc-a0-XX.ucode in your /lib/firmware/ and put only iwlwifi-cc-a0-46.ucode (without renaming it), the kernel should start looking for a0-66 going down till it finds a file in the range a0-66 --> a0-39. And I'm quite sure it will load the correct a0-46, because it's in the range of allowed firmwares and it's the only one available in /lib/firmware/. If I were you, I would go this way, delete all, and put only a0-46. If you stick with the "firmware renamed solution", remember that if you update the linux-firmware package (if you have it installed), your renamed firmware could be overwritten (replaced with the real a0-66) and your wifi won't work again, if it will be the case, just repeat the steps you did. Devices like this have the firmware loaded in the device ram during boot, if a wrong firmware is wrongly loaded you may need to power cycle it to be able to load another firmware on it.

First try to fix the mouse: can you attach without enabling msi a screenshot of the msi util?

In real I think it's not an issue with the passthrough, but with the driver. Tomorrow I will have a better look at that log and think something.

In latest diagnostics no gpus is attached to vfio at boot and you have nvidia plugin installed in unraid which is attaching to them. Try to attach gpu to vfio at boot to properly isolate them.

I don't know how this thing works, but from your dmesg: [ 5.236686] iwlwifi 0000:04:00.0: firmware: failed to load iwlwifi-cc-a0-66.ucode (-2) [ 5.236693] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware [ 5.236695] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-cc-a0-66.ucode failed with error -2 [ 5.242185] iwlwifi 0000:04:00.0: firmware: failed to load iwlwifi-cc-a0-65.ucode (-2) [ 5.242193] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-cc-a0-65.ucode failed with error -2 [ 5.242228] iwlwifi 0000:04:00.0: firmware: failed to load iwlwifi-cc-a0-64.ucode (-2) [ 5.242229] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-cc-a0-64.ucode failed with error -2 [ 5.264416] iwlwifi 0000:04:00.0: firmware: direct-loading firmware iwlwifi-cc-a0-63.ucode it seems it tries to load higher version numbers , starting from 66, 65, 64: since they are not in the folder it cannot load them, then it searches for 63 and it loads it. If you replace the 46 it doesn't change anything because the same 63 is loaded. Put the 68 in that folder and see if it gets detected, if the same 63 is loaded you can try to delete 66, and rename that 68 to 66 and check if it loads. <-- Nonsense, a0-68 firmware is for different devices

Please keep calm JhonScript To avoid issue download the attachment, unzip it and put it in /lib/firmware/ Check dmesg and see if this a0-68 firmware is loaded or not. <-- Nonsense, the firmware is for different devices iwlwifi-cc-a0-68.ucode.zip

ok, good that you found how to fix the xml. Now that the xml is set correctly can you attach a new diagnostics file, so we can see if there's something useful in it to track the issue?

Not many ideas left.... I see that the newest version of the firmware you have in /lib/firmware/ is a0-63. If I'm not wrong the latest available version should be a0-68. <-- Wrong, they are completely different firmwares, not updates. Maybe the issue is a faulty firmware. Try to clone the linux-firmware repo and copy iwlwifi-cc-a0-68.ucode into /lib/firmware, then try to load it instead of a0-63. <-- Non sense. the firmware is for a different device.

I have no doubts you have good intentions to fix it However I cannot be of more help if buses are not fixed, because I don't know what to do in addition to give you the settings to set the gpu as multifunction Have no idea why these settings aren't applied..

I don't think it's an issue with lacking of drivers, because iwlwifi is loaded and attached to the card. It's an issue with the initialization, something like if the card is an in undefined state that couldn't be initialized by iwlwifi driver.

That's really strange Shutdown your pc. Boot to your pc bios (not the vm bios), disable fast boot if it's enabled and apply changes, shutdown. Unplug power chord and wait 2-3 minutes. Boot unraid and run the linux vm, do not start any windows vm before. See if you get wifi.

I'm asking this because booting another os can leave some devices in an undefined state and the driver will be unable to properly initialize the device. I have an example in my build for my wifi usb adapter: I have 3 vms, mac os, windows 11 and kali. If I boot into kali after booting mac os wifi is not detected; I need to boot into windows, then boot into kali to have the wifi detected. Mac os leaves that wifi in an undefined state that the linux driver is unable to reinitialize. On the contrary, windows (with fast boot disabled) leaves the wifi in a state such that the linux driver knows what to do. -- If you are dual booting with windows, check to disable fast boot/fast startup in windows, disable fast boot also in the bios. If it's not disabled it may cause unexpected behaviors as described.

Check this video: worrying voice but should help

I would say the setup on the host is correct and it's the best possible with the usb controller passthrough. For some reasons iwlwifi is failing to init the card. Are you dual booting unraid with windows?

Once you move the unraid pendrive to a different usb controller you can share you diagnostics file to get more help on setting it. However, once you attach that usb controller to vfio (the one to which the bluetooth is attached) you should see it under or above the wifi 6 device, just put a check on it to pass it through (obviously you wont find any usb device in the "USB devices" that are attached to that controller, because all that devices will be automatically be in the vm): By "attaching to vfio at boot" I mean put a check for iommu group 16 (now it's greyed out because it can't be passed through, but it will become available once you move the unraid pendrive to a different controller) Note that you have other devices attached to that controller, so move them too if you need them in the host.

Not so expert, but I cannot find from your screenshot what usb port belongs to which usb controller. From this screenshot: you can clearly see that both 8087:0029 (bluetooth) and the kingston datatraveler (unraid) are connected to the same controller at 07:00.0. If you have a spare usb pendrive attach it to different ports and see to which usb controller it attaches; once you find that it attaches to a different controller, move the unraid pendrive to that port, boot, remove the bluetooth device passthrough, attach to vfio at boot the usb controller to which the bluetooth is attached and passthrough in your vm the entire usb controller.

Because you run it in a non sudo environment, unraid runs as sudo.

Not sure I understand correctly...but it's perfectly fine: if you run lspci command in unraid you will see that the host (unraid) binds the pcie device to the vfio-driver and you see the source address at 57:00.0 (bus 57, slot 0, function 0), if you run lspci command in the vm you will see that the guest (your vm) binds the pcie device to the wifi driver and you see the target address at 03:00.0 (bus 3, slot 0, function 0), since you have this in your xml: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x57' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </hostdev> Since you have several usb controllers, I would try to attach the unraid pendrive to another port, belonging to another usb controller (different from that to which the bluetooth is attached), and passthrough to the vm the usb controller to which the bluetooth is attached, instead of passing through the single usb device (bluetooth).

Hope it helps in some way.. firmware: direct-loading firmware iwlwifi-cc-a0-63.ucode This means that a0-66, 65 and 64 failed to load but a0-63 is successfully loaded, and you can see in your latest screenshot the iwlwifi driver attached to it. My thought is that since it's a composite device (wifi+bluetooth) you need to passthrough also the bluetooth part: this can be tricky, since the bluetooth is attached to usb. Best option is to passthrough to the vm the wifi+the entire usb controller (not the single device) to which bluetooth is attached; however it seems you attached the bluetooth to the same controller where you have the unraid usb pendrive, so it cannot be passed through... Also follow SimonF link to prevent unraid from using the bluetooth.

Not of much help, but from what I'm reading it's not an issue with the compilation of libvirt, optional storage backends where separated from libvirt back in the past (2018?). You should need the additional package libvirt-daemon-driver-storage-zfs installed into unraid.

Sorry but something is wrong, either you are not applying my advices or for whatever reason your changes aren't applied, you can't have with the changes applied in the vm components of the gpu in different buses.

Windows 11 vm, multifunction is not applied correctly, replace this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </hostdev> with this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> </hostdev> Other things to consider (in order): - consider to setup the vm with vnc, enable remote desktop INSIDE the vm, switch from vnc to gpu passthrough, connect to the vm remotely with remote desktop to see if your gpus are detected, detected with errors, or not detected; maybe you only need to install nvidia drivers (download and install latest version) - you may need to pass also vbioses for your gpus (dump your own) - you may consider to switch from i440fx/ovmf to q35/ovmf for better support for passthrough - sometimes, in some builds, passing through the nvme controller doesn't play well together with passing through the gpu(s)