Re: [Xenomai-core] [patch] doc fix in rtdm

2005-10-20 Thread Philippe Gerum
Jan Kiszka wrote: Hi, someone ;) complained about this statement regarding rtdm_task_busy_sleep. I think he is right. Applied, thanks. --- drvlib.c(revision 44) +++ drvlib.c(working copy) @@ -335,7 +335,7 @@ * - Kernel-based task * - User-space task (RT, non-RT) * - *

[Xenomai-core] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]

2005-10-21 Thread Philippe Gerum
Resending here since this is a general project issue. Original Message Subject: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc). Date: Fri, 21 Oct 2005 18:45:59 +0200 From: Philippe Gerum [EMAIL PROTECTED] Organization: Xenomai To: Jan Kiszka

Re: [Xenomai-core] [patch] rtdm without CONFIG_XENO_OPT_PERVASIVE

2005-10-21 Thread Philippe Gerum
Jan Kiszka wrote: Hi, this fixes an unresolved symbol in xeno_rtdm when CONFIG_XENO_OPT_PERVASIVE is switched off. Applied, thanks. Jan Index: skins/rtdm/device.c

Re: [Xenomai-core] [patch] problems with nucleus/types.h

2005-10-21 Thread Philippe Gerum
Jan Kiszka wrote: Hi, after the latest changes in include/nucleus/types.h, I get some warnings during userspace lib compilation on my box: In file included from /usr/src/xenomai/include/nucleus/queue.h:24, from /usr/src/xenomai/include/nucleus/timer.h:24, from

Re: [Xenomai-core] [patch] signedness issues in testsuite

2005-10-21 Thread Philippe Gerum
Jan Kiszka wrote: Fixes gcc-4 warnings. Applied, thanks. Jan Index: testsuite/latency/latency.c === --- testsuite/latency/latency.c (revision 54) +++

[Xenomai-core] Adeos then Xenomai over Blackfin

2005-10-21 Thread Philippe Gerum
FYI, I have uploaded the initial release of Adeos for the Blackfin architecture: http://download.gna.org/adeos/patches/v2.6/adeos/bfin/adeos-ipipe-uc-2.6.12-bfin-1.0-00.patch It is based on the 2.6.12 kernel found in the uClinux-2005R3 distribution, and tested on a BF533 eval board.

Re: [Xenomai-core] EDF or RM scheduler for Xenomai

2005-10-21 Thread Philippe Gerum
Germain Olivier wrote: At the beginning of October I've posted on the RTAI mailing list a question about the development of additional scheduler for RTAI/Fusion. About the pluggable scheduler infrastructure, can you give more details on what you expect ? An implementation in the nucleus that

Re: [Xenomai-core] [PATCH: 0/3] powerpc merge

2005-10-24 Thread Philippe Gerum
Heikki Lindholm wrote: Merge 32- and 64-bit powerpc architectures into a common powerpc arch in anticipation of the similar merge happening in linux kernel (possible in 2.6.15). Amount of shared code between 32- and 64-bit ppc is substantial and I don't see anything changing that. These

Re: [Xenomai-core] problem and solution with adeos-ipipe-2.6.13-ppc-1.0-03.patch

2005-10-24 Thread Philippe Gerum
Fillod Stephane wrote: 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.

Re: [Xenomai-core] problem and solution with adeos-ipipe-2.6.13-ppc-1.0-03.patch

2005-10-24 Thread Philippe Gerum
Aristeu Sergio Rozanski Filho wrote: 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

Re: [Xenomai-core] [bug-reminder] user/kernel space header deps

2005-10-24 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, just to avoid that this issue got lost during the migration to Xenomai: It's still not possible to compile a C++ POSIX program with CFLAGS obtained via xeno-config --posix-ldflags

Re: [Xenomai-core] Re: [Xenomai-help] General Xenomai / RTAI Skin Usage Questions

2005-10-31 Thread Philippe Gerum
Romain Lenglet wrote: - A kernel option that causes Xenomai (or Adeos) to blatantly malfunction or even crash is a freaking BUG, and should be reported asap to the Xenomai-core list or the Adeos-main list. IOW, there is no such thing as options allowed to crash your box with Adeos/Xenomai

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-11-01 Thread Philippe Gerum
Dmitry Adamushko wrote: Hi Jan, I have some code hanging around here which implements IRQ sharing at skin level for an experimental in-house development over Xenomai. The code is smart enough to register an IRQ sharing trampoline handler only in case sharing is actually practiced for

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-11-01 Thread Philippe Gerum
Jan Kiszka wrote: Dmitry Adamushko wrote: On Tuesday 01 November 2005 12:58, you wrote: as cockie to the xnintr_irq_handler(). The analogy is irq_desc_t vs. irqaction structures in Linux. This way, xnintr_irq_handler() can be called from adeos-ipipe layer directly without the [2] layer.

