Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards

Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a comparison with RTAI 3.0r5

Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards

Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high end covering a worst case latency range from 25 to 225 us. It also includes a

Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards

Wolfgang Grandegger wrote: On 10/18/2005 01:44 PM Philippe Gerum wrote: Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high

Re: [Xenomai-core] Xenomai and gdbserver

Steven Seeger wrote: I use remote debug with fusion/2.6.13, but I am using fusion from svn. Also, there are bugs. One I have found recently is that if a task is created with T_SUSP and then you start stepping through the code, the task seems to start up on its own somehow. Weird. Last time you

Re: [Xenomai-core] Xenomai and gdbserver

Marco Cavallini wrote: Hi I wonder if someone has been able to perform a remote debug with xenomai/fusion. I have problems debugging fusion-0.9.1 programs with kernel-2.6.12.2 and Fedora Core 2 gdb-6.0 When i run GDB chain and step into rt_task_create(...), GDB prompts "[1]+ Stopped

Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards

Wolfgang Grandegger wrote: On 10/18/2005 01:44 PM Philippe Gerum wrote: Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various embedded PowerPC boards using MPC 8xx and AMCC 4xx processors, from low to high

Re: [Xenomai-core] Xenomai latency tests on various PowerPC boards

Wolfgang Grandegger wrote: On 10/18/2005 08:14 PM Philippe Gerum wrote: Wolfgang Grandegger wrote: On 10/18/2005 01:44 PM Philippe Gerum wrote: Philippe Gerum wrote: Wolfgang Grandegger wrote: Hallo, attached you will find the results of Xemonai latency measurements on various

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

Fillod Stephane wrote: 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 m

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

Philippe Gerum wrote: Fillod Stephane wrote: 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

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

Fillod Stephane wrote: 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

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

Fillod Stephane wrote: 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

Re: [Xenomai-core] Autotools versions

Heikki Lindholm wrote: Hello, To whoever knows: What versions of the various autotools are used to generate the (svn) makefiles at the moment? o autoconf 2.59 o automake 1.9.5 o aclocal 1.9.5 o libtool 1.5.6 We always document this in the README.INSTALL (see 1.6). -- Heikki Lindholm

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

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) * - * Reschedu

[Xenomai-core] Re: [Patch] Anonymous (NULL-named) objects from user-space

Dmitry Adamushko wrote: Hi, anonymous objects (name == NULL) from user-space get registered under unique names, - which is a string representation of the object's kernel-space address, - but remain not-exported via the /proc interface. Applied (fixing the comment), thanks. Not tested with

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

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 T

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

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

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

Jan Kiszka wrote: Fixes gcc-4 warnings. Applied, thanks. Jan Index: testsuite/latency/latency.c === --- testsuite/latency/latency.c (revision 54) +++ t

Re: [Xenomai-core] [packaging] Proposal of split source code organization

Romain Lenglet wrote: Hi, Here is a proposal of reorganization of the files in Xenomai, to make packaging easier. I have moved all the files, and the resulting hierarchy of directories in in the attached dirs.txt, and the contained files in allfiles.txt. The GNUmakefiles, etc. are still miss

[Xenomai-core] Adeos then Xenomai over Blackfin

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. Functionall

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

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] [Fwd: Re: [Xenomai-help] timeout in native API calls (cond, sem, mutex, etc).]

Dmitry Adamushko wrote: On Friday 21 October 2005 19:35, Philippe Gerum wrote: Actually, there is a more general problem with the current coding style used throughout the code base: it's mine, it's not that standard, then what's standard in this case? By standard, I mean t

[Xenomai-core] Xenomai v2.0

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 such, it paves the way to the seamlessl

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

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 patches

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

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. Li

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

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 2.6

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

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". This is due to the fact th

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

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 --pos

Re: [Xenomai-core] [patch] RTDM abstraction for priority direction

Jan Kiszka wrote: Hi, it turned out that it is useful to abstract the priority increment/decrement by one level at the RTDM layer - for systems that use a different scheme compared to POSIX or Xenomai (so far only classic RTAI). Please apply. Applied, thanks. Jan -

Re: [Xenomai-core] [patch] serial driver fixes/improvements

Jan Kiszka wrote: Hi, this patch improves the behaviour of xeno_16550A on RTSER_RTIOC_EVENT_WAIT. In case it is invoked from non-RT, the driver tries to trigger an automatic switch-back to RT via returning ENOSYS. The patch also fixes another remaining issue about the right context when calling

Re: [Xenomai-core] [patch] clearify 16550A readme

