On 2013-02-19 13:30, Gilles Chanteperdrix wrote: > On 02/19/2013 01:22 PM, Jan Kiszka wrote: > >> On 2013-02-19 13:07, Gilles Chanteperdrix wrote: >>> On 02/19/2013 01:05 PM, Jan Kiszka wrote: >>> >>>> On 2013-02-19 12:22, Manuel Huber wrote: >>>>> Thanks for your reply and sorry for the delay ;) >>>>> I have tried disabling the options and attached the logs. It still fails >>>>> :( >>>>> >>>>> I hope it's okay to attach so many files... I can also add the config >>>>> files for >>>>> every build if that helps. >>>> >>>> I'll try your config later, though in a different environment. If I'm >>>> unable to reproduce, I'll provide further instrumentation suggestions. >>>> >>>> Gilles instrumentation confirmed that the CPU is taking a standard >>>> external IRQ (#23: 0x37-FIRST_EXTERNAL_VECTOR). I suspect we are >>>> enabling hardware IRQs too early during the boot of secondary CPUs, >>>> causing this BUG as not all data structures are initialized yet. What >>>> enables then can be some code that we do not run normally, on x86-64 or >>>> maybe also x86-32 unless using your .config and/or your hardware. >>> >>> >>> Remember that we have had such problems with grub2, so, the error could >>> depend on the bootloader, for instance a network-aware bootloader could >>> keep the network interface configured and we would take an interrupt >>> when re-enabling interrupts. >> >> Possibly, but I don't see yet how Linux (3.5.7) would behave better in >> this case. It should rather access the irq_desc array with a negative >> index. And that suggests there is still an I-pipe factor involved that >> makes this bug possible (the BUG_ON just catches it). > > > Maybe because Linux only unmask the interrupt after request_irq has > installed a handler?
Does I-pipe do this, specifically that early during boot? Well, I can try injecting a spurious IRQ7 through QEMU to see what happens. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
