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

2005-10-21 Thread Jan Kiszka
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

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

2005-10-21 Thread Jan Kiszka
Fixes gcc-4 warnings. Jan Index: testsuite/latency/latency.c === --- testsuite/latency/latency.c (revision 54) +++ testsuite/latency/latency.c (working copy) @@ -40,9 +40,9 @@ #define WARMUP_TIME 1 #define HISTOGRAM_CELLS 100 int

Re: [Xenomai-core] Xenomai v2.0

2005-10-24 Thread Jan Kiszka
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 such, it paves

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

2005-10-28 Thread Jan Kiszka
Hannes Mayer wrote: Hi Jan et al.! Jan Kiszka wrote: [...] +modprobe xeno_16550A ioaddr=io1[,io2...] irq=irq1[,irq2...] + [tx_fifo=len1[,len2...]] [start_index=index] + +Arguments: +ioaddrN - I/O address of device N (e.g. 0x3f8 for ttyS0) +irqN

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

2005-10-31 Thread Jan Kiszka
Romain Lenglet wrote: ... Otherwise, my biggest source of problems is IRQ sharing between realtime and non-realtime drivers: this predictably provokes kernel panics. But Jan seems to be working on it. Actually, Dmitry and I are discussing IRQ sharing between real-time driver, not across

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