[Xenomai-core] Dev branch 2.1

2005-11-02 Thread Philippe Gerum
A dev branch toward v2.1 has been created. It features a new build system so that Xenomai now follows a split source model, decoupling the kernel space support from the user-space libraries used in accessing the former. It's work in progress, and there is still a lot of things to be done in

Re: [Xenomai-core] [RFC] support for sharing IRQs

2005-11-02 Thread Philippe Gerum
Bernard Dautrevaux wrote: -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Philippe Gerum Envoyé : mardi 1 novembre 2005 18:30 À : Jan Kiszka Cc : xenomai-core Objet : Re: [Xenomai-core] [RFC] support for sharing IRQs Ok, let's go

Re: [Xenomai-core] Dev branch 2.1

2005-11-03 Thread Philippe Gerum
Hannes Mayer wrote: Ciao Philippe! prepare-kernel.sh works well - I'd suggest to ask the user for the 3 needed parameters, instead of supplying them as parameters. e.g. # scripts/prepare-kernel.sh Linux directory: [default: /usr/src/linux] : Adeos-patch: [default: none] : Architecture:

Re: [Xenomai-core] [16550A-PATCH] integer baud rate, type renaming

2005-11-08 Thread Philippe Gerum
Jan Kiszka wrote: Jan Kiszka wrote: Hi all, and another patch: This one changes the rtserial API so that the baud rate can now be provided as an integer instead of the previous low-level encoded value. The baud base of a device is provided as module parameter to the driver on insmod. Turned

Re: [Xenomai-core] [BUG] scheduling order of dying shadow threads

2005-11-08 Thread Philippe Gerum
Jan Kiszka wrote: Hi Philippe, I think this one is for you: ;) Sebastian got almost mad with his CAN driver while tracing a strange scheduling behaviour during shadow thread deletion for several days(!) - and I was right on the way to follow him yesterday evening. Attached is a simplified

Re: [Xenomai-core] [BUG] scheduling order of dying shadow threads

2005-11-08 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi Philippe, I think this one is for you: ;) Sebastian got almost mad with his CAN driver while tracing a strange scheduling behaviour during shadow thread deletion for several days(!) - and I was right on the way to follow him

Re: [Xenomai-core] RT pipes

2005-11-09 Thread Philippe Gerum
Sebastian Smolorz wrote: Hi, I've spotted a -- in my view -- strange behaviour of RT pipes in the native skin. The scenario is as follows: A RT task creates a RT pipe and writes some bytes into it. A NRT counterpart reads from this pipe, but not all bytes. Afterwards, the RT task deletes the

Re: [Xenomai-core] RT pipes

2005-11-09 Thread Philippe Gerum
Philippe Gerum wrote: Sebastian Smolorz wrote: Hi, I've spotted a -- in my view -- strange behaviour of RT pipes in the native skin. The scenario is as follows: A RT task creates a RT pipe and writes some bytes into it. A NRT counterpart reads from this pipe, but not all bytes. Afterwards

Re: [Xenomai-core] Patch for RTDM recvmsg bug

2005-11-12 Thread Philippe Gerum
Sebastian Smolorz wrote: Hi, here's a patch for a bug in skins/rtdm/syscall.c. The msghdr was not copied to user space upon completion of a recvmsg() call if the return value was not equal to zero. But recvmsg shall return the length of the message in bytes (according to IEEE Std 1003.1).

Re: [Xenomai-core] Xenomai homepage

2005-11-14 Thread Philippe Gerum
Jan Kiszka wrote: Hi, just to bring this topic in mind again: what is currently preventing to activate Bruno's nice page as the main Xenomai site? I see no significant features lacking, fine-tuning can still be done later. This project deserves a more representative portal than the Gna site! ;)

Re: [Xenomai-core] [BUG] rt_pipe_flush declaration missing in skins/native/pipe.h

2005-11-14 Thread Philippe Gerum
Ignacio García Pérez wrote: Hi, The subject says it all. Fixed, thanks. PS: please send patches when possible, it's faster to handle for me and less likely to be forgotten in my job queue. TIA, Nacho. ___ Xenomai-core mailing list

[Xenomai-core] Re: [Xenomai-help] printk

