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

[Ian Campbell]

On Fri, 2014-05-16 at 11:08 +0100, Jan Beulich wrote:

Thanks for taking a look.

FYI Mike has since mentioned on the bug report that 4.1 worked. I've
asked for logs of Xen 4.1 + Linux 3.13 and Xen 4.3 + Linux 3.13 for
comparison.

> >>> 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.

Mike -- did both of the logs with Xen come from the same system? Since
you resent the Xen ones I expect it wasn't the same boot, but at least
the same machine, right?

> 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)?

Sadly I don't think the Debian packages currently retain these.

Mike, the easiest way to gather these might be
	apt-get source xen=<pkg-version>
	cd xen-XXX
	make -C xen 

Then boot with the resulting xen/xen.gz. Then xen/xen-syms is the symbol
file which Jan refers to.

> 
> 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).

Would this be visible in /proc/interrupts when not running under Xen?

Ian.