From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: xen 4 only seeing one keyboard and mouse Date: Mon, 16 Aug 2010 11:46:18 -0400 Message-ID: <20100816154618.GA8493@phenom.dumpdata.com> References: <20100721204042.GN17817@reaktio.net> <20100721214107.GO17817@reaktio.net> <20100722175153.GA4911@phenom.dumpdata.com> <20100723142724.GB4008@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: M A Young Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Sun, Aug 08, 2010 at 09:16:56PM +0100, M A Young wrote: > On Sun, 8 Aug 2010, M A Young wrote: > > >Unfortunately I don't have a serial console to output to. The best > >I can do is the dmesg outputs for xen and the kernel with I am > >attaching (bzipped). > > I found the conring_size setting and got a more complete dmesg log. I looked through it and also through your previous kernel and Xen outputs and nothing sparked that 'Aha!' moment. 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. - 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. - The /proc/interrupts is interesting. It shows no interrupts on your other CPU, but the IOAPIC tells us that the irq's should be blasted to both CPUs. So I wonder if it got reprogrammed by the 'irqbalance' daemon. One way to find that out is to do the 'xm send-keys i' thingie to see if the destination field is the same. - 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.