2005-11-15 Thread Philippe Gerum
Dmitry Adamushko wrote: ... This cannot happen in async mode, since the output would be buffered and printk() never called on behalf of the preempted handler. let's say at the (*) point void __ipipe_flush_printk (unsigned virq) { char *p =

Re: [Xenomai-core] [pipe.c] hairy synchronization - flush the output queue upon closure

2005-11-18 Thread Philippe Gerum
Dmitry Adamushko wrote: yep, it's a problem since data may be client-dependent. In such a case, for a new client old messages are just irrelevant. And xnpipe_release() cleans up the queus but, well, does it too earlier. so, 1) should xnpipe_open_handler() and xnpipe_close_handler() be called

Re: [Xenomai-core] [pipe.c] hairy synchronization - flush the output queue upon closure

2005-11-18 Thread Philippe Gerum
Philippe Gerum wrote: Dmitry Adamushko wrote: yep, it's a problem since data may be client-dependent. In such a case, for a new client old messages are just irrelevant. And xnpipe_release() cleans up the queus but, well, does it too earlier. so, 1) should xnpipe_open_handler

Re: [Xenomai-core] v2.1 status

2005-11-19 Thread Philippe Gerum
Ignacio García Pérez wrote: I had a first contact with the new build system. I really really don't like the fact it touches my kernel source tree. Besides adeos, I like to keep the kernel source independent of xenomai, because that tree is shared for other projects. At that point, I would

Re: [Xenomai-core] [PATCH] xenomai 2.1 ppc64 i-pipe support

2005-11-20 Thread Philippe Gerum
Heikki Lindholm wrote: Xenomai 2.1: - Add ppc64 I-pipe kernel support Applied, thanks. -- Heikki Lindholm diff -Nru xenomai/include/asm-powerpc/system.h xenomai-devel/include/asm-powerpc/system.h ---

Re: [Xenomai-core] [PATCH] xenomai 2.1 ppc64 build fix

2005-11-20 Thread Philippe Gerum
Heikki Lindholm wrote: Xenomai 2.1: - powerpc/atomic.h lost one 64-bit #ifdef during the merge - ppc64 defines its own atomic mask functions. Applied, thanks. -- Heikki Lindholm diff -Nru

Re: [Xenomai-core] [RFC] define your own pipe heap

2005-11-22 Thread Philippe Gerum
Jan Kiszka wrote: Jan Kiszka wrote: ... A patch says more than thousand words. ;) As a first approach, I picked the second variant and implemented a new function called rt_pipe_setpool. I also had to extend rt_pipe_alloc and rt_pipe_free so that the right pool is used by them. I thought

Re: [Xenomai-core] fusion and its stack limit

2005-11-25 Thread Philippe Gerum
Marco Cavallini wrote: Hi, with fusion-0.9.1 and VxWorks skin I am testing the creation of 255 different tasks each with a different priority level from 0 to 254. I am facing to a problem creating more than 12 tasks with taskSpawn after creating 12 tasks the program fails into thread.c in

Re: [Xenomai-core] [PATCH] private heaps for native pipes

2005-11-25 Thread Philippe Gerum
Jan Kiszka wrote: Hi, this is basically the last version of my rt_pipe_create-ext patch to add private, user-resizeable heaps to native pipes. Joerg has tested this patch successfully under the 2.1 trunk, and I added a ChangeLog snippet. Attached both 2.0.x and 2.1.x patches - please apply at

[Xenomai-core] Re: Xenomai on PPC

2005-11-28 Thread Philippe Gerum
Andrea Iudiciani wrote: Hi all, hi Paolo, I would like to know if is scheduled the porting of Xenomai to PPC-based platform and, if the answer is affermative, when. I'm very interested about that. best regards, It's already there:

Re: [Xenomai-core] [PATCH] NMI-watchdog related fixes

2005-11-28 Thread Philippe Gerum
Jan Kiszka wrote: Hi, some fixes related to warnings when you switch on Xenomai's NMI watchdog. Applied, thanks. Jan Index: include/asm-i386/system.h

Re: [Xenomai-core] Latest snapshot (182) not compiling (kernel)

2005-11-28 Thread Philippe Gerum
Panagiotis Issaris wrote: Hi, I'm also having issues compiling the latest Xenomai tree. Mm, dot-config would be great. TIA, On 11/25/05, *Ignacio García Pérez* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I dunno what's changed, but I updated my xenomai snapshot to

Re: [Xenomai-core] Latest snapshot (182) not compiling (kernel)

