Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Petr Cervenka wrote:
>>>>>>> Try instrumenting ksrc/skins/native/syscall.c, __rt_task_create(), to
>>>>>>> identify which spot returns -EFAULT. I can't repro
Jan Kiszka wrote:
> What was the precise brokenness you saw? Also a missing syscall
> argument initialization? Can you easily reproduce the ARM issue?
> Would be
It is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38815
The arm syscalls contain a workaround, I copy the values to some
temporar
Yigal Goldberger wrote:
> Hi all, I'm using kernel 2.6.29.4 with xenomai . I'm getting an
> exception 769 . I'd like to know what this exception means (or hints
> where to look for it ).
Well the meaning of exceptions is dependent on the platform you are
using, so we can not answer without more i
Kolja Waschk wrote:
> Hi,
>
> As a newcomer to Xenomai, I was until now successfully experimenting
> with the native skin. Now that it comes to run an existing application
> that is written for POSIX threads, a few problems show up. The
> pthread_mutex_lock() _always_ returns 1 (EPERM) to me, alth
Kolja Waschk wrote:
> Gilles,
>
> thanks for the prompt answer. Yes, the code is not certainly not useful as a
> skeleton for building anything else...
>
>> initialization has several defects:
>> - setinheritsched(1) does not mean anything (and actually, it would seem it
>
> I copied it literall
Henri Roosen wrote:
> Hi everyone,
>
> I have a basic Xenomai realtime user task which does a read call to a
> basic RTDM driver. The problem is that the realtime task is generating
> pagefaults when the system is under heavy network load even while the
> current and future memory is locked with m
Theo Veenker wrote:
> Hi,
>
> I'm replacing a number of old machines in our lab by new ones with an
> MSI P45 Neo3 mobo. On the new hardware I'm seeing high latencies with
> Xenomai 2.4.8 on kernel 2.6.29.5. The latency thingy reports many
> overruns:
> RTT| 00:00:01 (periodic user-mode task, 10
Felipe Brandão Cavalcanti wrote:
> Hello,
> We are currently trying to install Xenomai (version 2.5rc2) on a Geode GX1
> (PCM 3350 board), kernel 2.6.26 (Debian 5.0).
The Geode is a very very bad choice:
- it is going to disappear any time soon
- its performances in many domains are far from the a
Steve wrote:
> Hi,
>
> Using Xenomai 2.5-rc2 on Linux 2.6.29.4 the following code
> periodically produces a bad result:
>
> clock_gettime(CLOCK_REALTIME, timespec);
>
> Where it assigns a timespec.tv_nsec that is greater than 1000 million.
> If it helps the maximum returned value that i have se
Theo Veenker wrote:
> Gilles Chanteperdrix wrote:
>> Theo Veenker wrote:
>>> Hi,
>>>
>>> I'm replacing a number of old machines in our lab by new ones with an
>>> MSI P45 Neo3 mobo. On the new hardware I'm seeing high latencies with
>>&
Charlton, John wrote:
> I have been using xenomai-2.4.6.1 with linux-2.6.27.7 without problems. We
> have changed our open embedded build to build xenomai within open embedded
> and with recent xenomai/kernel builds I am getting the following error output
> from xeno-test:
>
> latency: failed t
Gilles Chanteperdrix wrote:
> Charlton, John wrote:
>> I have been using xenomai-2.4.6.1 with linux-2.6.27.7 without problems. We
>> have changed our open embedded build to build xenomai within open embedded
>> and with recent xenomai/kernel builds I am getting the follo
Charlton, John wrote:
> Gilles,
>
> Thank you for the reply. Here is the output of ld-linux.so.2. I do not have
> ldd on the open embedded target embedded controller:
> ld-linux.so.2 --list ./latency:
> linux-gate.so.1 => (0xe000)
> libnative.so.1 => /usr/xenomai/lib/libnat
Charlton, John wrote:
> Gilles,
>
> I am using linux kernel 2.6.27.7 and xenomai 2.4.6.1. I get the same results
> below after loading xeno_timerbench module:
>
> I loaded xeno_timerbench module as follows but get the same results:
> modprobe xeno_timerbench
>
> ./latency -t 2:
>
> == Sampling
Charlton, John wrote:
> (snip)
> I-pipe: Domain Xenomai registered.
> Xenomai: hal/i386 started.
> Xenomai: real-time nucleus v2.4.6 (Bamboo) loaded.
> Xenomai: starting native API services.
> Xenomai: starting POSIX services.
> Xenomai: starting RTDM services.
> Xenomai: starting RTAI emulator.
>
Charlton, John wrote:
> Gilles,
>
> Here is another piece of the puzzle, my colleague Jay Snyder who is working
> on the Open Embedded bitbake build for Xenomai found this:
>
>I have narrowed the problem down to
> /usr/xenomai/lib/libpthread_rt.so.1.0.0
>
> I can install the full OE packag
Charlton, John wrote:
> >
> >
> > -Original Message- From: Gilles Chanteperdrix
> > [mailto:gilles.chanteperd...@xenomai.org] Sent: Thursday, August 13,
> > 2009 7:32 AM To: Charlton, John Cc: xenomai-help@gna.org Subject: Re:
> > [Xenomai-help]
Charlton, John wrote:
> >
> >
> > -Original Message-
> > From: Gilles Chanteperdrix [mailto:gilles.chanteperd...@xenomai.org]
> > Sent: Thursday, August 13, 2009 9:17 AM
> > To: Charlton, John
> > Cc: xenomai-help@gna.org
> > Subject: Re
Henry Bausley wrote:
> We are using 2.6.28.8 and xenomai 2.4.7 on a AMCC PowerPC 460EX platform
> and getting
> the following message.
>
> Xenomai Posix skin init: pthread_setschedparam: Resource temporarily
> unavailable
>
>
> It takes quite a while for this to happen. The /proc/xenomai/heap
Hans Søndergaard (HSO) wrote:
> I use objects of type:
>
>
>
> typedef struct object {
>
> RT_MUTEX *rt_lock;
>
> ..
>
> } Object;
>
>
>
> int err = rt_mutex_create (ob->rt_lock, NULL);
>
> printf ("[alloc.c]: rt_mutex_create err: %d; #%d \n", err, __LINE__);
>
>
>
> err = rt_mu
Hans Søndergaard (HSO) wrote:
> I am using Xenomai-2.4.3 together with Linux-2.6.24.
> What does ESRCH mean?
I do not know, I would need to look into the sources, but before any
more search for an issue which may have already been resolved, could you
try xenomai 2.4.8 and see if you get the same p
Kolja Waschk wrote:
> Hi,
>
> I'm trying to detect some remaining unwanted mode switches in an
> application using the native Xenomai app. In one task (that is meant to
> stay in RT domain all the time) I set the T_WARNSW bit and run the
> program via gdb, but - although /proc/xenomai/stat shows s
Henri Roosen wrote:
> We have not much progress tracing the problem so far. But in parallel
> to the tracing we also updated a kernel to the latest xenomai git
> status of the 2.4.8 branch, just to see whether we are not facing
> problems that are solved already.
>
> This version however crashes a
Henri Roosen wrote:
> We have not much progress tracing the problem so far. But in parallel
> to the tracing we also updated a kernel to the latest xenomai git
> status of the 2.4.8 branch, just to see whether we are not facing
> problems that are solved already.
>
> This version however crashes a
Henri Roosen wrote:
> Unfortunately the latency app still crashes from xnshadow_harden with
> this patch.
> Please find attached the updated .config.
Ok. I will work on it tonight.
--
Gilles
___
Xenomai-help
Henry Bausley wrote:
> I used the defaults that came up for my 2.6.28.8 kernel I-pipe 2.4-05.
> I'll rebuild the kernel with 2.6
Ok. Forget it, I can reproduce it. I simply forgot to enable Xenomai
posix skin shared memories in the kernel configuration. The bug does not
happen on head though, only
Gilles Chanteperdrix wrote:
> Henry Bausley wrote:
>> I used the defaults that came up for my 2.6.28.8 kernel I-pipe 2.4-05.
>> I'll rebuild the kernel with 2.6
>
> Ok. Forget it, I can reproduce it. I simply forgot to enable Xenomai
> posix skin shared memories in
Gilles Chanteperdrix wrote:
> Henri Roosen wrote:
>> We have not much progress tracing the problem so far. But in parallel
>> to the tracing we also updated a kernel to the latest xenomai git
>> status of the 2.4.8 branch, just to see whether we are not facing
>> probl
Steve wrote:
> On 07/08/2009, Gilles Chanteperdrix wrote:
>> Steve wrote:
>>> Hi,
>>>
>>> Using Xenomai 2.5-rc2 on Linux 2.6.29.4 the following code
>>> periodically produces a bad result:
>>>
>>> clock_gettime(CLOCK_REALTIME, timespe
Steve wrote:
> Were you going to delay handling this until later, or were you hoping
> it wouldn't be a problem? If it's the former then this is not my
> number one priority at the moment, so from my perspective I can wait
> until the next release candidate / release.
To be completely frank, I wa
Steve wrote:
> On 19/08/2009, Gilles Chanteperdrix wrote:
>> Steve wrote:
>>> Were you going to delay handling this until later, or were you hoping
>>> it wouldn't be a problem? If it's the former then this is not my
>>> number one priority at
Berruer Sébastien wrote:
> I include my code and hope you can point me out what I am doing wrong.
> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
> (PXA255).
Could you try Xenomai 2.4.9?
--
Gilles
___
Steve wrote:
> On 19/08/2009, Gilles Chanteperdrix wrote:
>> Steve wrote:
>>> Were you going to delay handling this until later, or were you hoping
>>> it wouldn't be a problem? If it's the former then this is not my
>>> number one priority at
Berruer Sébastien wrote:
> Hi,
>
>>> I include my code and hope you can point me out what I am doing wrong.
>>> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
>>> (PXA255).
>>
>>Could you try Xenomai 2.4.9?
>
>
>
> I did it yesterday with the version 2.4.9. But, I still i
Berruer Sébastien wrote:
> Hi,
>
> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
> (PXA255).
Could you try Xenomai 2.4.9?
>>>
>>> I did it yesterday with the version 2.4.9. But, I still issue the same
>>> problem with the same code.
>>>
>>
>>Ok. Please keep
Berruer Sébastien wrote:
> Hi,
>
> I'm running a kernel 2.6.28 with Xenomai 2.4.8 on an ARM architecture
> (PXA255).
Could you try Xenomai 2.4.9?
>>>
>>> I did it yesterday with the version 2.4.9. But, I still issue the same
>>> problem with the same code.
>>>
>>
>>Ok. Please keep
Hans Søndergaard (HSO) wrote:
> Thank you to both Gilles and Philippe.
> I followed the advises from you both:
> typedef struct object {
> RT_MUTEX rt_lock;
>..
> } Object;
>
> and used:
> printf("%ld", ob->rt_lock.opaque);
> to see output.
So, what is the result? Did you find the bug?
Christoph Permes wrote:
> Hi,
>
> I have a realtime application running in user space that sometimes terminates
> with a segmentation fault.
> I get a message segfault at 4c4f5200 ip b7cb98d8 sp b7ef7354 error 4 in
> libc-2.7.so[b7c5e000+138000],
> but there is no core file writen, although ul
Berruer Sébastien wrote:
> Hi,
>
> Sorry for the delay, I've issued a problem using the serial line.
>
> As I can see in the Oops trace, the problem is due to my compiler. I'll
> checked my compilation parameters or a newer version of my compiler.
No. The problem is due to the FPU handling. Coud
wangxiyu8237 wrote:
> hello :
>
> I'm porting xenomai to SAMSUMG s3c2410 processor (on SMDK2410) as per
> porting guidelines. In the first phase, applied
> adeos-ipipe-2.6.26-arm-1.12-00 patch found in xenomai-2.4.8 to kernel
> 2.6.26.8 and have implemented required machine specific code. add
David Tao wrote:
> Hi,
>
> I run into a build error when compiling ipipe.c as follows:
>
> CC arch/arm/kernel/ipipe.o
> arch/arm/kernel/ipipe.c: In function '__ipipe_grab_irq':
> arch/arm/kernel/ipipe.c:421: error: implicit declaration of function
> '__ipipe_mach_irq_mux_p'
> make[1]: ***
Berruer Sébastien wrote:
> Hello,
>
> It works for me.
>
> It also solve some problem for me using the latency program in the test
> suite. I suppose it was the same kind of lock.
An issue with the latency test is the first thing you should mention. We
know the latency program is supposed to wor
Berruer Sébastien wrote:
> Hello,
>
>>
>>Could you try something: with the patch still applied, could you try to
>>compile Xenomai user-space without the -msoft-float option?
>
> I've done the compilation of the kernel support with both previous
> patches applied.
>
>
> I've done the compilatio
Christoph Permes wrote:
> Hi,
>
> I'm using rt_printf for debug output. When running tests for 20 hours or
> longer, sometimes I get a segmentation fault.
>
> The backtrace shows:
> #0 0xb7d008d8 in fputs () from /lib/libc.so.6
> #1 0xb7f26f61 in print_buffers () from /usr/xenomai/lib/librtdk.
Imanol Martínez wrote:
> Hello all,
>
> I have installed xenomai 2.4.9 in a linux 2.6.30 kernel. It seems that
> all the boot is done correctly but when reaching the point to access the
> nfs filesystem I get the following error:
>
> <4>[ 32.879389] WARNING: at net/sched/sch_generic.c:226
> dev
Steve wrote:
> 2009/8/20 Gilles Chanteperdrix <mailto:gilles.chanteperd...@xenomai.org>>
>
> Steve wrote:
> > On 19/08/2009, Gilles Chanteperdrix
> <mailto:gilles.chanteperd...@xenomai.org>> wrote:
> >> Steve wrote:
> >&
Imanol Martínez wrote:
> Hello all,
>
> I have installed xenomai 2.4.9 in a linux 2.6.30 kernel. It seems that
> all the boot is done correctly but when reaching the point to access the
> nfs filesystem I get the following error:
>
> <4>[ 32.879389] WARNING: at net/sched/sch_generic.c:226
> dev
Imanol Martínez wrote:
>>Please check that when starting from the configuration where you have
>>the bug, if you disable Xenomai (CONFIG_XENOMAI) and the interrupt
>>pipeline (CONFIG_IPIPE), the system works.
>
> This way it works, but when applying the patch it still does not work, I
> get the sa
Peter Puchwein wrote:
> Hi,
>
> what does a negative latency in the latency-test mean?
>
> RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat
> worst
> RTD| -56.443| -54.519| -33.519| 0| -57.020|
> -28.208
It means that the timer handler ticked before t
Peter Puchwein wrote:
> Gilles Chanteperdrix wrote:
>> Peter Puchwein wrote:
>>> Hi,
>>>
>>> what does a negative latency in the latency-test mean?
>>>
>>> RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat
>>>
Christoph Permes wrote:
> Hi,
>
> I'm working together with Peter on the latency problem.
>
> I have attached our kernel configuration and the boot log to this mail.
>
> We have tried out configuring a latency between 0 and 1 but this
> didn't help.
Ok. Could you try the following patch:
d
Christoph Permes wrote:
> Am Donnerstag, den 27.08.2009, 14:05 +0200 schrieb Gilles Chanteperdrix:
>> Christoph Permes wrote:
>>> Hi,
>>>
>>> I'm working together with Peter on the latency problem.
>>>
>>> I have attached our kernel c
Imanol Martínez wrote:
>>Please check that when starting from the configuration where you have
>>the bug, if you disable Xenomai (CONFIG_XENOMAI) and the interrupt
>>pipeline (CONFIG_IPIPE), the system works.
>
> This way it works, but when applying the patch it still does not work, I
> get the sa
Gilles Chanteperdrix wrote:
> Imanol Martínez wrote:
>>> Please check that when starting from the configuration where you have
>>> the bug, if you disable Xenomai (CONFIG_XENOMAI) and the interrupt
>>> pipeline (CONFIG_IPIPE), the system works.
>> This way it w
Berruer Sébastien wrote:
> Hello,
>
> I'm using Linux 2.6.28 and Xenomai 2.4.8 over an PXA255 processor based
> board.
>
> I can't achieve the compilation process when I enable the I-pipe tracer.
> I've tried some mixed configurations but it always fails with an error.
> I use :
>
> - gcc versi
Berruer Sébastien wrote:
> Hello,
>
>>> I can't achieve the compilation process when I enable the I-pipe tracer.
>>> I've tried some mixed configurations but it always fails with an error.
>>> I use :
>>>
>>> - gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)
>>> - GNU C Library stable release v
Berruer Sébastien wrote:
> I downloaded the toolchain from:
> http://www.codesourcery.com/sgpp/lite/arm/portal/release316
>
> It's the free version but it's supposed to have a Newlib library. Why
> can't I
> find any *.so? I only have *.a files. Must I only statically compile my
> software?
No. T
Berruer Sébastien wrote:
> Hello,
>
>>> I downloaded the toolchain from:
>>> http://www.codesourcery.com/sgpp/lite/arm/portal/release316
>>>
>>> It's the free version but it's supposed to have a Newlib library. Why
>>> can't I
>>> find any *.so? I only have *.a files. Must I only statically compil
Felipe Castro wrote:
> Ok i got ,
>
> When i tried to run latency with 3 ms, it works but i received the message
> [149.437671] Xenomai: Switching display-321 to secondary modo after
> exception #5 from user-spcae at 0x9588 (pid 232)
>
> So , if i put my test software posted in the last message,
Felipe Castro wrote:
> Ok i got ,
>
> When i tried to run latency with 3 ms, it works but i received the message
> [149.437671] Xenomai: Switching display-321 to secondary modo after
> exception #5 from user-spcae at 0x9588 (pid 232)
You have compiled latency with FPU support. Contarily to what I
Philippe Gerum wrote:
> We had a couple of brown paper bag issues in v2.4.9, particularly in the
> interrupt pipeline for the ARM port, but also a time conversion bug
> which basically affects any architecture with high frequency CPUs
> (x86-ers, this one is for you).
A note for users of Xenomai o
dev.chm...@gmx.com wrote:
> Hi,
> My current state is as follows:
> -2.6.30.5 with ipipe running, apm + cpufreq disabled
> -xenomai userland compiled and installed
You do not tell us on what platform. You do not tell us what version of
Xenomai.
>
> When I try to run any of the examples I get 2 n
Rus V. Brushkoff wrote:
> Now as rt_task_create/rt_task_start are deprecated, can anybody
> briefly describe how such driver need to be developed ?
Using the RTDM skin.
--
Gilles
___
Xenomai-help mailing l
Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:
>
> :Rus V. Brushkoff wrote:
> :> Now as rt_task_create/rt_task_start are deprecated, can anybody
> :> briefly describe how such driver need to be developed ?
> :
> :Using the RTDM skin.
>
Rus V. Brushkoff wrote:
> :> :> Now as rt_task_create/rt_task_start are deprecated, can anybody
> :> :> briefly describe how such driver need to be developed ?
> :> :
> :> :Using the RTDM skin.
> :>
> :> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
> :
> :We are talking abou
Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:
>
> :> :> :Using the RTDM skin.
> :> :> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
> :> :We are talking about drivers, then just design your driver as you would
> :&g
Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Philippe Gerum wrote:
>
> :> Next - I do not
> :> understand why the previous model lets the _developer_ itself decide
> :> which of the application tasks will be running in kernel and which will
> :> be running in user space. The current model lef
Felipe Castro wrote:
> Hi,
>
> I'm having some problems to compile with -msoft-float. I'm using xenomai
> in a PXA270 processor.
> So to get a task with 5ms resolution for example, e need to compile with
> -msoft-float parameter right?
>
> My toolchain must be prebuilt to use a soft float point ?
Jan Kiszka wrote:
> Christoph Permes wrote:
>> Hi,
>>
>> I've created a patch that provides a workaround for the segmentation
>> fault:
>>
>> --- a/src/rtdk/rt_print.c2009-05-21 16:34:54.0 +0200
>> +++ b/src/rtdk/rt_print.c2009-09-04 10:09:19.0 +0200
>> @@ -40,6 +40,7 @@
>>
Guvenc Gulce wrote:
> Hi As far as I know an Xenomai RT Task can not call Linux API
> functions without leaving the Xenomai domain.
>
> I was thinking about a generic library/framework which would allow an
> Xenomai RT Task call a Linux API function which would be then
> marshalled over a Posix/Na
Alphan Ulusoy wrote:
> You can always use the Xenomai's _wonderful_ pipe functionality (and
> other task communication services as well) to communicate data back
> and forth between RT (Xenomai user -or- kernel space tasks) and non-RT
> (dedicated linux executables) tasks. This also ensures t
Felipe Castro wrote:
> Spam detection software, running on the system "xenomai.org", has
> identified this incoming email as possible spam. The original message
> has been attached to this so you can view it (if it isn't spam) or label
> similar future email. If you have any questions, see
> the
Guvenc Gulce wrote:
> Guvenc Gulce wrote:
>
Leaving Xenomai domain is not bad per se. The reason why it is bad is
that when re-entering Linux domain, you may have to wait an unbounded
time for Linux to let your task run.
>>> Exactly and that would disturb the real-timeliness of the
Guvenc Gulce wrote:
> rt_net is nice but then all network participants have to use rt_net otherwise
> the realtime communication is not guaranteed on the wire.. in some cases
> the real-timeliness on the wire may not be needed but the determinism
> of the rt-task may still be an issue..
>
> I t
Guvenc Gulce wrote:
> How can I do that with rt_net ? Any pointers, any examples ? rt_net
> documentation
> talks about the hard real-timeliness on the wire.. can I separate rt_net and
> rt_mac ?
> I don't need real-timeliness on the wire why should I pollute my Network
> with the MAC level et
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Christoph Permes wrote:
>>>> Hi,
>>>>
>>>> I've created a patch that provides a workaround for the segmentation
>>>> fault:
>>>>
>
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Christoph Permes wrote:
>>>>> Hi,
>>>>>
>>>>> I've created a patch that provides a workaround for the
Jan Kiszka wrote:
> As you do not care about determinism of the network communication, you
> also do not need RTnet. It would only introduce the risk that non-RT
> network participant overload your box. And this load would show up in
> the RT domain because RTnet would have to handle it.
You can s
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> As you do not care about determinism of the network communication, you
>>> also do not need RTnet. It would only introduce the risk that non-RT
>>> network participant overload your box. An
Felipe Castro wrote:
> Yes , i compiled with msoft-float , anyway I downloaded xenomai 2.4.9.1
> and recompile my kernel,
>
> During the startup it was ok ,
>
> [1.340935] NetWinder Floating Point Emulator V0.97 (double precision)
> [1.344875] I-pipe: Domain Xenomai registered.
> [1.
Felipe Castro wrote:
> i applied the adeos path that comes with xenomai 2.4.9.1 overriding the old
> one that I was using, is that a problem ?
Yes, please start from scratch. And I suspect you may not be running the
kernel you think you are running since it is a 2.6.27, and there is no
I-pipe patc
Felipe Castro wrote:
> i applied the adeos path that comes with xenomai 2.4.9.1 overriding the old
> one that I was using, is that a problem ?
>
> the result is :
>
> r...@vpac270:~$ cat /proc/ipipe/version
> 1.12-02
>
>
> On Wed, Sep 9, 2009 at
Jonathan Haws wrote:
> All,
>
> I am trying to run Xenomai 2.5-rc3 on a 2.6.30.3 kernel from Denx on an AMCC
> 405EX CPU. I have it all installed and ran the testsuite, but the latency,
> switchtest, switchbench, and cyclictest tests fail with these messages:
>
>
> ===
Jonathan Haws wrote:
>>> All,
>>>
>>> I am trying to run Xenomai 2.5-rc3 on a 2.6.30.3 kernel from Denx
>>>
>> on an AMCC 405EX CPU. I have it all installed and ran the
>> testsuite, but the latency, switchtest, switchbench, and cyclictest
>> tests fail with these messages:
>>>
>>>
>> ==
Jonathan Haws wrote:
> Thu Jan 1 00:06:52 UTC 1970
> running: ./run -- -T 120 # switchtest
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Testing FPU check routines...
> r0: 1 != 2
> r1: 1 != 2
> r2: 1 != 2
> r3: 1 != 2
> r4: 1 != 2
> r5: 1 != 2
> r6: 1 != 2
> r7: 1 != 2
> r8: 1 != 2
>
Felipe Castro wrote:
> I'm a little bit lost about this issues cause when running the xenomai
> 2.4.8 with the patch that you send me it worked, but with new version it
> doesn't work.
> Acctually i using the kernel 2.6.27 and i understand what you told me ,
> in version 2.4.9.1 there aren't a patc
Jonathan Haws wrote:
> All,
>
> I am new to Xenomai, so please bear with me.
>
> I have a question regarding creating Makefiles for building Xenomai
> enabled programs. I would like to simply use "xeno-config" to set my
> CFLAGS and LDFLAGS settings in the Makefile.
>
> However, the problem I
Jonathan Haws wrote:
>> Use DESTDIR, that is what it was made for. The makefiles use it
>> when running "make install", and xeno-config prepends it to the
>> directories it returns.
>>
>> So, in a makefile, you woud do:
>>
>> XENO_DESTDIR:=~/eldk/ppc_4xx
>> XENO_CONFIG:=$(XENO_DESTDIR)/usr/loca
Jonathan Haws wrote:
> All,
>
> When I run the xeno-test to test my configuration, I noticed
> something interesting. The test mode "in kernel timer handler" shows
> a negative minimum latency.
>
> Is this typical behavior? It seems like a negative latency is not a
> phyical possibility, though
Flavio de Castro Alves Filho wrote:
> Hello,
>
> I am new with Xenomai and I am having problems in booting a compiled
> kernel into Ubuntu 8.10. I could compile the kernel with the appropriate
> patch, configured grub to load the new kernel. But, when I boot the new
> kernel, it performs all the
Cristian Axenie wrote:
> Hello !
> I've took a snapshot of the xenomai-abe (Comedi port related) git repos
> pointing to the last update and tried it up and it seems that are some
> errors.
Hi,
I will let Alexis answer, but I have a remark: you do not need to
cross-post on the core and help maili
Flavio de Castro Alves Filho wrote:
> Hello,
> Sorry for the delay in the response.
>
> In fact, I believe it is not really a kernel panic,
And you believe wrong. The keyboard leds blinking are the sign of a
kernel panic. Without any doubt.
because the login
> message appears at the screen just
Felipe Castro wrote:
> Hi all !
>
> I found a thread about using GPIO in real time domain with PXA processor,
> and in that thread there are some patch to implement that.
> It's a old thread so, this patch was included in the last adeos-ipipe patch
> ? There are some code to test the GPIO access ?
Flavio de Castro Alves Filho wrote:
> Hello,
>
> I am new with Xenomai and I am having problems in booting a compiled kernel
> into Ubuntu 8.10. I could compile the kernel with the appropriate patch,
> configured grub to load the new kernel. But, when I boot the new kernel, it
> performs all the b
Flavio de Castro Alves Filho wrote:
> Hello,
>
> I could complete here the installation of the Xenomai in my ubuntu.
>
> It was really something related to the display installation. I disable the
> automatic boot of gnome and I could continue the work. Now I have a working
> kernel with xenomai.
James Kilts wrote:
> Philippe,
>
> Indeed it was a problem with __set_irq_handler() not assigning appropriate
> handlers, since this board doesn't fall into any of the existing handler
> categories.
If your PIC needs an EOI, you can define the irq_finish macro in
include/mach/irqs.h like the AT91
James Kilts wrote:
> Philippe,
>
> Indeed it was a problem with __set_irq_handler() not assigning appropriate
> handlers, since this board doesn't fall into any of the existing handler
> categories.
Ok. I had a look at handle_prio_irq in arch/arm/mach-ns9xxx/irq.c. What
this irq handler does is b
Stephen Sinclair wrote:
> Hi,
>
> I am successfully running Xenomai examples now. Just wanted to note
> that it took me a little while to figure out why I was getting this
> error even though I had set up the xenomai group as suggested in the
> quick build guide:
>
> $ ./trivial-periodic
> Xenom
James Kilts wrote:
>> If your PIC needs an EOI, you can define the irq_finish macro in
>> include/mach/irqs.h like the AT91, and use the level handler.
>
> Thanks for the suggestion. I'll give it a try when I have a moment.
>
>
>> Ok. I had a look at handle_prio_irq in arch/arm/mach-ns9xxx/irq.
James Kilts wrote:
>> you should really upgrade to 2.4.9.1.
>
> I'm now running Xenomai 2.4.9.1 on Linux 2.6.28.9.
>
>
I had a look at handle_prio_irq in arch/arm/mach-ns9xxx/irq.c. What
this irq handler does is bad, really bad. If you care about interrupt
latencies, you should re
901 - 1000 of 1937 matches
Mail list logo
