Re: pvops-2.6.32 - Interrupt routing problem

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Mar 16, 2010 at 09:18:32AM +0100, Bastian Blank wrote:
> On Mon, Mar 15, 2010 at 09:31:14PM -0400, Konrad Rzeszutek Wilk wrote:
> > 1) Can you boot your baremetal with these options:
> >  acpi.debug_level=0xffffffff  acpi.debug_layer=0x2 apic=debug 
> 
> | IOAPIC[0]: Set routing entry (8-14 -> 0x3e -> IRQ 14 Mode:0 Active:0)
> | IOAPIC[0]: Set routing entry (8-14 -> 0x3e -> IRQ 14 Mode:1 Active:1)
> 
> > 2) And then later on your Xen with these (make SURE to _not_ have apic=debug on
> > the Linux kernel command line with Xen, it will blow):
> >   xen.gz  apic=debug apic_verbosity=debug  console_to_ring sync_console loglvl=all guest_loglvl=all
> 
> | (XEN) IOAPIC[0]: Set PCI routing entry (8-14 -> 0x88 -> IRQ 14 Mode:0 Active:0)
> | (XEN) Pin 8-14 already programmed
> | (XEN) IOAPIC[0]: Set PCI routing entry (8-14 -> 0x88 -> IRQ 14 Mode:1 Active:1)
> 
> | (XEN) IOAPIC[0]: Set PCI routing entry (8-5 -> 0x38 -> IRQ 5 Mode:0 Active:0)
> | (XEN) Pin 8-5 already programmed
> | (XEN) IOAPIC[0]: Set PCI routing entry (8-5 -> 0x38 -> IRQ 5 Mode:1 Active:1)
> 
> Still with my hack to allow 8-5 and 8-14 to be reprogrammed.

I wish you had included the whole serial console for Xen boot. I am
curious to at what stage the pin 14 of the IOAPIC is set. Is it set by Xen
hypervisor initially (don't think so), or is there another piece of code
in the pv-ops that iterates over the 0-15 IRQs and sets them to the
legacy trigger/level?

When you printed out the IOAPIC information, did the Xen one (in the
hypervisor, when you did apic=debug during boot) have pin 14 set to the
wrong mode?

Or was it later when the pv-ops kernel booted that the pin 14 was set
incorrectly?