2005-11-28 Thread Philippe Gerum
Panagiotis Issaris wrote: Hi Philippe, On 11/28/05, *Philippe Gerum* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Panagiotis Issaris wrote: Hi, I'm also having issues compiling the latest Xenomai tree. Mm, dot-config would be great. TIA, Sorry

Re: [Xenomai-core] [RFC] latency tracing

2005-11-28 Thread Philippe Gerum
Jan Kiszka wrote: Hi, as I'm lazy, er busy, I'm pushing this idea into public instead of hacking a patch on my own: wouldn't it be nice to have something like the latency backtrace of PREEMPT_RT also in Xenomai? Yes; we would had saved a lot of time with a precise debug instrumentation in

Re: [Xenomai-core] Coding style

2005-11-29 Thread Philippe Gerum
Ignacio García Pérez wrote: Hi, Some time ago someone mentioned the current xenomai coding style, and that maybe it would be a good idea to change it to something more standard. A good place to start would be turn the tabs into spaces to eliminate editor configuration dependency. Anyway, my

Re: [Xenomai-core] rt_intr_enable() requierd after rt_intr_create

2005-11-29 Thread Philippe Gerum
Ignacio García Pérez wrote: Hi, I noticed that when an interrupt object is created using rt_intr_create(), it is created disabled, and a call to rt_intr_enable() is necessary for the ISR to be called. Question is: is this the expected behaviour?. Yes. You don't necessarily want to take

Re: [Xenomai-core] Latest snapshot (182) not compiling (kernel)

2005-11-29 Thread Philippe Gerum
Panagiotis Issaris wrote: Hi Jan, On 11/28/05, *Jan Kiszka* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: ... reference to `__raw_read_unlock' kernel/built-in.o: In function `schedule_event': /usr/local/src/linux-2.6.14/kernel/xenomai/nucleus/shadow.c:152:

Re: [Xenomai-core] [patch] fix SMI and proc cleanup

