Re: [Xenomai] Sporadic problem : rt_task_sleep locked after debugging

[Paolo Minazzi <Paolo.Minazzi@mitrol.it>]

Il 11/03/2013 21.26, Gilles Chanteperdrix ha scritto:
> On 03/11/2013 02:46 PM, Paolo Minazzi wrote:
>
>> Il 11/03/2013 14.07, Gilles Chanteperdrix ha scritto:
>>> On 03/11/2013 09:47 AM, Paolo Minazzi wrote:
>>>
>>>> Il 08/03/2013 21.13, Gilles Chanteperdrix ha scritto:
>>>>> On 03/08/2013 01:50 PM, Paolo Minazzi wrote:
>>>>>
>>>>>> This fault does not freeze the arm, I can countinue to work.
>>>>>>
>>>>>> Ideas ?
>>>>> Please try the following patch:
>>>>>
>>>>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>>>>> index c91a6f3..ed3864b 100644
>>>>> --- a/ksrc/nucleus/shadow.c
>>>>> +++ b/ksrc/nucleus/shadow.c
>>>>> @@ -1430,8 +1430,10 @@ void xnshadow_unmap(xnthread_t *thread)
>>>>>     	rpi_pop(thread);
>>>>>
>>>>>     	sys_ppd = xnsys_ppd_get(0);
>>>>> -	xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>>>> -	thread->u_mode = NULL;
>>>>> +	if (thread->u_mode) {
>>>>> +		xnheap_free(&sys_ppd->sem_heap, thread->u_mode);
>>>>> +		thread->u_mode = NULL;
>>>>> +	}
>>>>>
>>>>>     	xnarch_atomic_dec(&sys_ppd->refcnt);
>>>>>
>>>>> @@ -2379,7 +2381,7 @@ int do_hisyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>>>           ret_handled:
>>>>>
>>>>>     	/* Update the userland-visible state. */
>>>>> -	if (thread)
>>>>> +	if (thread&&    thread->u_mode)
>>>>>     		*thread->u_mode = thread->state;
>>>>>
>>>>>     	trace_mark(xn_nucleus, syscall_histage_exit,
>>>>> @@ -2549,7 +2551,7 @@ int do_losyscall_event(unsigned event, rthal_pipeline_stage_t *stage,
>>>>>           ret_handled:
>>>>>
>>>>>     	/* Update the userland-visible state. */
>>>>> -	if (thread)
>>>>> +	if (thread&&    thread->u_mode)
>>>>>     		*thread->u_mode = thread->state;
>>>>>
>>>>>     	trace_mark(xn_nucleus, syscall_lostage_exit,
>>>>>
>>>> Hi Gilles,
>>>> I can see the same problem under 2.6.2.1.
>>>> I was debugging, after a while I could not stop anymore the code using
>>>> breakpoints because all tasks are stopped at rt_task_sleep.
>>>> After this, If I close the application and restart it, the rt_task sleep
>>>> are blocked. I have to restart my arm processor.
>>>> Any ideas ?
>>> Debugging xenomai thread causes the timers to be stopped, and they are
>>> supposed to be restarted when the thread blocked on the breakpoint,
>>> maybe this is what goes wrong: the timers are not restarted.
>>>
>>> Another possibility is the hardware timer being programmed for a too
>>> short delay.
>>>
>>> Please no private mails.
>>>
>>>> Paolo
>>>>
>>>>
>>>
>> Time ago I have already tried to change a parameter
>> ksrc/nucleus/timer.c:402 (the following is the comment ...)
>>                                   /*
>>                                    * Make the blocked timer elapse again
>>                                    * at a reasonably close date in the
>>                                    * future, waiting for the timebase to
>>                                    * be unlocked at some point. Timers
>>                                    * are blocked when single-stepping
>>                                    * into an application using a
>>                                    * debugger, so it is fine to wait for
>>                                    * 250 ms for the user to continue
>>                                    * program execution.
>>                                    */
>>                                   interval = xnarch_ns_to_tsc(250000000ULL);
>>                                   goto requeue;
>>
>> I have tried bigger and smaller value than 250ms without luck.
>
> As the comment says, and the code shows, the timer will elapse again and
> check if the timebase is unlocked, if the timebase is locked, it will go
> to sleep again.
>
>> If you have got some ideas I can make tests as you want.
>
> Provide us with an example allowing to reproduce the issue. Or
> alternatively, you can do the debug yourself following the leads I
> already gave you.
>
>
Unfortunately it is not easy make a small program that produce the problem.
I have tried making the debugging with gdb an automatic process, but I 
cannot see the problem.
I can uderstand that timer stops because a problem in programming the 
timer interval.
But I do not understand why if I use CTRL-C to stop the application (in 
a moment that rt_task_sleep are blocked) I have still the same problem 
(rt_task_sleep blocked). The only solution to use a realtime process is 
to reset my arm processor. Why xenomai does not reset all when I start a 
xenomai application ?

Paolo