2005-11-01 Thread Jan Kiszka
/*** rt_test_module.c --- begin: Thr Dec 04 2003 copyright: (C) 2003 by Jan Kiszka email: [EMAIL PROTECTED

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

2005-11-01 Thread Jan Kiszka
Dmitry Adamushko wrote: On Monday 31 October 2005 21:38, you wrote: [...] In our case, the relation between xnintr_irq_handler() and rthal_irq_trampoline() is 1:1. The first one does much more things that the second one which is really almost a pure redirection layer. Hopefully,

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

2005-11-01 Thread Jan Kiszka
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. But that change

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

2005-11-02 Thread Jan Kiszka
Dmitry Adamushko wrote: [...] e.g. the cookie remains opaque for the ipipe but when requested by HAL::rthal_irq_request() or NUCLEUS::xnintr_irq_handler() it's treated as a chain of ISR handlers. Yep, that's also what I had in mind about potential ipipe changes and their use in the

[Xenomai-core] Xenomai homepage

2005-11-12 Thread Jan Kiszka
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! ;) Jan

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

2005-11-22 Thread Jan Kiszka
Philippe Gerum wrote: 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

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

2005-11-25 Thread Jan Kiszka
Philippe Gerum wrote: 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

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

2005-11-27 Thread Jan Kiszka
=== --- ChangeLog (Revision 191) +++ ChangeLog (Arbeitskopie) @@ -1,3 +1,11 @@ +2005-11-28 Jan Kiszka [EMAIL PROTECTED] + + * ksrc/arch/i386/Kconfig: Fixed XENO_HW_NMI_DEBUG_LATENCY_MAX + kconfig type. + + * include/asm-i386/system.h, ksrc/arch/i386/hal.c: Fixed

[Xenomai-core] [RFC] latency tracing

2005-11-28 Thread Jan Kiszka
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? Even when the core is once optimised ;), there can still be drivers with long IRQ locks nuking the

[Xenomai-core] NMI-WD dependencies

2005-11-29 Thread Jan Kiszka
Hi, what precisely are the requirements to build Xenomai's NMU watchdog? Something like depends on X86_LOCAL_APIC || X86_VISWS_APIC? Please add the correct dependency to the build system to avoid compilation errors like I just got after switching off the UP_APIC and forgetting the NMI watchdog.

[Xenomai-core] [patch] spinlock latency debugging

2005-11-29 Thread Jan Kiszka
Hi, this is a first attempt to add some more instrumentation to the Xenomai core and related modules. It enables the existing spinlock profiling also for non-SMP setups and adds the exit location to the log. Note that this is likely not yet ready for inclusion, it's only tested with debugging on

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

2005-11-30 Thread Jan Kiszka
of the nucleus when being used as a module. I also removed some special character from a name in the ChangeLog. Please apply! Jan Index: ChangeLog === --- ChangeLog (Revision 208) +++ ChangeLog (Arbeitskopie) @@ -1,3 +1,11 @@ +2005-11-30 Jan

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

2005-11-30 Thread Jan Kiszka
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). To be more precisely: Setup 1: xeno 2.0,

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

2005-11-30 Thread Jan Kiszka
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). As it took some time

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

2005-11-30 Thread Jan Kiszka
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 this double-deletion

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

2005-12-07 Thread Jan Kiszka
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

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

2005-12-07 Thread Jan Kiszka
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 on. Will give a nice crash

[Xenomai-core] [RFC] rt_task_join?

2005-12-07 Thread Jan Kiszka
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 signalled by the terminating real-time

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

2005-12-07 Thread Jan Kiszka
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 signalled

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

2005-12-08 Thread Jan Kiszka
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_create/delete in a

[Xenomai-core] [patch] fix rt_task_delete for cancellable rt-threads

2005-12-08 Thread Jan Kiszka
Hi, no, this is not the fix for the issue I described earlier. This just improves the behaviour of rt_task_delete in case the target is blocking at a cancellation point (tested with standard sem_wait). With the current version, rt_task_deletes the rt-shadow and just wakes up the linux pthread

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

2005-12-08 Thread Jan Kiszka
Hi, Please apply this, the statement is no longer valid. --- 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 zero is passed, a reasonable pre-defined

[Xenomai-core] anonymous rt_tasks in userspace / registry dependencies

2005-12-08 Thread Jan Kiszka
Hi again, some questions just came up for me: 1. Is it intended that tasks created with NULL name in userspace are not accessible even to the creator? I.e. don't they have to register anonymously in that case like semaphores e.g. do? 2. Doesn't render switching off XENO_OPT_NATIVE_REGISTRY the

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

2005-12-08 Thread Jan Kiszka
Good evening, this patch is required to compile some posix userspace program against 2.1 SVN. Jan Index: include/posix/signal.h === --- include/posix/signal.h (Revision 245) +++ include/posix/signal.h (Arbeitskopie) @@ -20,6 +20,12

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

2005-12-08 Thread Jan Kiszka
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 a simple test, compile the attached program one time as

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

2005-12-09 Thread Jan Kiszka
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 a simple test

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

2005-12-09 Thread Jan Kiszka
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 in userspace

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

2005-12-11 Thread Jan Kiszka
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). While thinking about the possibility to convert the hard IRQ lock protection of kheapq into some Linux mutex or

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

2005-12-11 Thread Jan Kiszka
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 introducing a generic

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

2005-12-11 Thread Jan Kiszka
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). Critical should

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

2005-12-11 Thread Jan Kiszka
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-off context, thus

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

2005-12-11 Thread Jan Kiszka
Philippe Gerum wrote: 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

[Xenomai-core] [PATCH] debug_maxlat as module_param

2005-12-17 Thread Jan Kiszka
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 (before activating the hal). Unfortunately, this tiny patch caused some headache

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

2005-12-17 Thread Jan Kiszka
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 (before

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

2005-12-17 Thread Jan Kiszka
, +driver_name:xeno_16550A, driver_version: RTDM_DRIVER_VER(1, 2, 1), peripheral_name:UART 16550A, provider_name: Jan Kiszka, Index: ksrc/drivers/16550A/Makefile === --- ksrc/drivers/16550A/Makefile

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

2005-12-18 Thread Jan Kiszka
, -driver_version: RTDM_DRIVER_VER(1, 2, 1), +driver_version: RTDM_DRIVER_VER(1, 2, 2), peripheral_name:UART 16550A, provider_name: Jan Kiszka, }; @@ -1040,10 +1048,15 @@ int i; -if (irq_c ioaddr_c) -return -EINVAL; +for (i = 0; i

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

2005-12-18 Thread Jan Kiszka
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 kernels. This also

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

2005-12-18 Thread Jan Kiszka
device profile header + * + * @note Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED] + * + * Xenomai is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License

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

2005-12-18 Thread Jan Kiszka
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 circumstances. This bug

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

2005-12-22 Thread Jan Kiszka
Philippe Gerum wrote: Jan Kiszka wrote: ... Anyway, there seems to be some latency issues pending. I discovered this again with my migration test. Please give it a try on a mid- (800 MHz Athlon in my case) to low-end box. On that Athlon I got peaks of over 100 us in the userspace latency

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

2005-12-22 Thread Jan Kiszka
Gilles Chanteperdrix wrote: 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

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

2005-12-22 Thread Jan Kiszka
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 to open some device

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

2005-12-26 Thread Jan Kiszka
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 irq

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

2005-12-27 Thread Jan Kiszka
/i386/ipipe-mcount.S + * + * Copyright (C) 2005 Jan Kiszka + */ + +#include linux/config.h + +.globl mcount +mcount: +cmpl $0,ipipe_trace_enable +je out + +pushl %ebp +movl %esp,%ebp + +pushl %eax +pushl %ecx +pushl %edx + +pushl $0

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

