[Xenomai-core] vxworks-skin taskSpawn

[Xenomai-core] vxworks-skin taskSpawn

[Roderik_Wildenburg]

I am using xenomai-2.1-rc2 and try to create a task via the vxWorks skin function taskSpawn. As I have read that uvm and vxWorks exclude each other, I just inserted the xeno_uvm module (not the xeno_vxworks.o module ). No problems so far. 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 ?

Thank you in advance !
Roderik

Re: [Xenomai-core] vxworks-skin taskSpawn

[Philippe Gerum]

Roderik_Wildenburg@domain.hid wrote:
> I am using xenomai-2.1-rc2 and try to create a task via the vxWorks skin function taskSpawn.
As I have read that uvm and vxWorks exclude each other, I just inserted the 
xeno_uvm module (not the xeno_vxworks.o module ).
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.

-- 

Philippe.