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

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

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.
If you have got some ideas I can make tests as you want.
Regards,
Paolo