Hi again,
Check whether the thread manager does attempt to call into the
Xenomai
replacement for the pthread_cond_wait call.
I have to apologize; the pthread_cond_wait -> EPERM appeared after
enabling
debug output to trace the actual problem I had when I started this
mail thread,
but is seems unrelated. I have completely disabled that part of
code, and with
it also disabled the use of all pthread* functions. Only native
skin functions
are used by my remaining code and I'm back to the original problem
(gdb hangs
at some point when stepi'ing through rt_task_start).
Even though debugging is enabled, nothing is printed on the
console. The target
cannot be reached on the console (Ctrl-C doesn't work) and GDB also
doesn't
react on Ctrl-C. telnet to the target works, however. cat /proc/
xenomai/sched
shows the half started task as "X Console_Output_Thread":
/ # cat /proc/xenomai/sched
CPU PID CLASS PRI TIMEOUT TIMEBASE STAT NAME
0 0 rt 49 - master R ROOT
0 303 rt 49 - master RT main
0 305 rt 49 - master X
Console_Output_Thread
I forgot to describe our problem: Gdb hung at rt_task_start() when
trying to step through it. But debugging worked fine if I set a
breakpoint in the task body, way after any rt_task_start(). Btw, do
you call rt_task_start() from a RT task body?
Andreas
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
