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