Re: [Xenomai-help] Freeze while running examples

[Philippe Gerum <rpm@xenomai.org>]

On 03/06/2012 05:45 PM, Gilles Chanteperdrix wrote:
> On 03/06/2012 04:14 AM, Oscar Dávila wrote:
>> 2012/3/2 Gilles Chanteperdrix<gilles.chanteperdrix@xenomai.org>
>>
>>> On 03/03/2012 01:14 AM, Oscar Dávila wrote:
>>>> 2012/3/2 Gilles Chanteperdrix<gilles.chanteperdrix@xenomai.org>
>>>>
>>>>> On 03/02/2012 11:04 AM, Gilles Chanteperdrix wrote:
>>>>>> On 03/01/2012 05:23 AM, Oscar Dávila wrote:
>>>>>>> Finally i could get the dump
>>>>>>>
>>>>>>>
>>>>>>> post-prompt
>>>>>>> No breakpoints or watchpoints.
>>>>>>>
>>>>>>> breakpoints-table-end
>>>>>>>
>>>>>>> post-prompt
>>>>>>> Dump of assembler code for function __ipipe_sync_stage:
>>>>>>> 0xc106d376<__ipipe_sync_stage+0>:   push   %ebp
>>>>>>> (...)
>>>>>>> 0xc106d526<__ipipe_sync_stage+432>: ret
>>>>>>> End of assembler dump.
>>>>>>
>>>>>> The address where the EIP is when the NMI watchdog triggers is
>>>>>> 0xc106d5e1, so, outside this code.
>>>>>>
>>>>> And this dump does not seem to correspond to the kernel that was running
>>>>> when the bug happened, because in that case we had
>>>>>
>>>>> 0xc106d5e1 == __ipipe_sync_stage + 0x21b
>>>>>
>>>>> whereas in your dump,
>>>>>
>>>>> __ipipe_sync_stage + 0x21b == 0xc106d591
>>>>>
>>>>> Sorry about that, i lost that image of the kernel.
>>>>
>>>> Here is a new complete test.
>>>>
>>>> Kernel Messages
>>>>
>>>>
>>>> Kernel failure message 1:
>>>> BUG: NMI Watchdog detected LOCKUP on CPU0, ip c10751d3, registers:
>>>>
>>>>                        local_irq_disable_hw();
>>>> c10751bf:     fa                      cli
>>>> c10751c0:     89 e0                   mov    %esp,%eax
>>>> c10751c2:     25 00 e0 ff ff          and    $0xffffe000,%eax
>>>>                        root_stall_after_handler();
>>>>                        while (__ipipe_check_root_resched())
>>>> c10751c7:     83 78 14 00             cmpl   $0x0,0x14(%eax)
>>>> c10751cb:     75 58                   jne    c1075225<__xirq_end+0x2>
>>>> c10751cd:     f6 40 08 08             testb  $0x8,0x8(%eax)
>>>> c10751d1:     74 52                   je     c1075225<__xirq_end+0x2>
>>>> c10751d3:     eb f8                   jmp    c10751cd
>>> <__ipipe_sync_stage+0x12b>
>>>>                                __ipipe_preempt_schedule_irq();
>>>
>>> Looks like an infinite loop when CONFIG_PREEMPT is off. Try putting an
>>> #ifdef CONFIG_PREEMPT around this code:
>>>
>>> #ifdef CONFIG_PREEMPT
>>>                         while (__ipipe_check_root_resched())
>>>                                 __ipipe_preempt_schedule_irq();
>>> #endif
>>>
>>> To test that this is indeed the issue, you may try enabling
>>> CONFIG_PREEMPT in the code.
>>
>>
>>
>> I recompiled the kernel enabling CONFIG_PREEMPT and it worked, also i tried
>> the other option, where i add the #ifdef CONFIG_PREEMPT to the source of
>> core.c, and it also worked.
>>
>> So it seems that was the problem. Now i can run trivial_periodic.
>>
>> But after some time with the kernel after running trivial_periodic, the
>> machines still freezes, i will try to see where the failure is happening
>> now.
>>
>> Which type of preemption model its preferred? i mean, using the
>> CONFIG_PREEMPT enabled or without the:
>>                         while (__ipipe_check_root_resched())
>>                                 __ipipe_preempt_schedule_irq();
>
> We should not need either workaround. From reading the code, I do not
> understand why the compiler creates this infinite loop. It would be
> interesting to generate the pre-processed file to understand how this
> happens.
>

Because CONFIG_PREEMPT is disabled, but __ipipe_check_root_resched() is 
instantiated. This can't fly.

-- 
Philippe.