2005-12-28 Thread Jan Kiszka
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... Jan Index: src/skins/uvm/init.c

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

2005-12-28 Thread Jan Kiszka
Philippe Gerum wrote: ... +#ifdef CONFIG_IPIPE_TRACE +extern void __ipipe_init_trace_proc(void); +#else /* !CONFIG_IPIPE_TRACE */ +# define __ipipe_init_trace_proc() +#endif /* CONFIG_IPIPE_TRACE */ + Better move this to linux/ipipe.h. Ok. + +#include linux/kernel.h +#include

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

2005-12-28 Thread Jan Kiszka
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: (Each undeclared identifier is reported only

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

2005-12-28 Thread Jan Kiszka
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 Jan Kiszka
Jan Kiszka wrote: --- linux-2.6.14.3/arch/i386/boot/compressed/misc.c.orig 2005-11-24 23:10:21.0 +0100 +++ linux-2.6.14.3/arch/i386/boot/compressed/misc.c 2005-12-28 16:12:43.0 +0100 @@ -15,6

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

2005-12-29 Thread Jan Kiszka
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 the timer,

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

2005-12-29 Thread Jan Kiszka
Philippe Gerum wrote: 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

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

2005-12-30 Thread Jan Kiszka
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 priority. Apply

[Xenomai-core] [RFC] pkg-config for Xenomai

2005-12-30 Thread Jan Kiszka
Hi, just to file the idea, not to claim that I'm going to do this: ;) What about moving xeno-config to a xenomai.pc file, providing the required information to build userspace applications via pkg-config? Any traps or pitfalls that could make this tricky or less comfortable? I just browsed a bit

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

2005-12-30 Thread Jan Kiszka
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

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

2006-01-02 Thread Jan Kiszka
/benchmark/timerbench.c (Revision 0) @@ -0,0 +1,538 @@ +/* + * Copyright (C) 2005 Jan Kiszka [EMAIL PROTECTED]. + * + * Xenomai is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2

[Xenomai-core] [PATCHES] various fixes

2006-01-02 Thread Jan Kiszka
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) * rtdm-nrt-close.patch - don't permit RTDM devices without NRT closure handlers * maxlat_proc.patch - export NMI watchdog

Re: [Xenomai-core] src/skins/*/COPYING consistency

2006-01-02 Thread Jan Kiszka
Stefan Kisdaroczi wrote: hi, license detail: in every src/skins/*/ directory containing source is a LGPL COPYING file, except in rtdm. For consistency there should be also one. Or only one file src/skins/COPYING ? Thanks for pointing out. Will be addressed soon (see my various fixes

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

2006-01-02 Thread Jan Kiszka
Jan Kiszka wrote: ... Moreover, here are two minor fixes: * accuracy.patch - add missing define to let this posix demo compile Forget about this one. I oversaw the way SPERIOD is passed in the original Makefile while compiling accuracy.c by hand. Jan signature.asc Description: OpenPGP

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

2006-01-02 Thread Jan Kiszka
Stefan Kisdaroczi wrote: Hi Jan, Am Montag, 2. Januar 2006 14.36 schrieb Jan Kiszka: * rtdm-license.patch - add missing COPYING files to RTDM skin and lib (or go for just a single file for ksrc/skins and src/skins if this is applicable) The COPYING file in your patch contains

[Xenomai-core] [PATCH] fix ipipe for !CONFIG_PRINTK

2006-01-02 Thread Jan Kiszka
Hi, this patch lets ipipe compile even if someone is annoyed of all the babbling on the kernel console. ;) Jan --- linux-2.6.14.3/kernel/ipipe/core.c.orig 2005-12-17 14:08:23.0 +0100 +++ linux-2.6.14.3/kernel/ipipe/core.c 2006-01-01 18:58:18.0 +0100 @@ -43,7 +43,9 @@ unsigned

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

2006-01-02 Thread Jan Kiszka
Philippe Gerum wrote: * maxlat_proc.patch - export NMI watchdog threshold via /proc, trigger trace freezing instead of die_nmi() if CONFIG_IPIPE_TRACE is enabled Merged. Gilles pointed out that ipipe_trace_freeze() is not NMI-save. After sorting my private patch chaos, I'm going to

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

2006-01-02 Thread Jan Kiszka
...as a follow-up, here is a patch to fix some bugs in the new trace triggering and to improve (from my POV) the output of this tool in some regards. Jan Index: src/testsuite/latency/latency.c === --- src/testsuite/latency/latency.c

[Xenomai-core] xenomai prefix in RTDM userspace includes

2006-01-04 Thread Jan Kiszka
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 my eyes - ugly

Re: [Xenomai-core] RTDM timerbench problems

2006-01-04 Thread Jan Kiszka
Stelian Pop wrote: Hi, I'm trying to use the xeno_timerbench as a replacement to the old 2.0 klatency module and I encounter some problems. This is on my in-progress ARM Xenomai port. User space latency and old klatency work great (my board has some hardware latency problems though -

[Xenomai-core] enjoying the trace

2006-01-04 Thread Jan Kiszka
Hi all, after a long day of experimenting with a new tracer revision (will get posted later), I'm looking now for some external wisdom. I changed the instrumentation for high-domain stall times such that I now attach to local_irq_disable_hw friends instead. In case the hard-IRQ status doesn't

Re: [Xenomai-core] enjoying the trace

2006-01-04 Thread Jan Kiszka
Jan Kiszka wrote: Hi all, after a long day of experimenting with a new tracer revision (will get posted later), I'm looking now for some external wisdom. I changed the instrumentation for high-domain stall times such that I now attach to local_irq_disable_hw friends instead. In case

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

2006-01-06 Thread Jan Kiszka
Jan Kiszka wrote: ... Meanwhile I found a solution for the described unterminated trace (put an explicite trace_end at the end of __ipipe_unstall_iret_root), included the irq number in the begin/end report, and stumbled over some other remaining unterminated trace on a different machine. So

[Xenomai-core] Oops, I broke something

2006-01-06 Thread Jan Kiszka
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 @@ base=include

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

2006-01-06 Thread Jan Kiszka
Philippe Gerum wrote: 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

Re: [Xenomai-core] [PATCH] Fix ppc fpu support

2006-01-06 Thread Jan Kiszka
Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one of the codepaths that save FPU state if MSR_FP is set,

Re: [Xenomai-core] [PATCH] Fix ppc fpu support

2006-01-06 Thread Jan Kiszka
Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens to hit one

Re: [Xenomai-core] [PATCH] Fix ppc fpu support

2006-01-06 Thread Jan Kiszka
Jan Kiszka wrote: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Xenomai might preempt linux when linux has cleared a tasks MSR_FP, but not yet set last_task_used_math to NULL. As a result the tasks MSR_FP will get set, although it should be cleared. If the task happens

[Xenomai-core] Re: [PATCH] move RTDM headers

2006-01-07 Thread Jan Kiszka
Philippe Gerum wrote: Jan Kiszka wrote: Hi Philippe, this patches cleans up the include/rtdm folder by moving internal headers to ksrc/skins/rtdm, leaving only rtdm.h, rtdm_driver.h, the two profile headers, and syscall.h there. The latter is still only needed for building Xenomai itself

[Xenomai-core] Re: [PATCH] move RTDM headers

2006-01-07 Thread Jan Kiszka
Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi Philippe, this patches cleans up the include/rtdm folder by moving internal headers to ksrc/skins/rtdm, leaving only rtdm.h, rtdm_driver.h, the two profile headers, and syscall.h there. The latter

[Xenomai-core] [PATCH] reset tracer after timer calibration

2006-01-07 Thread Jan Kiszka
Hi Philippe, this patch is to reset the maximum IRQs-off path after timer calibration (will get flooded otherwise). If you have no concerns, please apply. Actually, there is another noise source: rthal_timer_request() for the APIC case. But I think we should let this one alone as the user may

Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.

2006-01-07 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Jan Kiszka wrote: The previous patch was also incorrect when trying to cross-compile the Linux kernel or building it for ppc. The attached patch fixes these issues. Regarding your general idea, I'm just trying to imagine the new build process

Re: [Xenomai-core] latency kernel part crashes on ppc64

2006-01-08 Thread Jan Kiszka
Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? Nope, it should work as it is. But

Re: [Xenomai-core] latency kernel part crashes on ppc64

2006-01-08 Thread Jan Kiszka
Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending

Re: [Xenomai-core] latency kernel part crashes on ppc64

2006-01-08 Thread Jan Kiszka
Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes

[Xenomai-core] [PATCH] fix tracer compilation issues

2006-01-08 Thread Jan Kiszka
Hi Philippe, two minor updates I fixed since your last merge. The first one triggers if the tracer tries to warn of debugging switch related latencies. The second one when building very specific out-of-tree modules against the kernel (here: madwifi with its binary-only component), stumbling over

Re: [Xenomai-core] [PATCH, RFC] nucleus:shared irq, draft v.2

2006-01-09 Thread Jan Kiszka
Dmitry Adamushko wrote: Hi everybody, I'm presenting it one last time as a draft, so it's a right time to give all the remarks concerning design/implementation issues for all interested parties. Any feedback is wellcome. -- Best regards, Dmitry Adamushko My mail client

Re: [Xenomai-core] latency kernel part crashes on ppc64

2006-01-11 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Likely not this time (keep it cold anyway, who knows); I strongly suspect a bug in xnarch_switch_to() for all archs but x86 Now that you are talking about it, I may

[Xenomai-core] Re: [PATCH] Shared irqs v.5

2006-01-22 Thread Jan Kiszka
Dmitry Adamushko wrote: Hello Jan, as I promised earlier today, here is the patch. I finally had a look at your patch (not yet a try), and it looks really nice and light-weight. Now I only have two topics on my wish list: o Handling of edge-triggered IRQs (ISA-cards...). As I tried to

[Xenomai-core] Re: [PATCH] Shared irqs v.5

2006-01-23 Thread Jan Kiszka
Dmitry Adamushko wrote: On 23/01/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: Hello Jan, as I promised earlier today, here is the patch. I finally had a look at your patch (not yet a try), and it looks really nice and light-weight. I have another version here at hand

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-23 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Jeroen Van den Keybus wrote: Hello, I'm currently not at a level to participate in your discussion. Although I'm willing to supply you with stresstests, I would nevertheless like to learn more from task migration as this debugging session

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-24 Thread Jan Kiszka
Dmitry Adamushko wrote: On 23/01/06, Gilles Chanteperdrix [EMAIL PROTECTED] wrote: Jeroen Van den Keybus wrote: Hello, [ skip-skip-skip ] Since in xnshadow_harden, the running thread marks itself as suspended before running wake_up_interruptible_sync, the gatekeeper will run when

Re: [Xenomai-core] About scheduling routine and xnpod_announce_tick

2006-01-25 Thread Jan Kiszka
Germain Olivier wrote: Hello My question is about the scheduling routine: I want to know if the function xnpod_announce_tick is called at every tick of the timer (such I suppose because it is linked with the timer), so it will be a good place to do some EDF scheduling stuff. Yes,

Re: [Xenomai-core] Sigevent, sigaction

2006-01-26 Thread Jan Kiszka
Doyle, Alan wrote: I've downloaded Xenomai-2.0.3 and have been lookingh into signal handling. Structs sigevent sigaction are used in the code but I can't find where they are declared. Can anyone help ? Maybe browsing for them (identifier or full-text search) on this site helps you (I do not

Re: [Xenomai-core] [PATCH] Fix to RTDM open problems

2006-01-27 Thread Jan Kiszka
Anders Blomdell wrote: When RTDM is exposed to code like this: device1 = rt_dev_open(some_device, O_RDWR); device2 = rt_dev_open(some_device, O_RDWR); I get a SEGFAULT, which I attribute to a missing assignment to context_ptr in the case when the device is already busy, the lack of

[Xenomai-core] [PATCH] fix pthread cancellation in native skin

2006-01-28 Thread Jan Kiszka
Hi, Gilles' work on cancellation for the posix skin reminded me of this issue I once discovered in the native skin: https://mail.gna.org/public/xenomai-core/2005-12/msg00014.html I found out that this can easily be fixed by switching the pthread of a native task to PTHREAD_CANCEL_ASYNCHRONOUS.

Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-30 Thread Jan Kiszka
Wolfgang Grandegger wrote: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) Philippe Gerum wrote: Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Therefore we need a dedicated function to re-enable interrupts in the ISR. We could name it *_end_irq, but maybe

Re: [Xenomai-core] Missing IRQ end function on PowerPC

2006-01-30 Thread Jan Kiszka
Philippe Gerum wrote: Jan Kiszka wrote: Wolfgang Grandegger wrote: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) Philippe Gerum wrote: Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Therefore we need a dedicated function to re-enable interrupts in the ISR. We

Re: [Xenomai-core] [BUG] racy xnshadow_harden under CONFIG_PREEMPT

2006-01-30 Thread Jan Kiszka
Dmitry Adamushko wrote: ... I have not checked it yet but my presupposition that something as easy as : preempt_disable() wake_up_interruptible_sync(); schedule(); preempt_enable(); It's a no-go: scheduling while atomic. One of my first attempts to solve it. My fault. I meant the

Re: [Xenomai-core] broken docs

2006-01-30 Thread Jan Kiszka
ROSSIER Daniel wrote: Dear Xenomai workers, Would it be possible to have an updated API documentation for Xenomai 2.0.x ? (I mean with formal parameters in function prototypes) I tried to regenerate it with make generate-doc, but it seems that a SVN working dir is required. It would be

Re: [Xenomai-core] broken docs

2006-01-30 Thread Jan Kiszka
Gilles Chanteperdrix wrote: Jan Kiszka wrote: ROSSIER Daniel wrote: Dear Xenomai workers, Would it be possible to have an updated API documentation for Xenomai 2.0.x ? (I mean with formal parameters in function prototypes) I tried to regenerate it with make generate

  1   2   3   4   5   6   7   8   9   10   >