[Pkg-xen-devel] Bug#748052: [Xen-devel] dom0 USB failing with "ehci-pci: probe of 0000:00:1d.0 failed with error -110"

[Jan Beulich]

>>> On 16.05.14 at 10:58, <ijc at hellion.org.uk> wrote:
> So it seems like dom0 is unable to (correctly) bind to some hardware
> interrupts. I wonder if these messages from Xen's dmesg are relevant.
> (XEN) Not enabling x2APIC: depends on iommu_supports_eim.
> (XEN) I/O virtualisation disabled
> (XEN) Enabled directed EOI with ioapic_ack_old on!

The last one certainly isn't, and the first two shouldn't (albeit the
non-Xen kernel is running in x2APIC mode). That difference is likely
because the Xen and non-Xen boots are with differing BIOS
configurations, or on different machines: The non-Xen boot shows
a DMAR ACPI table, while the Xen one doesn't. Or wait, no, the
hypervisor and kernel-under-Xen logs differ in that respect too. We
clearly need a consistent set of logs.

The one clearly odd thing in the hypervisor logs are these two lines

(XEN) traps.c:3061: GPF (0000): ffff82c4c0186a91 -> ffff82c4c0218daa
(XEN) traps.c:3061: GPF (0000): ffff82c4c0186a91 -> ffff82c4c0218daa

Can at least the left side address please be associated back with a
symbol (with the help of xen-syms perhaps)?

And finally, looking at the IRQ usage, this

[    2.087722] xen: registering gsi 22 triggering 0 polarity 1
[    2.087731] xen: --> pirq=22 -> irq=22 (gsi=22)
[    2.100161] xen: registering gsi 20 triggering 0 polarity 1
[    2.100166] xen: --> pirq=20 -> irq=20 (gsi=20)

happens rather early - it's not clear to me in which context that is.
And there's no problem with GSI 22 used by the other EHCI HC, so
a fundamental question is what other device(s) is/are using GSI 20
(not visible from the non-Xen kernel log).

Jan