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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
