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 errormess
Hello everybody,
1) arm/hal.c : rthal_irq_enable/disable/end()
the only arch that calls Linux'es enable_irq() and disable_irq() directly.
The later ones use spinlock with the interrupts off only for the Linux domain,
so that under some circumstances - Linux domain gets preempted being i
Hi Philippe,
I figured out where to link/copy every file. There was no need to
modify any file in ksrc/...
Here is my patch. The new option to prepare-kernel.sh is:
--outpatch=
For instance you can run:
> mkdir /tmp/temptree
> ./scripts/prepare-kernel.sh
--outpatch=/tmp/patch.diff /tmp/tempt
Some more debugging (printf´s ;-)) of the example satch.c revealed that
taskSpawn hangs in a function of the nucleus module nucleus/pod.c called
xnpod_schedule.
This is the caller stack :
vxworks/tasklib.c/taskSpawn
->vxworks/tasklib.c/taskInit
->vxworks/tasklib.c/TaskActivate
-->nucleus/pod.c
Hi Philippe,
I noticed you fixed the libtool warning during xenomai build - by
linking the testsuite statically... :-/ This is just a workaround and
doesn't help external users.
Isn't the reason for this warnings that "-module" in every skin
Makefile.am? At least, removing it also fixes external
Jan Kiszka wrote:
Hi Philippe,
I noticed you fixed the libtool warning during xenomai build - by
linking the testsuite statically... :-/ This is just a workaround and
doesn't help external users.
Yes, it's clearly hacky-patchy, however, I don't see how this would impact
external users (yet)?
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Hi Philippe,
>>
>> I noticed you fixed the libtool warning during xenomai build - by
>> linking the testsuite statically... :-/ This is just a workaround and
>> doesn't help external users.
>
> Yes, it's clearly hacky-patchy, however, I don't see how th
Gilles Chanteperdrix wrote:
> Romain Lenglet wrote:
> > +while read f; do
> > +f=`echo $f | cut -d/ -f2-`
> > +d=`dirname $f`
> > +if test "x$output_patch" = "x"; then
> > +mkdir -p $linux_tree/$link_dir/$d && \
> > +
Jim Cromie wrote:
attached is an update to xeno-test which runs latency with -t0 -t1 -t2
I think Ive got xeno-test and xeno-test.in sync'd, that doesnt seem to
happen
as part of the configure make process for me.
this ones slightly improved, it greps XENO out of /proc/config.gz if its
there.