2005-11-30 Thread Philippe Gerum
Kiszka [EMAIL PROTECTED] + + * ksrc/arch/i386/smi.c: Remove __initdata from rthal_smi_pci_tbl + to make table persistent. + + * ksrc/nucleus/module.c (__xeno_sys_exit): Reorder proc-fs + cleanup to avoid stalled entries. + 2005-11-29 Philippe Gerum [EMAIL PROTECTED

Re: [Xenomai-core] [bug] don't try this at home...

2005-11-30 Thread Philippe Gerum
Jan Kiszka wrote: Jan Kiszka wrote: Hi Philippe, I'm afraid this one is serious: let the attached migration stress test run on likely any Xenomai since 2.0, preferably with CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm trying to set up a serial console now).

Re: [Xenomai-core] [bug?] calling xnpod_delete_thread after self-termination

2005-11-30 Thread Philippe Gerum
Jan Kiszka wrote: Hi all, as the subject already says: I face some warning of the nucleus (with XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a thread which has already terminated itself by leaving the thread function. Is this double-deletion illegal? Or is it a

Re: [Xenomai-core] [patch] minor doc clarification

2005-11-30 Thread Philippe Gerum
(rtdm_task_join_nrt): Clarify doc. + 2005-11-30 Philippe Gerum [EMAIL PROTECTED] * ksrc/nucleus/pod.c (xnpod_delete_thread): Prevent double-deletion. @@ -10,7 +14,7 @@ * ksrc/arch/powerpc/patches: Upgrade to Adeos 2.4.25-denx-0.9-04, 2.6.10-ppc64-r3.patch. -2005-11-30 Ignacio García Pérez

Re: [Xenomai-core] [PATCH] Xenomai 2.1: Add SMP timer support for powerpc

2005-12-07 Thread Philippe Gerum
Heikki Lindholm wrote: Add SMP timer support code for the powerpc arch in Xenomai 2.1. Still a bit rough, but I'll clean it up as I go. Compiled and tested on G5 UP, SMP (I-pipe 2.6.14 0.9-02) and G4 UP (I-pipe 2.6.14 1.0-07). Doesn't seem to break anything. On a G5, SMP seems to bring a

Re: [Xenomai-core] [bug] don't try this at home...

2005-12-09 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Jan Kiszka wrote: Hi Philippe, I'm afraid this one is serious: let the attached migration stress test run on likely any Xenomai since 2.0, preferably with CONFIG_XENO_OPT_DEBUG

Re: [Xenomai-core] [RFC] rt_task_join?

2005-12-09 Thread Philippe Gerum
Jan Kiszka wrote: Jan Kiszka wrote: Hi all, we ran into some issue where we have to wait on the termination of a native real-time userspace thread during cleanup. This can be done in a custom way of course, either via some polling on a flag or by blocking on a standard posix semaphore that

Re: [Xenomai-core] [bug?] set pthread stack size broken

2005-12-09 Thread Philippe Gerum
Jan Kiszka wrote: Jan Kiszka wrote: Jan Kiszka wrote: Hi, something for the night: Can someone explain why normal pthreads can be restricted to initially use only the stack size provided via pthread_attr_setstacksize() while any rt-mapped thread (posix and native) refuse to accept this? For

Re: [Xenomai-core] [bug] user memory leakage on rt_task_delete

2005-12-09 Thread Philippe Gerum
Jan Kiszka wrote: Hi all, during my ongoing search for the init/cleanup issue of shadow threads, I stumbled over another problem: Deleting a userspace native thread that is blocked in primary mode does not let the NPTL clean up all resources allocated in userspace. If you plan to do some

Re: [Xenomai-core] [bug] user memory leakage on rt_task_delete

2005-12-09 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi all, during my ongoing search for the init/cleanup issue of shadow threads, I stumbled over another problem: Deleting a userspace native thread that is blocked in primary mode does not let the NPTL clean up all resources allocated

Re: [Xenomai-core] [PATCH] rt_task_join

2005-12-09 Thread Philippe Gerum
Jan Kiszka wrote: Hi, this is a cleaned up and documented version of my rt_task_join proposal. Please apply. Applied, thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [bug] vfree/kfree under hard IRQ locks

2005-12-11 Thread Philippe Gerum
Jan Kiszka wrote: Hi, I happened to stumble over this comment[1]. It made me curious, especially as it is not totally correct (the loop is executed in IRQ-off context, thus it *is* timecritical). Critical should be understood here in the sense that IRQs are off while the loop workload is

Re: [Xenomai-core] [bug] vfree/kfree under hard IRQ locks

2005-12-11 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, I happened to stumble over this comment[1]. It made me curious, especially as it is not totally correct (the loop is executed in IRQ-off context, thus it *is* timecritical). Critical should be understood here in the sense

Re: [Xenomai-core] Extensible heaps - needed for the future?

2005-12-11 Thread Philippe Gerum
Jan Kiszka wrote: Hi, I noticed that xnhead_extend() is not used at the moment [1], thus the whole extent management is redundent for now. Are there plans to use it in the future? Should we keep this feature? I'm asking as I still have the idea in my head of breaking up the heap service and

Re: [Xenomai-core] [bug] vfree/kfree under hard IRQ locks

2005-12-11 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, I happened to stumble over this comment[1]. It made me curious, especially as it is not totally correct (the loop is executed in IRQ-off context, thus it *is* timecritical

Re: [Xenomai-core] [bug] vfree/kfree under hard IRQ locks

2005-12-11 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, I happened to stumble over this comment[1]. It made me curious, especially as it is not totally correct (the loop is executed in IRQ

Re: [Xenomai-core] [bug] don't try this at home...

2005-12-16 Thread Philippe Gerum
Philippe Gerum wrote: Jan Kiszka wrote: Jan Kiszka wrote: Hi Philippe, I'm afraid this one is serious: let the attached migration stress test run on likely any Xenomai since 2.0, preferably with CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm trying to set up a serial

Re: [Xenomai-core] [bug] don't try this at home...

2005-12-16 Thread Philippe Gerum
Philippe Gerum wrote: Philippe Gerum wrote: Jan Kiszka wrote: Jan Kiszka wrote: Hi Philippe, I'm afraid this one is serious: let the attached migration stress test run on likely any Xenomai since 2.0, preferably with CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm

Re: [Xenomai-core] [bug] don't try this at home...

2005-12-16 Thread Philippe Gerum
Philippe Gerum wrote: Philippe Gerum wrote: Philippe Gerum wrote: Jan Kiszka wrote: Jan Kiszka wrote: Hi Philippe, I'm afraid this one is serious: let the attached migration stress test run on likely any Xenomai since 2.0, preferably with CONFIG_XENO_OPT_DEBUG on. Will give a nice crash

Re: [Xenomai-core] [patch] fix posix userspace headers

2005-12-16 Thread Philippe Gerum
Jan Kiszka wrote: Good evening, this patch is required to compile some posix userspace program against 2.1 SVN. Jan Applied, thanks. Index: include/posix/signal.h

Re: [Xenomai-core] [doc-patch] rt_task_create user stack size

2005-12-16 Thread Philippe Gerum
Jan Kiszka wrote: Hi, Please apply this, the statement is no longer valid. Applied, thanks. --- ksrc/skins/native/task.c(revision 243) +++ ksrc/skins/native/task.c(working copy) @@ -117,7 +117,7 @@ * * @param stksize The size of the stack (in bytes) for the new * task. If

Re: [Xenomai-core] [PATCH] debug_maxlat as module_param

2005-12-17 Thread Philippe Gerum
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi, this tiny patch exports the NMI watchdog's threshold as module parameter debug_maxlat of xeno_hal. This means that one can either override the value via a kernel parameter or in sysfs/modules/xeno_hal/parameters

Re: [Xenomai-core] [PATCH] fix typos around 16550A driver

2005-12-17 Thread Philippe Gerum
Jan Kiszka wrote: Hi, these are two typo fixes for the serial driver. One of them should have broken kernel 2.4 compilation for this driver, the other is cosmetic Applied, thanks. Jan PS: What about this splnone in gatekeeper_thread(), BTW. Still needed? Nope. Fixed. ---

Re: [Xenomai-core] [PATCH] fix 16550A for 2.4

2005-12-18 Thread Philippe Gerum
Jan Kiszka wrote: Hi, it takes more to get the serial driver running on 2.4 kernels. The current trunk version does not let the user set any module parameter (effectively commented out). This patch fixes it. Applied, thanks. Jan

Re: [Xenomai-core] [bug] don't try this at home...

2005-12-18 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: ... Fixed. The cause was related to the thread migration routine to primary mode (xnshadow_harden), which would spuriously call the Linux rescheduling procedure from the primary domain under certain circumstances. This bug only triggers on preemptible

Re: [Xenomai-core] [bug] don't try this at home...

2005-12-18 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: ... Fixed. The cause was related to the thread migration routine to primary mode (xnshadow_harden), which would spuriously call the Linux rescheduling procedure from the primary domain under certain

[Xenomai-core] Xenomai v2.0.2

2005-12-19 Thread Philippe Gerum
Here is v2.0.2. This is mainly a bug fix release, which includes the patches contributed during the last six weeks. Few changes, but all over the place: - RTDM fixes and updates - 16550 driver fixes - nucleus fixes (message pipes and shadow management mainly) - VxWorks errno fix -

Re: [Xenomai-core] [RFC] in-kernel timer benchmark

2005-12-22 Thread Philippe Gerum
Jan Kiszka wrote: Hi all, this is fully working proposal how to re-enable in-kernel timer latency benchmarks. More precisely, it adds a new RTDM device rtbenchmarkX (and also a new RTDM class) which can execute either a kernel task or timer periodically. The benchmark device generates all the

Re: [Xenomai-core] [PATCH] load librtdm without xeno_rtdm

2005-12-28 Thread Philippe Gerum
Jan Kiszka wrote: Hi, as suggested in an earlier mail, here is a patch that - as I think - improves the behaviour of librtdm. It will let applications start even if the kernel services of RTDM are not available. Instead, -ENODEV or -EAFNOSUPPORT will be returned in this case when the user tries

Re: [Xenomai-core] [rt shared irqs] ipipe-related changes (draft)

2005-12-28 Thread Philippe Gerum
Hi Dmitry, Dmitry Adamushko wrote: Hi everybody, the enclosed patches (the first version, hence it's still raw) are supposed to build the basis needed on the ipipe layer for adding support of real-time shared interrupts. As a side effect, the irq_trampoline() layer has been eliminated and the

Re: [Xenomai-core] [PATCH] I-pipe hosted tracing service

2005-12-28 Thread Philippe Gerum
Hi Jan, Jan Kiszka wrote: Hi all, as a late Christmas gift I would like to roll out a probably quite useful instrumentation tool: This is the PREEMPT_RT-inspired I-pipe tracing service! The core ipipe_trace.patch-v4 should apply cleanly against 2.6.14 kernels with ipipe-1.0-12, the

[Xenomai-core] Re: [PATCH] ipipe-tracer-v5

2005-12-28 Thread Philippe Gerum
Jan Kiszka wrote: Hi Philippe, this is a revised version of the tracer patch, addressing your concerns hopefully in the right way. Changes since the previous release: * move __ipipe_init_trace_proc() declaration to linux/ipipe.h * define __BUILTIN_RETURN_ADDRESSx in linux/ipipe.h unless some

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

2005-12-28 Thread Philippe Gerum
Hannes Mayer wrote: Hi Jan! Jan Kiszka wrote: Hannes Mayer wrote: I checked out xeno.trunk just a few minutes ago. With kernel 2.4.32, kernel compilation fails with this: mq.c: In function `mq_notify': mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use in this function) mq.c:475: error:

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

2005-12-28 Thread Philippe Gerum
Philippe Gerum wrote: Hannes Mayer wrote: Hi Jan! Jan Kiszka wrote: Hannes Mayer wrote: I checked out xeno.trunk just a few minutes ago. With kernel 2.4.32, kernel compilation fails with this: mq.c: In function `mq_notify': mq.c:475: error: `SIGEV_SIVNAL' undeclared (first use

Re: [Xenomai-core] [PATCH] ipipe-tracer-v5

2005-12-29 Thread Philippe Gerum
Jan Kiszka wrote: Jan Kiszka wrote: --- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig2005-11-24 23:10:21.0 +0100 +++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28

Re: [Xenomai-core] 2.4.32 compilation error + old timer example problem

2005-12-29 Thread Philippe Gerum
Hannes Mayer wrote: Jan Kiszka wrote: [...] Yea, maybe that periodic timer mode is not compiled in and rt_timer_start fails in your original example. I think it's off by default now. Yeah, got it! Sorry for not supplying error code earlier! In Xeno source: int xnpod_start_timer (u_long

Re: [Xenomai-core] [PATCH] fixing modprobe hint in libs

2005-12-29 Thread Philippe Gerum
Jan Kiszka wrote: Hi, this patches fixes the hint a user sees when trying to start some RT-application without the related core service being available. Might be frustrating for a newbie if the suggested command fails... Applied, thanks. Jan

Re: [Xenomai-core] autostart timer, rt_timer_start/stop

2005-12-29 Thread Philippe Gerum
Jan Kiszka wrote: Stefan Kisdaroczi wrote: Hi, cant the timer be started by default ? The current state (2.0.1) seems to lead to the following scenario: 1) Every app calls rt_timer_start() 2) If you call rt_timer_stop you can hurt other rt-apps, so dont call it 3) As some apps dont stop

Re: [Xenomai-core] [bug] vfree/kfree under hard IRQ locks

2005-12-30 Thread Philippe Gerum
Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, I happened to stumble over this comment[1]. It made me curious, especially as it is not totally correct

[Xenomai-core] I-pipe + latency tracing patch

2005-12-30 Thread Philippe Gerum
I've just rolled out two patches, the first issue of the 1.1 series for x86, and the accompanying tracer patch contributed by Jan Kiszka and Luotao Fu. With the latter patch, the I-pipe shall trace the longest stalled path of the domain with the highest priority. Apply them in that order:

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

2005-12-30 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: I've just rolled out two patches, the first issue of the 1.1 series for x86, and the accompanying tracer patch contributed by Jan Kiszka and Luotao Fu. With the latter patch, the I-pipe shall trace the longest stalled path of the domain with the highest

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

2005-12-30 Thread Philippe Gerum
Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: I've just rolled out two patches, the first issue of the 1.1 series for x86, and the accompanying tracer patch contributed by Jan Kiszka and Luotao Fu. With the latter patch, the I-pipe shall trace the longest stalled path

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

2005-12-31 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: I've just rolled out two patches, the first issue of the 1.1 series for x86, and the accompanying tracer patch contributed by Jan Kiszka and Luotao Fu. With the latter patch, the I-pipe shall trace

[Xenomai-core] Re: [PATCH, RFC] nucleus:shared irq and possible ipipe problem

2005-12-31 Thread Philippe Gerum
Dmitry Adamushko wrote: Hi everybody, I have got a few synch-related problems while adding the code for supporting the rt shared irqs to the nucleus layer. But at first let's take a look at some adeos code that, well, possibly has the same problem. let's say the primary domain is

[Xenomai-core] Xenomai v2.1-rc1

2006-01-02 Thread Philippe Gerum
So new that the paint is still wet, here is the first candidate release of the upcoming 2.1 series. The major changes since v2.0.x are as follows: * New build system which allows to compile Xenomai statically into the kernel image, and ensures proper decoupling between kernel and user-space

Re: [Xenomai-core] [PATCHES] various fixes

2006-01-02 Thread Philippe Gerum
Jan Kiszka wrote: Hi again, I would like to remind of the following three patches: * rtdm-excl-dev.patch - RTDM fix for bug in opening of exclusive devices (both 2.0 and 2.1) Merged. * rtdm-nrt-close.patch - don't permit RTDM devices without NRT closure handlers Merged. *

Re: [Xenomai-core] [PATCH] in-kernel timer benchmark -v3

2006-01-02 Thread Philippe Gerum
Jan Kiszka wrote: Happy New Year everyone! Hope you all survived the turn of the year without complications. ;) Nearly buried alive in patches, but this is hardly a complication. I would like to start with a new patch round. The first one is a revised and extended version of the earlier

[Xenomai-core] Re: xenomai prefix in RTDM userspace includes

2006-01-04 Thread Philippe Gerum
Jan Kiszka wrote: Hi, the current RTDM profile headers (so far only rtserial.h and rtbenchmark.h) suffer from the xenomai prefix in the include path. This was introduced with 2.1. An example: rtserial.h contains #include xenomai/rtdm/rtdm.h which is fine in kernel space but requires that - in

Re: [Adeos-main] Re: [Xenomai-core] I-pipe + latency tracing patch

2006-01-05 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: I've just rolled out two patches, the first issue of the 1.1 series for x86, and the accompanying tracer patch contributed by Jan Kiszka and Luotao Fu

[Xenomai-core] Re: [PATCH] latency tracer update

2006-01-05 Thread Philippe Gerum
Jan Kiszka wrote: Hi again, here comes the first update of the new latency tracer. arch/i386/kernel/entry.S | 27 +++ arch/i386/kernel/ipipe-root.c |4 include/asm-i386/system.h | 70 + include/linux/ipipe_trace.h |3 kernel/ipipe/Kconfig | 18 ++

Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch

2006-01-05 Thread Philippe Gerum
Hi Jim, Jim Cromie wrote: hi Phillipe, everyone, happy 06 ! Bugfree 06? Nah, just kidding... Out of curiosity, I applied adeos-ipipe-2.6.14-i386-1.1-01.patch on top of 15. the rejects were small, and simple enough looking, that even a lazy sod like myself might manually fix them, so I

Re: [Xenomai-core] Re: [PATCH, RFC] nucleus:shared irq and possible ipipe problem

2006-01-05 Thread Philippe Gerum
Dmitry Adamushko wrote: err... I have to orginize some issues next few days so I'll be out of my notebook. Then I'll finilize the ipipe-irq-related patch so to be ready for the .01 version. Meanwhile, I have finished merging the shared IRQ infrastructure into the Adeos codebase for all

[Xenomai-core] Re: [Adeos-main] Re: [PATCH] latency tracer update

2006-01-06 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi again, here comes the first update of the new latency tracer. arch/i386/kernel/entry.S | 27 +++ Is there any good reason to patch the callers of __ipipe_handle_irq instead of instrumenting the callee directly

[Xenomai-core] Re: Oops, I broke something

2006-01-06 Thread Philippe Gerum
Jan Kiszka wrote: Hi Philippe, my RTDM header optimisation broke the compilation of testsuite/latency. I need an extra link for the userspace compilation inside xeno now. Please apply this patch --- configure.in(Revision 372) +++ configure.in(Arbeitskopie) @@ -348,6 +348,8 @@

[Xenomai-core] Re: Oops, I broke something

2006-01-06 Thread Philippe Gerum
Jan Kiszka wrote: Hi Philippe, my RTDM header optimisation broke the compilation of testsuite/latency. I need an extra link for the userspace compilation inside xeno now. Please apply this patch --- configure.in(Revision 372) +++ configure.in(Arbeitskopie) @@ -348,6 +348,8 @@

Re: [Xenomai-core] Re: Oops, I broke something

2006-01-06 Thread Philippe Gerum
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Jan Kiszka wrote: But this raised the question to me again if we really need the xenomai prefix for all the skin headers /from within xenomai/. Why not doing the same linking dance for the other skins as well? Or do you also prefer

Re: [Xenomai-core] Problem with #define uint i

2006-01-06 Thread Philippe Gerum
Wolfgang Grandegger wrote: Hallo, when trying to build RTnet with Xenomai and Linux 2.4.25 for PowerPC, I stumbeld over the following problem: In linuxppc_2_4_devel/include/asm-generic/xenomai/wrappers.h there is defined: #define ulong i #define uint i This makes trouble when a

Re: [Xenomai-core] Re: Oops, I broke something

2006-01-06 Thread Philippe Gerum
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Jan Kiszka wrote: But this raised the question to me again if we really need the xenomai prefix for all the skin headers /from within xenomai/. Why not doing the same linking dance for the other skins as well? Or do you also prefer

  1   2   3   4   5   6   7   8   9   10   >