M. Koehrer wrote:
> Hi Jan,
> 
> I have looked closed into that issue.
> For that I have added a global array that is written within  
> __ipipe_handle_irq() (file arch/i386/kernel/ipipe.c):
> 
>                 extern int xxx_int[];
>                 irq = ~irq;
> 
>                 xxx_int[0] = irq;
> 
> #ifdef CONFIG_X86_LOCAL_APIC
>                 {
>                         unsigned vector = irq + FIRST_EXTERNAL_VECTOR;
>                         if (vector >= FIRST_SYSTEM_VECTOR)
>                                 irq = ipipe_apic_vector_irq(vector);
>                 }
> 
>                  xxx_int[1] = irq;
> 
> 
> This global variable is printed out within the kernel trap.
> It returns the values 0xcf and 0xe0 (207 and 224) for xxx_int[0], xxx_int[1].
> And this is the really strange thing as the IRQ for the e1000 should be 219 (on a non-adeos-patched kernel).
> I do not know what happens here, but it looks really strange...
> 

Please make xxx_irq per-cpu to exclude ugly races with the second CPU
handling IRQs in parallel. Also re-apply Philippe's vectoring
instrumentation and post the full kernel log to have a consistent picture.

Jan