Romain Lenglet wrote:
[..]
>I found a better solution, that could be a replacement for both a
>xenomai.m4 trick, and the xeno-config script: pkg-config.
>http://pkgconfig.freedesktop.org/wiki/
>There are packages for pkgconfig in both Debian and RedHat,
>AFAIK, and surely for all other distribs.
Gilles Chanteperdrix wrote:
> > Romain Lenglet wrote:
> > [..]
> > >I found a better solution, that could be a replacement for both a
> > >xenomai.m4 trick, and the xeno-config script: pkg-config.
> > >http://pkgconfig.freedesktop.org/wiki/
> > >There are packages for pkgconfig in both Debian and
Wolfgang Grandegger wrote:
[...]
>> Load for klatency/latency was ping flooding on FCC (piece of cake),
>> and cache calibrator. IMHO, we can do nastier.
>
>You mean the cache calibrator from http://monetdb.cwi.nl/Calibrator/? I
>tried it on my Ocotea board and it increased the max latency for 25 t
Philippe Gerum wrote:
[..]
>
http://download.gna.org/adeos/patches/v2.6/adeos/ppc/adeos-ipipe-2.6.13-
ppc-1.0-02.patch
Here is the result of tests with version 1.0-02 on e500:
load: ~1 minute ping -f, one run of calibrator chewing 64MiB.
$ cat /proc/ipipe/version
1.0-02
SWITCH without load:
RTH
Philippe Gerum wrote:
[..]
>The last significant change between -00 and -01 is actually the one related to
>the fork pressure (others are cosmetic ones aimed at better sharing stuff with
>the blackfin port). The patch below against -02 removes it.
Here is the result of tests with version 1.0-02+
Hi,
The adeos-ipipe-2.6.13-ppc-1.0-03.patch file in Xenomai-2.0 dist appears
to be broken. The unified diff format is wrong on
include/asm-ppc/ipipe.h,
which breaks include/asm-ppc/mmu_context.h. I've found the problem while
applying the patch on a Linux 2.6.13 kernel.
Line 1664 (no pun :), inste
Jan Kiszka wrote:
>Philippe Gerum wrote:
>> The first stable release of the former "fusion" effort is now
available
>> for download. I have not much more to say, except to thank to
everyone
>> involved with this tireless work since 2001. v2.0 is an important
>> milestone in the life of this project
Heikki Lindholm wrote:
> The old calibration value was from some ancient ppc32 embedded board,
I
> guess. This reflects the awesome power of them ppc64 boxen better :)
Actually, the ppc32 calibration value was from some ancient x86 machine,
I
guess. The same patch could be applied to asm-ppc/cal
Heikki Lindholm wrote:
[..]
> Probably, but there are less than awesome 4xx boards around and I'd
> guess they might even be more likely targets than G4 based machines,
for
> example. Some tuning might be needed.
How many people are using Xenomai (or Fusion) on 4xx ?
What are their typical sched
Wolfgang Grandegger wrote:
>On 10/11/2005 05:11 PM Fillod Stephane wrote:
>> Heikki Lindholm wrote:
>> [..]
>>> Probably, but there are less than awesome 4xx boards around and I'd
>>> guess they might even be more likely targets than G4 based machines,
>
Hi Philippe,
Sorry for the late report, Xenomai appears to work fine on a Freescale
e500
board (MPC8541E) under Linux 2.6.13. Xenomai version was v1.9.9, ie. the
daily
snapshot as of today. Here are some preliminary figures (CPU 800MHz, Bus
133MHz,
32 kiB I-Cache 32 kiB D-Cache, 256 kiB L2):
swi
Wolfgang Grandegger wrote:
[...]
>> Load for klatency/latency was ping flooding on FCC (piece of cake),
>> and cache calibrator. IMHO, we can do nastier.
>
>You mean the cache calibrator from http://monetdb.cwi.nl/Calibrator/? I
>tried it on my Ocotea board and it increased the max latency for 25 t
Philippe Gerum wrote:
[..]
>
http://download.gna.org/adeos/patches/v2.6/adeos/ppc/adeos-ipipe-2.6.13-
ppc-1.0-02.patch
Here is the result of tests with version 1.0-02 on e500:
load: ~1 minute ping -f, one run of calibrator chewing 64MiB.
$ cat /proc/ipipe/version
1.0-02
SWITCH without load:
RTH
Philippe Gerum wrote:
[..]
>The last significant change between -00 and -01 is actually the one related to
>the fork pressure (others are cosmetic ones aimed at better sharing stuff with
>the blackfin port). The patch below against -02 removes it.
Here is the result of tests with version 1.0-02+
Jan Kiszka wrote:
>Philippe Gerum wrote:
>> The first stable release of the former "fusion" effort is now
available
>> for download. I have not much more to say, except to thank to
everyone
>> involved with this tireless work since 2001. v2.0 is an important
>> milestone in the life of this project
Jan Kiszka wrote:
[..]
>> Another thing is the Device I/O handling from user-space. Simple
question: how do I perform read/write operations? In VxWorks, I have for
example following function for reading an I/O register of the board:
> ...
>On x86, iopl() or ioperm() opens in/out to a user space pr
Hi,
I have bumped on a compilation failure of Xenomai 2.3.1 with uClibc.
The shm_open/shm_unlink may not be available, at all.
So here's a basic patch against 2.3.1, FWIW.
diff -u -r1.1.1.5 configure.in
--- configure.in26 Dec 2006 18:39:27 - 1.1.1.5
+++ configure.in28 Mar
Philippe Gerum wrote:
>The other issue is an old bug of mine for this port, specifically we
>need to call irq_enter()/irq_exit() for virtual interrupts too;
>otherwise, softirqs triggered by virtual ones might be delayed until
the
>next hw interrupt comes in. Something like this would do:
Would th
Hi,
As Philippe has been suggesting it, I've been testing v2.4-rc4 on x86
(not favourite board though :) with the RTAI skin (not my favourite skin
too).
Anyway, a legacy RTAI application which was fine with v2.3.2/2.6.20, is
now
freezing the box randomly in the first 30 seconds. On the other han
Hi Gilles,
Thanks for the quick reply.
Gilles Chanteperdrix wrote:
> A case of freeze is a system call called in a loop which fails without
its return value being checked.
I forget to say that the RTAI application is running in kernel land,
because
no port of the RTAI skin has been made yet to u
Philippe Gerum wrote:
>Fillod Stephane wrote:
>> For the legacy RTAI application to load, the attached patch was
>> necessary.
>> The patch against ksrc/skins/rtai/shm.c is somewhat defeating the
>> purpose
>> of a lower XNCORE_PAGE_SIZE, so a better fix might be
Philippe Gerum wrote:
[...]
>This rounding was missing too. We need the previous one for kernel
local
> heaps, and the one below to meet the stricter PAGE_SIZE constraint for
> shareable heaps.
>
>--- ksrc/nucleus/heap.c(revision 3095)
>+++ ksrc/nucleus/heap.c(working copy)
>@@ -110
Hi,
Testing xenomai-2.4-rc5, I've encountered the following link error:
powerpc-linux-uclibc-gcc -Wl,--wrap -Wl,pthread_create
-Wl,--wrap -Wl,mmap -Wl,--wrap -Wl,munmap -o clocktest
clocktest-clocktest.o ../../skins/posix/.libs/libpthread_rt.a -lpthread
-lrt
.../powerpc-linux-uclibc/lib/lib
Dear Xeonmai/I-Pipe maintainers,
Attached is an obvious patch (to me). Part of it is across I-Pipe.
Is there a reason why the counter was declared signed?
--
Stephane
int-faults.patch
Description: int-faults.patch
___
Xenomai-core mailing list
Xenomai
Philippe Gerum wrote:
>Fillod Stephane wrote:
>> Attached is an obvious patch (to me). Part of it is across I-Pipe.
>> Is there a reason why the counter was declared signed?
>>
>
>Well, because the number of faults was not expected to increase
>indefinitely... Is
Dear Xenomai committers,
Here is attached a misc patch which add numaps to
/proc/xenomai/registry/native/heaps/*
I like it :-)
Regards
--
Stephane
numaps.patch
Description: numaps.patch
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.
Hi,
Here's attached a patch working around a glibcism. It is necessary
for uClib environment. The patch is against Xenomai 2.4.3.
Cheers
--
Stephane
posix-skin-glibcism.patch
Description: posix-skin-glibcism.patch
___
Xenomai-core mailing list
Xenom
Gilles Chanteperdrix wrote:
[...]
> Already fixed in trunk, forgot to apply the patch to the v2.4.x
> branch. Note that your patch is slightly incorrect:
> - it runs strstr in an uninitialized string;
> - the result on platforms without _CS_GNU_LIBPTHREAD_VERSION is
> linuxthreads == 0 whereas we r
Gilles Chanteperdrix wrote:
> This patch adds architecture independent support for non cached memory
> mappings. This is necessary on ARM architecture with VIVT cache to
share a
>mapping between kernel and user-space, but may be used in other
situations
> (who knows).
So, the difference between H
Gilles Chanteperdrix wrote:
>> PS: any plan on a H_HUGETLB one of those days?
>
>What would this do ?
Some embedded platforms have small TLB compared to the vm hungriness of
certain real-time tasks. H_HUGETLB would reply on HugeTLB[1] backing for
allocation. Scattered accesses to this memory woul
Gilles Chanteperdrix wrote:
>> Some embedded platforms have small TLB compared to the vm hungriness
of
>> certain real-time tasks. H_HUGETLB would reply on HugeTLB[1] backing
for
>> allocation. Scattered accesses to this memory would benefit in the
lower
>> pressure of minor page-faults/TLB ref
Hi,
Please find attached a patch against 2.4.4 which brings into
documentation the struct rt_heap_info of the native skin. This patch
also allows DMA rt heaps bigger than 128KB (already in trunk).
Cheers
--
Stephane
rt_heap_info_doc.patch
Description: rt_heap_info_doc.patch
_
Jan Kiszka wrote:
>/proc/xenomai/stat output is strange. Probably some type cast error,
> because 18446744071739514846 = 0x8A939FDE and the appropriate
> value perhaps should be 0x8A939FDE = 2324930526.
[...]
Reminds me that other pending patch for /proc/xenomai/faults:
https://m
Hi!
Why rt_timer functions, esp. rt_timer_tsc(), are not inlined in
user-space
(with CONFIG_XENO_HW_DIRECT_TSC) ? Is it because some policy insists
that every library function must have an overridable symbol?
Even a branch is worrisome when doing repetitive micro-measurements.
What about a patch
Hi,
I have bumped on a compilation failure of Xenomai 2.4.6 with uClibc.
The mmap64/ftruncate64 functions may not be available, at all.
So here's an attached patch against 2.4.6, FWIW.
BTW, people stuck with a fascist pthread that lets only superuser use
SCHED_FIFO will need the following patch.
Hi,
I haven't seen a reply to this patch, maybe it has been missed?
https://mail.gna.org/public/xenomai-core/2008-12/msg9.html
---8<---8<---8<---8<---8<---8<
I have bumped on a compilation failure of Xenomai 2.4.6 with uClibc.
The mmap64/ftruncate64 functions may no
36 matches
Mail list logo
