Maybe a bit of a stupid question, but did you check in your motherboard
manual and make sure the two cards are in non-IRQ sharing slots? On
skylake the x1 port to slot assignment is hard wired so they likely
share IRQs with another device (that's a good thing on skylake .. but
not if you've got IRQ problems). Should be a table in your manual .. if
not I can send you the spec. but it's not very friendly.
I have a skylake system and run the sorts of setups your running using
q35. When it's not 5am .. I can post the script for you to try as you
don't seem to use q35 and switching is a big job. Until then try a
couple of kernel command line args e.g. pci=noacpi or pci=biosrq as
they'll mess around the irq ordering (and probably get different ones
sharing). And absolutely make sure that Native ASPM is off. I bind
pci-stub to my root bridges (fine on skylake as the firmware not
software does it all)..
Somebody with a more definitive answer will likely turn up first anyway.
V1 devices don't work reliably .. I'll say that for sure.
D
Just a couple of thoughts .. can help more when it's not 5am!
On 09/09/16 08:40, Laszlo Ersek wrote:
On 09/09/16 03:21, Brett Peckinpaugh wrote:
I am running Arch Linux, ACS patch on a Skylake system. I have some
audio pop and crackle so wanted to try passing a sound card instead of
routing the audio from my monitor to my speakers. I purchased an Asus
Xonar PCI DGX. Chip is CMI8788. I can boot the host with it, or my USB
card. But not both. Error I get is as follows.
Error starting domain: internal error: qemu unexpectedly closed the
monitor: 2016-09-09T01:17:41.729237Z qemu-system-x86_64: -device
vfio-pci,host=0e:00.0,id=hostdev3,bus=pci.0,addr=0x6: vfio: Error:
Failed to setup INTx fd: Device or resource busy
2016-09-09T01:17:41.729854Z qemu-system-x86_64: -device
vfio-pci,host=0e:00.0,id=hostdev3,bus=pci.0,addr=0x6: Device
initialization failed
http://vfio.blogspot.hu/2014/09/vfio-interrupts-and-how-to-coax-windows.html
VFIO does also have support for non-PCI-2.3 compliant devices, but
it requires a much more restricted configuration. We still need to
identify when the assigned device is signaling an interrupt, which
we can only do in a non-device specific way by requiring only a
single device per interrupt line. Also when this is the case, we
can mask the interrupt at the system APIC rather than at the device
itself. Therefore we can achieve the same results, but we require
an exclusive interrupt line for the device, which can often be an
insurmountable configuration restriction.
[...]
If you find that your device supports MSI but it's not being
enabled, and your guest is Windows, you can follow the steps found
here to attempt to enable it. [...]
You can also try moving the card(s) to different slots:
[...] PCI bridges also incorporate a standard swizzle to remap
interrupt lines between primary and secondary interfaces, so that we
don't over-use some of the interrupt lines. Each slot may also have
different mappings, so INTA on one slot doesn't actually pull the
same line as INTA on another slot.
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
_______________________________________________
vfio-users mailing list
vfio-users@redhat.com
https://www.redhat.com/mailman/listinfo/vfio-users
