From: Philippe Gerum <rpm@xenomai.org>
To: Roderik_Wildenburg@domain.hid
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] vxworks-skin taskSpawn
Date: Sat, 25 Feb 2006 13:28:12 +0100 [thread overview]
Message-ID: <44004D5C.6060708@domain.hid> (raw)
In-Reply-To: <5D63919D95F87E4D9D34FF7748CE2C2A1C3B49@domain.hid>
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.
prev parent reply other threads:[~2006-02-25 12:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-24 10:13 [Xenomai-core] vxworks-skin taskSpawn Roderik_Wildenburg
2006-02-25 12:28 ` Philippe Gerum [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44004D5C.6060708@domain.hid \
--to=rpm@xenomai.org \
--cc=Roderik_Wildenburg@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.