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