Jan Kiszka wrote: Hope this improves the understandability. Applied, thanks. Jan Index: drivers/16550A/README === --- drivers/16550A/README (Revis

[Xenomai-core] UVM bugfix for RTAI/fusion and Xenomai 2.0

People depending on the UVM support as available with RTAI/fusion should apply the following patch (against v0.9.1); it solves a serious bug which usually bites at thread creation time. The bug affects Xenomai 2.0 as well, so this fix will be part of Xenomai 2.0.1. --- fusion-0.9.1/skins/uvm

Re: [Xenomai-core] [RFC] overcome kernel headers in userspace

Jan Kiszka wrote: Hi, I started some first proof-of-concept to get rid of all kernel header inclusions in user space. Here is a patch which so far only addresses asm-inclusion and the i386 architecture. It may have side effects, I didn't tested it (except compilation). Anyway, I hope to hear so

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

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 because

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

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

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

Jan Kiszka wrote: 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 pra

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

Dmitry Adamushko wrote: On Monday 31 October 2005 16:04, you wrote: Dmitry Adamushko wrote: It seems to me now, that some parts of the hal will be involved (rthal_irq_request/release()) since the nucleus itself doesn't keep track of registered irqs. That's true. And it also raises another q

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

Jan Kiszka wrote: Dmitry Adamushko wrote: On Monday 31 October 2005 16:04, you wrote: Dmitry Adamushko wrote: It seems to me now, that some parts of the hal will be involved (rthal_irq_request/release()) since the nucleus itself doesn't keep track of registered irqs. That's true. And it

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

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

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 o

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

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

Re: [Xenomai-core] Dev branch 2.1

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: [default:

Re: [Xenomai-core] Dev branch 2.1

Hannes Mayer wrote: Philippe Gerum wrote: [...] The surprise is that xeno_native is statically built-in by default. You can change that selecting the proper tristate position in the kernel config for the native skin. So everything (even the 16550 driver) is compiled in by default ? I

[Xenomai-core] Xenomai v2.0.1

This is a minor release fixing a few glitches found in 2.0. People using the UVM support will find a single but important bug fix there though. Aside of this, the most noticeable thing is the upgrade of Adeos/ppc and x86 patches to 2.6.14. See the ChangeLog for details. http://download.gna.o

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

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 demon

Re: [Xenomai-core] rt_task_receive DOKU

Ulrich Schwab wrote: Hello, here is a patch, making the doku of rt_task_receive() more complete. diff -Nru xenomai-2.0-orig/skins/native/task.c xenomai-2.0-devel/skins/native/task.c --- xenomai-2.0-orig/skins/native/task.c2005-10-08 16:26:07.0 +0200 +++ xenomai-2.0-devel/ski

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

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 ou

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

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 demon

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

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

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 pi

Re: [Xenomai-core] RT pipes

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. After

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

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). App

Re: [Xenomai-core] Xenomai homepage

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] [PATCH] Xenomai stable ppc64 I-pipe sync

Heikki Lindholm wrote: Sync the ppc64 arch of the stable tree to work with I-pipe kernel also. Applied, thanks. -- Heikki Lindholm diff -Nru xenomai/arch/ppc64/hal/switch.S xenomai-devel/arch/ppc64/hal/switch.S --- x

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

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-core] [BUG] rt_pipe_flush declaration missing in skins/native/pipe.h

