ghost82

Members
  • Posts

    2721
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by ghost82

  1. Looking at the qemu bugtracker, it seems confirmed there too; the alias is there, it's not stripped, the issue is with the -set and json format. https://gitlab.com/qemu-project/qemu/-/issues/787 Also here: https://gitlab.com/libvirt/libvirt/-/issues/287 There is a patch too, but it hasn't been merged. Not sure, how to eventually modify qemu.conf to add capability_filters; the only option could be to extract the unraid bzroot file, "patch" it, and recompress it, to have a persistent solution after a reboot. Moreover it's not clear if this is working or not. ...and: For rotation_rate I think you can actually add it to the libvirt xml without using the custom qemu arg (from libvirt 7.3.0, 6.10 RC3 should have >=7.8.0), something like this, in the target line of the disk section: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='path/to/vdisk.img'/> <target dev='hdc' bus='sata' rotation_rate='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> For x-msix-relocation the only option should be that described in the next post
  2. Can you please check in your diagnostics file, after setting a vm with aliases in unraid (don't bother if they are stripped or not) and run it then stop it: 1. Extract diagnostics zip and go to qemu/VMName.txt 2. Open VMName.txt and check if the aliases are there: for example for 'sata0-0-1' alias, you should have this in the device line: id=sata0-0-1 Libvirt aliases translate to ids in qemu. If they are not there too, as a temporary workaround you could run the vm directly from the command line, adding all the ids you need, calling directly the qemu binary.
  3. I asked because there is no error in the log you attached. Try to attach diagnostics, after trying to run the problematic vm.
  4. Ok, open a bug in the appropriate forum section.
  5. Not your fault for sure, even with a translator I'm missing the meaning, even if explained ahah, but all I need to know it's that it was sarcasm Did you try with the virsh edit command? It can be a bug in the gui stripping the aliases.
  6. It's better to reserve some cpu power for unraid, core 0 at least, or core 0 + its hyperthreaded core. However I run for several months some vms with all the core assigned, and even at 100% power in vm without issues, now it runs with some dedicated cores. This really depends on what the host is doing when you have the vm running. You should try directly and see what fits your purposes, worst thing can happen is that unraid locks.
  7. Hi Simon, never had a igpu, so not expert, however that line refers to the header of the rom; kernel is expecting the header 0xaa55, but it finds 0xfc44 instead. Are you passing a vbios? If so, first thing to check is the vbios file: open it with a hex editor and check the first 2 bytes: does it start with "55 AA" (0xaa55 is aa55 in little-endian)? If it doesn't start with 55 AA the vbios could not have been dumped correctly. 55 AA are the bytes for standard pci roms. Update: sorry, I read now you are not passing a rom file... Sometimes this happen if the kernel tries to extract and load the vbios, but it is "masked"; most of the times that is because the igpu is in use by something. Is it possible to have a vbios dump? This could not be an "error", most of the time that line refers to expecting 0xaa55, got 0xffff, which can be totally fine, for example if the vbios has been modded to remove the efi image, or not, if the kernel can see nothing (FF FF). However it sounds a little strange the 0xfc44 value...Again, if the extracted rom is ok, even with that signature value, that is only a warning, and you should have the passthrough working. In real I don't think this is an issue, igpu rom should not be a "standard pci rom", so lacking 55 AA.. Looking around it seems only few people had some luck in passing through to linux guests, as far as I know no luck with windows (till now).
  8. I would suggest to backup your current unraid usb key and upgrade to the latest 6.10.0 RC3. Apply the same boot arg and see if it gets solved, I wouldn't see any reason to not being able to solve this. In case of troubles just restore the backup.
  9. I think he means 6.10RC2, if you're on 6.9.2 you need the patch.
  10. I'm afraid but I think it is, your logs point to the rmrr issue: Qemu log: pci,host=0000:07:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:07:00.0: failed to setup container for group 11: Failed to set iommu for container: Operation not permitted Libvirt log: qemu-system-x86_64: -device vfio-pci,host=0000:07:00.0,id=hostdev0,bus=pci.3,addr=0x0: vfio 0000:07:00.0: failed to setup container for group 11: Failed to set iommu for container: Operation not permitted Syslog: Tower kernel: vfio-pci 0000:07:00.0: DMAR: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor. I read that a patch is included in >=RC2. The patch has some print instructions, "Intel-IOMMU: assuming all RMRRs are relaxable. This can lead to instability or data loss", if it's applied: https://github.com/kiler129/relax-intel-rmrr/blob/master/patches/add-relaxable-rmrr-5_8_and_up.patch but there is no trace in your syslog.
  11. This is HP Proliant, so: vfio-pci 0000:07:00.0: DMAR: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor. You have this boot arg: intel_iommu=relax_rmrr But I think you need kernel patch. Here some readings:
  12. No problem man! happy you solved in some way your issue! And happy that I helped a retro game fan!!I'm going for 40s and I miss that cool games played natively
  13. I don't understand this, can you rephrase?
  14. If this is the issue, it could be a bug (?) in the rc3. I think you could always use terminal to edit the xml of the vm with the 'virsh edit' command. If the alias is lacking try to manually add it with terminal: virsh edit HEREVMNAME Then in the editor add the alias in the appropriate device section: <alias name='YOURALIASHERE'/> Save and exit the editor. Double check again with virsh edit that the alias has being added. Close the editor and try.
  15. Allow unsafe interrupts should not prevent the os to load... Maybe you messed with uefi/legacy bios? Check the mode unraid is booting (uefi vs legacy bios) and check the bios options (csm disabled vs csm enabled).
  16. Last command you typed, "genirq: Flags mismatch irq 16. 00000000 (vfio-intx(0000:07:00.0)) vs. 00000080 (ehci_hcd:usb1)", is not a command, that's why you got the syntax error, it is a line reported in your logs, to explain you what happened. It should be the same, unchecking is fine too! Yes, they have to be added to the vm (vfio), but not attached to vfio at boot. With this config vfio doesn't claim that device at boot, so it attaches to the host driver (if any); when you boot the vm the device detaches from the host driver (if any) and attaches to vfio: that's what I mean for 'on the fly'. Yes, because everytime you boot the bios detects the usb controller (and so, unraid); you may use unraid user scripts to automate it. Otherwise, you may have an option in bios to enable/disable usb controllers (I have it in my bios): by this way you can disable it in bios, so you don't have to type the command on every boot. But take care that disabling devices in bios may re-arrange all irqs, so the capture card may conflict with something else (or not...this must be checked directly). This could be because the "second device" is claiming the same irq as the first one, if this is the case I can't see any option to fix it.
  17. Ok, from your syslog you have: genirq: Flags mismatch irq 16. 00000000 (vfio-intx(0000:07:00.0)) vs. 00000080 (ehci_hcd:usb1) So, a usb 2.0 controller is using irq 16, confirmed by /proc/interrupts, the same irq that the card is trying to use. P.S: I won the bet!! From your lspci output you have 2 usb 2.0 controllers using the ehci driver: 00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 04) Subsystem: Dell 8 Series/C220 Series Chipset Family USB EHCI [1028:05a5] Kernel driver in use: ehci-pci 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 04) Subsystem: Dell 8 Series/C220 Series Chipset Family USB EHCI [1028:05a5] Kernel driver in use: ehci-pci So try to remove one at a time in unraid terminal; try to start with 00:1d.0, since from your proc/interrupts we read usb1 and the output of lspci is USB EHCI #1 (but not sure if it's related or not..): echo -n 1 > "/sys/devices/pci0000:00/0000:00:1d.0/remove" Try to start the vm. If it still output the error, try with the other one: echo -n 1 > "/sys/devices/pci0000:00/0000:00:1a.0/remove" Try to start the vm. The other device, 07:04.0, is trying to be assigned to the same irq 16, so it should be ok (or not...I'm not sure, if this needs another irq and may conflict with 07:00.0): genirq: Flags mismatch irq 16. 00000000 (vfio-intx(0000:07:04.0)) vs. 00000080 (ehci_hcd:usb1) Note: take care to where your unraid usb is plugged in: if you want to avoid issue, plug in into a usb 3.0 port, otherwise you have to map the usb ports to know to which controller they belong, and don't plug in into a port belonging to a controller that you are going to disable/remove. Note2: you may need to remove 07:00.0 and 07:04.0 from vfio-pci.cfg so that they don't attach to vfio at boot; that's because at boot you still have the problematic usb controller detected and I think that when they try to attach to vfio you will get the error. If it's the case detach from vfio at boot and let them attach to it 'on the fly' (i.e. when you run the vm, after you disabled the usb controller).
  18. That is something you cannot fix in unraid or linux or windows, at least for me, and I think it cannot be fixed in the bios too, unless you have some settings to manually assign interrupts. Irq interrupts are assigned automatically depending on your motherboard, some irq are shared, there are a lot of cases of irq shared with usb, ethernet, sata controllers. In most cases thia is not an issue, sometimes it is, for example crackling audio could be caused by shared irq between audio and something else (usb, ethernet, etc), and in your specific case, since you can see that your capture card doesn't support INTx disable. Sometimes, for pcie devices, changing the slot changes also the assigned irq. Otherwise your only option is to remove the device sharing its irq with your capture card, from within linux, as I wrote. I suggest you to read something abour irq if you don't know what they are, at least to know the basics.
  19. This is non sense, it expects 0xaa55 and got 0xaa55, so what's the problem? Are you sure you pasted it right? If the gpu is isolated and the vbios extracted correctly, if you open it in a hex editor first hex values should be 'AA 55'. If the gpu is grabbed by something else, part of the vbios will be masked, but the error will be different, something like 'expecting 0xaa55, got 0xffff'. Similar error if the vbios flashed to the card was modded. Btw, this is not an 'error', but an harmless warning. Is the gpu attached to vfio at boot?Are you sure it doesn't attach to efifb? That should be no difference... RX460 needs reset patch, so removing the plugin without having any reset patch is not a good idea.
  20. You can use this script to check if INTx disable is available or not: #!/bin/sh # Usage $0 <PCI device>, ex: 9:00.0 INTX=$(( 0x400 )) ORIG=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX & $ORIG )) -ne 0 ]; then echo "INTx disable supported and enabled on $1" exit 0 fi NEW=$(printf %04x $(( $INTX | $ORIG ))) setpci -s $1 4.w=$NEW NEW=$(( 0x$(setpci -s $1 4.w) )) if [ $(( $INTX & $NEW )) -ne 0 ]; then echo "INTx disable support available on $1" else echo "INTx disable support NOT available on $1" fi NEW=$(printf %04x $ORIG) setpci -s $1 4.w=$NEW Save it into an .sh file, chmod +x, and run it with: ./check.sh 07:04.0
  21. You should check if this device supports 'INTx disable', I think it doesn't. Without 'INTx disable' the device needs its own irq, if another device is using the same irq it won't work: that's probably why you have it working on some builds and not in others, because this depends on the mb layout and shared irqs. You should check what device is using the same irq and disable it, or adjust your device layout so that this device has its own irq. To remove the offending device you can do it from the terminal, something like: echo -n 1 > "/sys/devices/pci0000:00/0000:00:1b.0/remove" 00:1b.0 being the offending device. If I had to bet I would say some usb controller is sharing the same irq....
  22. Did you try to reboot your router?
  23. vfio_iommu_type1_attach_group: No interrupt remapping support. Use the module param "allow_unsafe_interrupts" to enable VFIO IOMMU support on this platform So I would try to add to syslinux config: vfio_iommu_type1.allow_unsafe_interrupts=1 ---> For unraid without gui it becomes: append vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot It is also recommended to attach to vfio at boot iommu groups 14 and 15, gpu video and audio.
  24. You don't need a second pc to dump the rom; if it fails to dump it probably means that you are not able to detach it from the host. You may check your syslog and see if the gpu is in use by efifb (just search for "efifb" and see if it's attached to your amd gpu) and add to your syslinux config video=efifb:off. Using a downloaded rom can work if you know what you are doing, but if the rom is not that corresponding to your gpu (even a rom with changed gpu revision version can fail) it will fail. If most of applications fail to start maybe you haven't installed redistributable packages (visual c++, net frameworks), less probable that you have corrupted filesytem, less probable you have an av blocking some dlls. This isn't very important, on most builds it is fixed with kernel boot-args (see above video=efifb:off); if you are booting unraid in uefi mode, the primary gpu is attached to efifb for console video output, so it gets grabbed by the host, setting it as secondary prevents so without the need to detach the gpu from the host. If the pc bios/firmware is bugged, last option is to change the physical pcie slot, usually pcie priority goes from top to bottom, meaning that a gpu in top slot has priority over a gpu in a slot below the top one.