On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
> plain text document attachment (enhance-kernel-fault-report.patch)
> Introduce xnarch_fault_um() to test if a fault happened in user-mode and
> applies the new feature to report core and driver crashes more verbosely.
> if (xnpo
Philippe Gerum wrote:
> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
>> plain text document attachment (enhance-kernel-fault-report.patch)
>> Introduce xnarch_fault_um() to test if a fault happened in user-mode and
>> applies the new feature to report core and driver crashes more ve
On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
> >> plain text document attachment (enhance-kernel-fault-report.patch)
> >> Introduce xnarch_fault_um() to test if a fault happened in user-mode and
> >> ap
Philippe Gerum wrote:
> On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
plain text document attachment (enhance-kernel-fault-report.patch)
Introduce xnarch_fault_um() to test if a fault happened
On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
> plain text document attachment (enhance-kernel-fault-report.patch
Philippe Gerum wrote:
> On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
> On Mon, 2006-06-26 at 19:21 +0200, [EMAIL PROTECTED] wrote:
>> plain text document attachment (enhance-
On Wed, 2006-06-28 at 10:51 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Mon, 2006-06-26 at 19:21 +0200, [EMAIL
Philippe Gerum wrote:
> On Wed, 2006-06-28 at 10:51 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
> On Wed, 2006-06-28 at 09:51 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Mon, 2006-06-2
[EMAIL PROTECTED] wrote:
> Index: xenomai/src/testsuite/irqbench/irqbench.c
> ===
> --- /dev/null
> +++ xenomai/src/testsuite/irqbench/irqbench.c
> @@ -0,0 +1,301 @@
> +/*
> + * Copyright (C) 2006 Jan Kiszka <[EMAIL PROTECTED]>.
Gilles Chanteperdrix wrote:
> [EMAIL PROTECTED] wrote:
> > Index: xenomai/src/testsuite/irqbench/irqbench.c
> > ===
> > --- /dev/null
> > +++ xenomai/src/testsuite/irqbench/irqbench.c
> > @@ -0,0 +1,301 @@
> > +/*
> > + * Copyri
Jan Kiszka wrote:
> > Is there no way to make this code easier to port for example by using
> > native or posix services for timings measurement and by abstracting the
> > non portable part and moving them to include/asm-i386 ?
>
> This tool is intentionally left Xenomai-free. You can put it
On 28/06/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
Jan Kiszka wrote:
>
> Ok, then we also need a fix for the latency test (this is where I
> grabbed that pattern from). Is there a high risk that this locks up? I
> wonder why I never observed or heard of problems with latency.
The l
Dmitry Adamushko wrote:
> On 28/06/06, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
>> Jan Kiszka wrote:
>> >
>> > Ok, then we also need a fix for the latency test (this is where I
>> > grabbed that pattern from). Is there a high risk that this locks up? I
>> > wonder why I never observed or
Jan Kiszka wrote:
> Hi,
>
> could someone give this scenario a try (requires my recent patch series)
> and tell me if you are also seeing excessive latencies:
>
> Start:
> irqloop (+xeno_irqbench) -P 99 -t 0
> latency -p 200 -P 50
>
> Terminate:
> irqloop
>
> The termination seems to cause high
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> > > Is there no way to make this code easier to port for example by using
> > > native or posix services for timings measurement and by abstracting the
> > > non portable part and moving them to include/asm-i386 ?
> >
> > This tool is intentio
>
> Then all other threads must block signal delivering with sigprocmask()
> so that the main thread is the only one which "accepts" signals.
Is that required, i.e. does pause() only wake up if the signal handler
executed in the main thread's context? Then cyclictest contains a bug as
well...
I
On Wed, 2006-06-28 at 11:17 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-06-28 at 10:51 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Wed, 2006-06-28 at 10:18 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2006-06-28 at 09:51 +0200, Jan Kis
Jan Kiszka wrote:
> >
> > Also note that calling printf from a signal handler risk deadlocking if
> > the signal handler get called on the return path of the write call that
> > take place in the middle of a printf call on the main thread.
> >
>
> Ok, then we also need a fix for the laten
Update to fix a compiler warning (char * vs. const char *).
Jan
Subject: Overread dev-prefix on posix open
Adds support to the posix user-space lib to address RTDM-devices also with a (here meaningless) "/dev/" name prefix. Intended to increase user convenience slightly.
---
src/skins/posix/rtd
This is just a rebased version of the patch over revision #1275.
Jan
Subject: Add prio switch to latency test
Introduces -P switch to the latency test and extends xeno_timerbench to respect this for the kernel-based timer task as well. The patch also allows now to run multiple latency tests (bot
Here comes an update of the irqbench patch.
Changelog:
- avoid printf from signal context in irqloop
- reorder irq-enable code in the driver to avoid spurious replies on
startup
- avoid creating/destroying pthread under SCHED_FIFO (but still suffers
from prio inversion during cleanup here)
- f
Hi,
here are three patches, two enhancing the ipipe tracer, the third
propagating the new features to Xenomai.
The tracer gains support for recording a Linux pid + a priority value.
The priority can be set to an arbitrary value (12 bit, signed), but will
typically be related to the pid. When the
22 matches
Mail list logo
