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

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.

>>> On 16.05.14 at 17:31, <ijc at hellion.org.uk> wrote:
> On Fri, 2014-05-16 at 11:08 +0100, Jan Beulich wrote:
>> 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?
Possibly, but not necessarily (the fact that these messages show up
so early, without any connection to a driver being loaded, kind of
puzzle me - I wonder whether they're associated with one of the PCI
bridges, which lspci may be able to tell us).

Jan

>>> On 16.05.14 at 17:31, <ijc at hellion.org.uk> wrote:
> On Fri, 2014-05-16 at 11:08 +0100, Jan Beulich wrote:
>> 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).
What occurred to me right after sending the previous reply - I think
it was said earlier that it doesn't matter which port the keyboard was
plugged in. Does that hold if it gets plugged into a port connected to
the other EHCI HC? I.e. does the failure then occur during the other
driver initialization instance?

Jan

Attached are the most recent boot logs.
All tests have been on the same system, an Intel S1200BTL motherboard.

I did 2 boots, both with kernel 3.13.
First one into xen 4.3 and the 2nd into xen 4.1.
The keyboard works on xen 4.1, not on 4.3.

Cheers,
Mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20140516/a9f8fe86/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xen4.1dmesg.txt
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20140516/a9f8fe86/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xen4.3dmesg.txt
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20140516/a9f8fe86/attachment-0005.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xen4.3xldmesg.txt
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20140516/a9f8fe86/attachment-0006.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xen4.1xldmesg.txt
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20140516/a9f8fe86/attachment-0007.txt>

Here's some more info:

I went into the BIOS, Advanced Tab-->USB Configuration
and set the following:

USB Controller				[Enabled]
Legacy USB Support			[Disabled]
Port 60/64 Emulation			[Disabled]

Make USB Devices Non-Bootable	[Disasbled]

Device Reset timeout			[20 sec]


I then rebooted into xen4.3 kernel 3.13.
The keyboard does NOT work at the grub menu.
But 5 seconds pass and the system boots.
Once at the login console, then keyboard works!





-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20140516/be7b34e0/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmesgnolegacyusb.txt
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20140516/be7b34e0/attachment-0001.txt>

Ian Campbell <ijc at hellion.org.uk> writes:
#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.

Forgive me as I'm not that familiar with source code.
I've run apt-get source xen
and downloaded the xen-4.3.0 code.

I've run Make -C xen and it compiled fine.
How now do I boot with the xen.gz?

Also Jan mentioned that I could try one of the newer xen's.
Should I patch this source code, or upgrade it first before booting it?

Thanks,

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20140521/b29cbdf4/attachment.html>

On Wed, 2014-05-21 at 10:44 -0700, Mike Egglestone wrote:

> I've run Make -C xen and it compiled fine.
> How now do I boot with the xen.gz?
Copy xen/xen.gz to /boot and add an entry to your grub config
(/boot/grub/grub.cfg) which references it, you can just copy one of the
existing Xen entries and change the path.
> Also Jan mentioned that I could try one of the newer xen's.
> Should I patch this source code, or upgrade it first before booting
> it?
Probably best/easiest to boot with something like what you are using
already but built yourself first before starting to change things. So
I'd suggest starting with the xen.gz which you've just built.

Ian.