Ignacio García Pérez wrote: Philippe Gerum wrote: 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, I updated my source fro

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

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) > >> { > >>

Re: [Xenomai-core] rt_pipe_* usage

Ignacio García Pérez wrote: RT_PIPE_MSG *m = rt_pipe_alloc(sizeof(mystruct_t)); mystruct_t *p = (mystruct_t *)P_MSGPTR(m); p->whatever1 = X; p->whatever2 = X; rt_pipe_send(&mypipe, m, sizeof(mystruct_t), P_NORMAL); If this is correct, why do I have to specify the size of mystruct_t *twice*. Can'

Re: [Xenomai-core] More on rt pipes usage

Ignacio García Pérez wrote: Hi, Suppose I have a kernel rt task that samples data at a certain rate and writes it as messages into a rt pipe, from which it is read by a user space non rt program. I want to limit the number of messages that are put into the pipe, because otherwise if the user sp

[Xenomai-core] Re: [PATCH] Auto-allocation of minor values for pipe objects

Dmitry Adamushko wrote: Hello, enclosed please find a patch that hopefully adds so desired functionality. I have made various tests with it just now and it seems to work fine. Sounds good. A size of the bitmap is dependent on XNPIPE_NDEVS parameter in the same vein as xnpipe_states depe

Re: [Xenomai-core] rt_pipe_* usage

Ignacio García Pérez wrote: Philippe Gerum wrote: Ignacio García Pérez wrote: RT_PIPE_MSG *m = rt_pipe_alloc(sizeof(mystruct_t)); mystruct_t *p = (mystruct_t *)P_MSGPTR(m); p->whatever1 = X; p->whatever2 = X; rt_pipe_send(&mypipe, m, sizeof(mystruct_t), P_NORMAL); If this is co

Re: [Xenomai-core] [PATCH] Small build system fix for Xenomai 2.1

Heikki Lindholm wrote: The prepare-kernel.sh script doesn't link assembly files to the kernel at all. This should fix it. Applied, thanks. -- Heikki Lindholm diff -Nru xenomai.orig/scripts/prepare-kernel.sh xenomai

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

Dmitry Adamushko wrote: please see comments below... > > Another approach is about dropping the non-atomic update sequence > that hurts, tolerating > null runs of the virq when the seldom preemption case is seen, but > without requiring hw > interrupt masking to protect the shared stuff. L

[Xenomai-core] Re: [PATCH] Auto-allocation of minor values for pipe objects

Dmitry Adamushko wrote: Philippe Gerum <[EMAIL PROTECTED]> wrote on 15.11.2005 23:17:50: > Dmitry Adamushko wrote: > > > > Hello, > > > > enclosed please find a patch that hopefully adds so desired > > functionality. I have made various tests wit

[Xenomai-core] v2.1 status

Here is an update regarding the way things progress on the v2.1 branch: o The build system has been deeply revamped, so that we now fully leave the burden of building Xenomai's kernel support to Linux. To this end, the code tree has been reorganized in two major sections, the first one contain

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

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"

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] [pipe.c] hairy synchronization -> "flush the output queue upon closure"

Dmitry Adamushko wrote: Philippe Gerum <[EMAIL PROTECTED]> wrote on 18.11.2005 11:14:26: > > ... > > > > it looks like we can't make the whole xnpipe_release() atomic because of > > PREEMPT_RT + wake_up_interruptible_all() things, right? Or no. >

Re: [Xenomai-core] v2.1 status

Jan Kiszka wrote: Question: On recent roadmaps I'm so far missing the topic "RT-signal support in userspace". Are there any concrete schedules (Qx 200y)? Not currently, even if AFAIC, this is an interesting feature to have, so that we don't always have to process async events over dedicated

Re: [Xenomai-core] v2.1 status

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 real

Re: [Xenomai-core] v2.1 status

Wolfgang Grandegger wrote: Philippe Gerum wrote: Here is an update regarding the way things progress on the v2.1 branch: o The build system has been deeply revamped, so that we now fully leave the burden of building Xenomai's kernel support to Linux. To this end, the code tree has

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

Dmitry Adamushko wrote: Philippe Gerum <[EMAIL PROTECTED]> wrote on 18.11.2005 12:07:22: > > > Hm.. but we still have fasync_helper(-1,file,0,&state->asyncq); which is > > about sending a signal and that's perfectly valid (a file::counter is > > not

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

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 --- xenomai/includ

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

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 xenomai/include/asm-powerp

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

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 ab

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

Jan Kiszka wrote: Philippe Gerum wrote: 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

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

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 funct

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

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 le

Re: [Xenomai-core] ENOMEM detection fix in 16550A driver

(once again). Found by Paolo Mantegazza through cross-usage. + 2005-11-21 Philippe Gerum <[EMAIL PROTECTED]> * skins/native, nucleus/pipe.c: Globally replace ENOSPC by Index: drivers/16550A/16550A.c === --- driver

[Xenomai-core] Re: Xenomai on PPC

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: http://download.gna.org/xenomai/stable/xenomai-2.0.1.tar.bz

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

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)

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] > wrote: Hi, I dunno what's changed, but I updated my xenomai snapshot to

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

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-confi

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

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 pla

Re: [Xenomai-core] Coding style

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 qu

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

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 interr

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

Panagiotis Issaris wrote: Hi Jan, On 11/28/05, *Jan Kiszka* <[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 Jan 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 &

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

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). Confirme

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

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 cleanup-

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

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 cleanup-

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

Jan Kiszka wrote: Philippe Gerum wrote: 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

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

dm/drvlib.c (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-3

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

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 on. Will give a nice crash sooner or later

[Xenomai-core] Re: I-pipe ppc64 0.9-02

Heikki Lindholm wrote: Updated ppc64 I-pipe patch for 2.6.14. Changes: * sync with ppc 1.0-07 * send IPI to self fixed * additional IPI (#4) for xenomai SMP timer implementation Also at the usual http://www.cs.helsinki.fi/group/nonsto/rtaippc64.html Philippe, please put this in Xenomai 2.1.

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

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 2-3use

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

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_DEB

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

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 are

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

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

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 rt_task

  1   2   3   4   5   6   7   8   9   10   >