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

Reply via email to