>>> On 16.05.14 at 10:58, <i...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org