Re: [Xen-devel] xen 4 only seeing one keyboard and mouse

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Aug 16, 2010 at 10:05:58PM +0100, M A Young wrote:
> On Mon, 16 Aug 2010, Konrad Rzeszutek Wilk wrote:
> 
> >There are a couple of things we can try:
> >- Compare this with the output from Xen 3.4 and see if the IOAPIC lines
> >  are different. Especially if these:
> >(XEN) IOAPIC[0]: Set PCI routing entry (2-12 -> 0x78 -> IRQ 12 Mode:0 
> >Active:0)
> >(XEN) IOAPIC[0]: Set PCI routing entry (2-1 -> 0x28 -> IRQ 1 Mode:0 Active:0
> >
> >are different. I think that previous to Xen 4, the pv-ops kernel could
> >not set the IOAPIC entries below pin 16, so you would not see them and
> >instead it would have these programmed:
> >(XEN)  01 001 01  0    0    0   0   0    1    1    28
> >(XEN)  0c 001 01  0    0    0   0   0    1    1    78
> >
> >Which is OK, as the trigger and polarity look to be correct.
> 
> Logs attached as dmesg.xen3 and xm.xen3

Cool. So this is what I see

(XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:      | (XEN)  NR Log 
Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
(XEN)  00 000 00  1    0    0   0   0    0    0    00           (XEN)  00 000 
00  1    0    0   0   0    0    0    00
(XEN)  01 001 01  0    0    0   0   0    1    1    20         | (XEN)  01 001 
01  0    0    0   0   0    1    1    28
(XEN)  02 001 01  0    0    0   0   0    1    1    F0           (XEN)  02 001 
01  0    0    0   0   0    1    1    F0
(XEN)  03 001 01  0    0    0   0   0    1    1    28         | (XEN)  03 001 
01  0    0    0   0   0    1    1    30
(XEN)  04 001 01  0    0    0   0   0    1    1    30         | (XEN)  04 001 
01  0    0    0   0   0    1    1    38
(XEN)  05 001 01  0    0    0   0   0    1    1    38         | (XEN)  05 001 
01  0    0    0   0   0    1    1    40
(XEN)  06 001 01  0    0    0   0   0    1    1    40         | (XEN)  06 001 
01  0    0    0   0   0    1    1    48
(XEN)  07 001 01  0    0    0   0   0    1    1    48         | (XEN)  07 001 
01  0    0    0   0   0    1    1    50
(XEN)  08 001 01  0    0    0   0   0    1    1    50         | (XEN)  08 001 
01  0    0    0   0   0    1    1    58
(XEN)  09 001 01  1    1    0   0   0    1    1    58         | (XEN)  09 001 
01  1    1    0   0   0    1    1    60
(XEN)  0a 001 01  0    0    0   0   0    1    1    60         | (XEN)  0a 001 
01  0    0    0   0   0    1    1    68
(XEN)  0b 001 01  0    0    0   0   0    1    1    68         | (XEN)  0b 001 
01  0    0    0   0   0    1    1    70
(XEN)  0c 001 01  0    0    0   0   0    1    1    70         | (XEN)  0c 001 
01  0    0    0   0   0    1    1    78
(XEN)  0d 001 01  0    0    0   0   0    1    1    78         | (XEN)  0d 001 
01  0    0    0   0   0    1    1    88
(XEN)  0e 001 01  0    0    0   0   0    1    1    88         | (XEN)  0e 001 
01  0    0    0   0   0    1    1    90
(XEN)  0f 001 01  0    0    0   0   0    1    1    90         | (XEN)  0f 001 
01  0    0    0   0   0    1    1    98
(XEN)  10 000 00  1    0    0   0   0    0    0    00           (XEN)  10 000 
00  1    0    0   0   0    0    0    00
..
Left column is 3.4, right is 4.0.

The one thing that is odd is that in 4.0 we start with vector 0x28 while
in 3.4 it is with 0x20.

It looks as if one vector is getten eaten. But that should not be such
an issue as the internal mapping of vector->irq is still proper...

> 
> >- Boot the Xen4, and trigger the IOAPIC debug printout. I think this is
> >  can be done via "xm send-keys i". Also the 'q' output would be
> >  usefull (it will tell us which ioports domain 0 has access to - we
> >  should see dom0 see 0x60 and 0x64), and irq 1, and 12.
> 
> attached as xm.debugkeys

OK. The ioports are OK, the vectors and irq are fine too.
> 
> >- We can also compare this to baremetal IOAPIC programming. It should
> >  be the _same_ as what Xen does. What we can do is provide
> >  'apic=debug' and that will print out the IOAPIC entries of baremetal
> >  kernel. The values for irq 1 and 12 ought to be same as what Xen saw
> >  and programmed it too.
> 
> attached as dmesg.baremetal

Thanks. It seems to do the thing that baremetal always does..

<sigh> Still no idea what is the trouble with your box.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel