[EMAIL PROTECTED] wrote:
As I have read that uvm and vxWorks exclude each other, I just inserted the
xeno_uvm module (not the xeno_vxworks.o module ).
I am using xenomai-2.1-rc2 and try to create a task via the vxWorks skin
No problems so far.
More precisely, the VxWorks API is compiled as a user-space library (instead of a
kernel module) when using the UVM mode, and the VxWorks services are obtained from
this library, within the Linux process that embodies it. This is why there is no
point in loading the in-kernel VxWorks module in this case.
When I start my application nothing happens (no errormessages ...), the
application seems to hang. Debugging printf´s show that the function taskSpawn
never returns and the task to be spawned (there is no evidence that she is
running) never produces any debug output.
This happens with both vxworks skin examples koan.c and satch.c.
Xenomai native skin works, satch and latency are running.
Does anybody have any idea/recomendation about this behavior ?
After your application has stalled, try dumping the scheduler state to get more
information on the existing threads:
$ cat /proc/xenomai/sched
The same goes for the timer state:
$ cat /proc/xenomai/timer
Additionally, you may want to load your application with GDB, and see which code
gets executed using breakpoints.
Xenomai-core mailing list