RE: [Xenomai-core] Xenomai v2.0

2005-10-24 Thread Fillod Stephane
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, and as

RE: [Xenomai-core] PATCH: fix ppc64 calibration

2005-10-11 Thread Fillod Stephane
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

RE: [Xenomai-core] PATCH: fix ppc64 calibration

2005-10-12 Thread Fillod Stephane
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, for example. Some tuning might be needed. How

RE: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch

2005-10-17 Thread Fillod Stephane
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):

RE: [Xenomai-core] Testing the adeos-ipipe-2.6.13-ppc-1.0-00.patch

2005-10-19 Thread Fillod Stephane
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 to 30

RE: [Xenomai-core] Xenomai v2.0

2005-10-24 Thread Fillod Stephane
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, and as

[Xenomai-core] [PATCH] check for shm_open/shm_unlink

2007-03-28 Thread Fillod Stephane
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

Re: [Xenomai-core] [PATCH] Adeos for Linux 2.6.19 PowerPC kernels.

2007-05-16 Thread Fillod Stephane
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 this

[Xenomai-core] Xenomai v2.4-rc4: freeze with RTAI skin, fine with other skins

2007-10-22 Thread Fillod Stephane
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

Re: [Xenomai-core] Xenomai v2.4-rc4: freeze with RTAI skin, fine with other skins

2007-10-22 Thread Fillod Stephane
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

Re: [Xenomai-core] Xenomai v2.4-rc4: freeze with RTAI skin, fine with other skins

2007-10-25 Thread Fillod Stephane
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 expected. This one should prevent -EINVAL

Re: [Xenomai-core] Xenomai v2.4-rc4: freeze with RTAI skin, fine with other skins

2007-10-30 Thread Fillod Stephane
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) @@ -1103,7

[Xenomai-core] [PATCH] Wrong -lpthread/-lrt order in testsuite/clocktest/Makefile.am ?

2007-11-08 Thread Fillod Stephane
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

[Xenomai-core] [PATCH] I see negative faults

2007-12-17 Thread Fillod Stephane
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

Re: [Xenomai-core] [PATCH] I see negative faults

2008-01-03 Thread Fillod Stephane
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 it the PF count we are talking about

[Xenomai-core] [PATCH] add numaps to /proc/xenomai/registry/native/heaps/*

2008-03-25 Thread Fillod Stephane
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

Re: [Xenomai-core] [PATCH] glibcism in src/skins/posix/thread.c

2008-04-02 Thread Fillod Stephane
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

Re: [Xenomai-core] [1/9] Support for non cached memory mappings

2008-04-24 Thread Fillod Stephane
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

Re: [Xenomai-core] [1/9] Support for non cached memory mappings

2008-04-24 Thread Fillod Stephane
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 would

Re: [Xenomai-core] [1/9] Support for non cached memory mappings

2008-04-24 Thread Fillod Stephane
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 refills,

[Xenomai-core] (no subject)

2008-06-10 Thread Fillod Stephane
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

Re: [Xenomai-core] [PATCH] Fix stat overruns on 64-bit (was: [Xenomai-help] Kernel panic: not syncing)

2008-08-13 Thread Fillod Stephane
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:

[Xenomai-core] native rt_timer questions

2008-09-03 Thread Fillod Stephane
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

[Xenomai-core] [PATCH] uClibc compile failure

2008-12-08 Thread Fillod Stephane
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

Re: [Xenomai-core] [PATCH] uClibc compile failure

2009-01-20 Thread Fillod Stephane
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 not be