Does anyone use Busybox(www.busybox.net) on a xenomai-linux ?
Or does anyone experience one of these problems with busybox on xenomai
:
- yes /dev/null stalls system completely (yes is a little program
returning 'y' continously; this does not happen using a normal bash
shell)
- netstat -a seems
Sorry for the stupid question but: what is tick_arg ? Do I have to configure
it within Xenomai or is it a kernel parameter ?
The timing of my target in principal is fine. When I set
tstart.tv_sec=0;
tstart.tv_nsec=0;
both to zero, my task gets peiodic (task runs every second). Just when
Can anybody tell me, how I have to set the 2. parameter (starttp) of
pthread_make_periodic_np ?
When I use clock_gettime to fill startp I get a giant timeout value in
the /proc/xenomai/sched list and my task never gets periodic.
Is this just a problem of my hardware(PPC)/xenomai(2.3) combination
When I try to prepare the kernel with xenomai-2.3-rc2 I get the
following error :
find: xenomai-2.3-rc2/sim: file or directory not found
The Prepare command I use :
scripts/prepare-kernel.sh --linux=/home/user/linuxppc --arch=ppc
Does anybody know what this means ?
I Could not find a sim
The missing directory will not harm. Anyhow, if you start
It does harm, as the kernel is prepared only partialy and make
menuconfig crashes.
testing 2.3-rcX now, please use xenomai-2.3-rc3.
I did not know, that this version exists and (!) I did not know where it
resides.
(No hint on
With 2.3-rc3 I get a new problem preparing the kernel :
Can't open perl script
/home/user/xenomai-2.3-rc3/scripts/help_from_kconfig.pl: Datei oder
Verzeichnis nicht gefunden
Any suggestions how I can get around this ?
Thanksa lot
Roderik
-Ursprüngliche Nachricht-
Von: [EMAIL
With 2.3-rc3 I get a new problem preparing the kernel :
Can't open perl script
/home/user/xenomai-2.3-rc3/scripts/help_from_kconfig.pl:
Datei oder Verzeichnis nicht gefunden
Any suggestions how I can get around this ?
Please copy that file from an SVN checkout for now.
This
Does anybody know the actual state of the LinuxTraceTool respectively
the ngLtt ?
Is it applicable for Xenomai (I know, that the tracepoints are already
supported by Xenomai).
Or even better, is anybody already using ngLtt with Xenomai.
Thank you for your information
Roderik
Can anybody tell me about the actual state of using vxworks-skin and posix-skin
simultaneously ? Is it possible, compiling one application with vxWorks-skin
and an other one with the posix-skin and to use/execute these two applications
simultaneously on one system ?
In an earlier posting I
Can anybody tell me about the actual state of using
vxworks-skin and posix-skin simultaneously ? Is it possible,
compiling one application with vxWorks-skin and an other one
with the posix-skin and to use/execute these two applications
simultaneously on one system ?
Yes, feasible.
[EMAIL PROTECTED] wrote:
Is there a standard way for communication between nativ Linux
processes and Xenomai task which ensures that the Xenomai task does
not lose its raltime capability (e.g. can I use Xenomai
(Posix)-queues
within Linux processes ?).
I just need a hint, where I
Just to be sure :
Does the access of a mmaped address (real_mmamp of a device file e.g.
/dev/dualportmemory) force Xenomai to switch to secondary mode ?
I would say yes, as the access of the address probably results into a
read/write of the device file.
Am I right ?
Thanks for your help
Roderik
Is there a standard way for communication between nativ Linux processes
and Xenomai task which ensures that the Xenomai task does not lose its
raltime capability (e.g. can I use Xenomai (Posix)-queues within Linux
processes ?).
I just need a hint, where I can read about it.
Thanks in advance
Dear Gilles,
I admit, the mechanism for allocating all memory of the target is not very
sophisticated. The idea was, that MAXHEAPBLOCKS*MEMORYCHUNKSIZE is much much
more, than memory available (at least with my target (128MB) this is true). I
should have mentioned this in the source code,
Daniel Schnell [mailto:[EMAIL PROTECTED] wrote :
Hi,
I have tried your program on my mpc5200 (Kernel 2.4.25,
Xenomai 2.2.1, 256 MB RAM). Besides it doesn't do much and
also the heap allocation seems not to work, I had no crashes.
Thank you for testing Daniel !
The idea was, to test
Ok. Now the question remains: does this problem still exist
with version
2.2.2 ? The heaps overhead computations have changed recently.
I will try this tomorrow.
___
Xenomai-help mailing list
Xenomai-help@gna.org
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] :
First of all, do we know where the demo precisely faults? In
which heap's memset? We could then analyse how this heap is
being set up in the kernel, if all mappings are done as
expected, if reasonable address are passed to the user, etc.
It
Is there a summary of the advantages of Xenomai vs. RTAI ?
I asked Google and my mail archive about this question but wasn´t very
succesful.
As far as I know, very much which is true for Xenomai is true for RTAI too
(userspace realtime, mixing realtime and linux systemcalls, multiple skins).
I
http://marc.theaimsgroup.com/?l=kernelnewbiesr=1w=2
Sorry Bernhard, but I think this site isn´t very helpful for Xenomai (just 6
messages about Xenomai !?), or did I miss something ?
___
Xenomai-help mailing list
Xenomai-help@gna.org
Is this function implemented in Xeno2.2-rc2 ?
When using it, the linker complains about a undefined reference.
(Is this a a standard POSIX-funktion or a Xenomai extension ?)
Roderik
___
Xenomai-help mailing list
Xenomai-help@gna.org
Can anybody tell me how the POSIX-Libraries are build. I had a look on various
scripts and makefiles but I don´t understand the mechanism.
I am asking, as I have the feeling, my POSIX-Library is not correct.
Although the xeno_posix.o file in the Linux/kernel/xenomai/skins/posix
directory
Gilles Chanteperdrix :
But when I start my application I still get just Linux threads and no
Xenomai
shadow tasks are created. Can anybody give me a hint how I can controll what
kind of thread is created ?
Normally, any thread created with pthread_create has a
shadow. Whether they are
Even worse, if you read the specification, you will see that
pthread_create should never return EINTR. A value of EINTR
means that a suspending call was interrupted by a signal. It
may happen if you are explicitely using signals, or
alternatively when running under gdb, because gdb
I try to port some software, which runs on native Linux, to Xenomai.
As the original SW uses Posix calls, I thought, I just have to compile with
Xenomai-header files, link Xenomai-libraries, use the Xenomai flags as deliverd
from xeno-config and the application will run on Xenomai.
So far so
First of all, I'm not sure if that 8K of stack is enough on
PPC with 2.4, on x86 over 2.6 it isn't. The native skin picks
PTHREAD_STACK_MIN*4 for you by default. Is this too much?
Unless dealing with dozens of
*simple* threads, reducing this makes no sense to me.
?? Greping for
memset should work with Xenomai heaps, I suspect your problem
is rather that the memory is not really allocated until you
memset it, which fails when no memory is available. In this
case, calling memset on memory allocated with malloc should
segfault the same way when the system memory
The are some long delays (approx. 40 secs) around __alloc_pages.
Finally it crashes in memset. With the attached xenomai
patch, which
touches the reserved page once, memset works fine. Let's wait what
Philippe says. I remember that the touch was needed for
RTAI shared memory as
Maybe the task is in fact killed by the OOM killer ? It would
prove that this function is working correctly, since the
killed task is the one that allocates all the memory. Is
there no trace in the logs ?
Could not find a hint in the /var/log/messages from OOM killer. Nothing
that says
Xenomai Version : 2.2-rc2
Skin : native
Kernel : 2.4.25
Arch.: PPC
I try to test my Xenomai system with low memory.
As Linux kills processes which try to allocate more memory than available
(instead of returning just a NULL-pointer !??), I had to use the Xenomai heap
services to allocate
Xenomai Version : 2.2-rc2
Skin : native
Kernel : 2.4.25
Arch.: PPC
I try to allocate as much memory as possible with the functions :
rt_heap_create and
rt_heap_alloc.
(see also Xenomai heap services in this mailing list; see source
attached)
When I try to use the allocated memory with memset,
when a xenomai-task crashs which created some queues (rt_queue_create)
and I try to restart the task the creation of the queues will fail as
the queue still exists (error EEXIST == 17). Is there a possibility to
see which queues exist (I did not find a hint in the /proc/xenomai
directory) and to
when I try to link the posix demo satch.c statically by inserting a
-static option to the LDFLAGS ( %_rt: LDFLAGS= -static $(LDFLAGS_RT) )
I get a lot of Errors about undefined references :
e.g.:
undefined reference to `__wrap_timer_settime'
relocation truncated to fit: R_PPC_REL24
Dear Gurus,
I have compiled ppc(!)-xenomai with debug information (configure
--enable-debug), so far so good (compiling of xenomai itself and it´s
libraries, testsuite etc. was successful).
Bt ..., when compiling the vxWorks-demos (ksrc/skins/vxworks/demos/*.c), I
get an error message
You are right, but who is somebody ? The example definitly does not call any
xchg-function directly. The only thing I did, was to activate debugging and
recompile all the libraries (make clean; configure --debug-enable; make ) and
soon I get this error message when compiling the demo (I don´t
Gilles Chanteperdrix wrote :
libvxworks is generated only when UVM are enabled. You need
to enable building the UVM skin as a kernel module using
menuconfig, and build user-space libraries for the UVM skin
using the configure option --enable-uvm.
Dear Gilles thank you for your support.
thank you for the hint to the vxworks-skin-examples (ksrc/skins/vxworks/demos/)
Unfortunately a new problem occured with these examples :
Executing the Makefile, I get the following Error-Message :
ppc-linux-gcc -o satch satch.c -I. -I~/xenomai-2.1-rc2/_install/include -O2
36 matches
Mail list logo
