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?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
