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
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
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
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
/***
rt_test_module.c
---
begin: Thr Dec 04 2003
copyright: (C) 2003 by Jan Kiszka
email: [EMAIL PROTECTED
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,
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
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
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
===
--- 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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
,
+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
,
-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
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
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
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
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
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
/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
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
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
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
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
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
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
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
/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
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
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
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
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
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
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
...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
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
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
-
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
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
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
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
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
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
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
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
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
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
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,
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
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.
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
Philippe Gerum wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
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
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008
Philippe Gerum wrote:
Jan Kiszka wrote:
At this chance: any comments on the panic-freeze extension for the
tracer? I need to rework the Xenomai patch, but the ipipe side should be
ready for merge.
No issue with the ipipe side since it only touches the tracer support
code. No issue either
Dmitry Adamushko wrote:
Hi,
the previous version contained an ugly bug, namely the misuse of the
test_and_set/clear_bit interface
that led to a broken system from time to time.
What about the ISA/edge-triggered stuff? :D
My problem is that we cannot test here on real hardware because all
Jeroen Van den Keybus wrote:
I mean that the support of shared interrupts for ISA boards
(edge-triggered
stuff) is a kind of emulation to overcome the shortcommings of the
initial
design on the hardware level. The hardware was just not supposed to
support
shared interrupt channels. So,
Jeroen Van den Keybus wrote:
I've installed both patches and the problem seems to have disappeared.
I'll try it on another machine tomorrow, too. Meanwhile: thanks very
much for the assistance !
While testing more thoroughly, my triggers for zero mutex values after
acquiring the lock are
Jeroen Van den Keybus wrote:
Revision 466 contains the mutex-info fix, but that is post -rc2. Why not
switching to SVN head?
Philippe asked to apply the patch against Xenomai 2.1-rc2. Can I safely
patch it against the SVN tree ? After that, what will 'svn up' do to the
patched tree ?
The
Anders Blomdell wrote:
While looking into how to implement sharing of interrupts between
realtime and non-realtime domains (and applying Wolfgang Grandegger's
patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html],
which is necessary to make XN_ISR_ENABLE work at all on the
Philippe Gerum wrote:
Jim Cromie wrote:
Philippe Gerum wrote:
Ive been running an ipipe kernel as the default since shortly after
1/7.
Since then, Ive had a couple of freezes on boot,
and sometimes bash's auto-complete takes longer to complete,
Eh? Maybe the CONFIG_PCI_MSI syndrom
Jan Kiszka wrote:
...
What about other time sources on x86? Which systems already have HPET
these days, and does this source not suffer from frequency scaling? I
once read that HPET is quite easy to program, is this true? IOW, would
it be worth considering to add this to the HAL
Anders Blomdell wrote:
Jan Kiszka wrote:
...and may also add further latencies with the system has to speed up
again. Anyway, there might be use-cases where power consumption is -
besides latency - also an important issue. I'm just thinking of our
smaller mobile robots where the power demand
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
...and may also add further latencies with the system has to speed up
again. Anyway, there might be use-cases where power consumption is -
besides latency - also an important issue. I'm just thinking of our
Hi Philippe,
now I finally found the bug in my first version of this patch: some UVM
skin builds complained about an unknown symbol. Fixed now in this
version, please apply.
Jan
Index: include/asm-uvm/system.h
===
---
Hi Philippe,
this patch tries to clarify where to solve SMI-related latencies. Or
should we even mention the kconfig path?
Moreover, I would like to upload my RTL-Workshop paper about RTDM to
doc/nodist/pdf (~150k) so that it later makes it on the website as well. Ok?
Jan
Index:
Wolfgang Grandegger wrote:
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA -
XN_ISR_EDGE), a few cleanups and updated comments.
Functionally, the support for shared
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA -
XN_ISR_EDGE), a few cleanups and updated comments
Anders Blomdell wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA -
XN_ISR_EDGE), a few cleanups
Philippe Gerum wrote:
Anders Blomdell wrote:
My distinct feeling is that the return value should be a scalar and
not a set!
To sum up, the valid return values are HANDLED, HANDLED | ENABLE (*),
HANDLED | CHAINED and CHAINED. It's currently a set because I once
thought that the handled
Anders Blomdell wrote:
For the last few days, I have tried to figure out a good way to share
interrupts between RT and non-RT domains. This has included looking
through Dmitry's patch, correcting bugs and testing what is possible in
my specific case. I'll therefore try to summarize at least a
John Schipper wrote:
Hello,
I'm new to this list but have in the past used RTAI in a single
processor off the shelf solution. I'm looking to switch to native
Xenomai api but have a general problem...
The problem is SMI on new systems, and other latency killers that
What do you mean with
Hi Dmitry,
some news from the testing front: It works fairly well - and it doesn't
crash =:). We set up a quite demanding test scenario which consists of
two Sick Laser scanners feeding two UART ports at 500 Kbit/s. The UARTs
are on a special PC104 card, sharing the same edge-triggered IRQ line.
Rodrigo Rosenfeld Rosas wrote:
Hi Jan, it just happened once and I couldn't reproduce (I didn't want to
reproduce it too since I would need to restart my computer because the driver
wouldn't unload)...
When it happened I forgot to start the timer running the latency program and
Already
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Rodrigo Rosenfeld Rosas wrote:
Hi Jan, it just happened once and I couldn't reproduce (I didn't want
to reproduce it too since I would need to restart my computer because
the driver wouldn't unload)...
When it happened I forgot to start
Dmitry Adamushko wrote:
On 11/02/06, Jan Kiszka [EMAIL PROTECTED] wrote:
Dmitry Adamushko wrote:
And as an additional option,
it could be interesting to print out to the log if not all counter
values
then min,max,average (the same like for the latency :) per second or per
1000 interrupts
Rodrigo Rosenfeld Rosas wrote:
Jan Kiszka escreveu:
Ok, but even if you decide to let rt-mmap be non-deterministic, you
still need some means to prevent the scenario you described above.
Actually, all you need is some callback when the mapped memory block was
actually released (munmap
Jan Kiszka wrote:
Hi,
while XENO_OPT_DEBUG is generally a useful switch for tracing potential
issues in the core and the skins, it also introduces high latencies via
the queue debugging feature (due to checks iterating over whole queues).
This patch introduces separate control over queue
Hi,
I'm sure now that the native registry is mandatory as soon as
CONFIG_XENO_OPT_PERVASIVE is selected. This patch enforces the selection
in such a scenario.
Jan
Index: ksrc/skins/native/Kconfig
===
--- ksrc/skins/native/Kconfig
Hi,
this patch addresses the compiler warnings when
CONFIG_XENO_OPT_NATIVE_REGISTRY is switched off.
Jan
Index: ksrc/skins/native/mutex.c
===
--- ksrc/skins/native/mutex.c (revision 564)
+++ ksrc/skins/native/mutex.c (working
Philippe Gerum wrote:
Jan Kiszka wrote:
I haven't worked out any patch for those issues. Actually, I only wanted
to put this patch forward when stumbling over the other:
--- ksrc/skins/native/Kconfig (revision 564)
+++ ksrc/skins/native/Kconfig (working copy)
@@ -127,7 +127,6
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
were you able to successfully run my T_SUSP test-case after the latest
changes? For me this code still causes fatal exceptions:
This is solved with revision 565, hopefully.
It is.
Jan
signature.asc
Description
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
while XENO_OPT_DEBUG is generally a useful switch for tracing
potential
issues in the core and the skins, it also introduces high
latencies via
the queue
Anders Blomdell wrote:
Jan Kiszka wrote:
Hi Dmitry,
Dmitry Adamushko wrote:
Hi Jan,
let's make yet another revision of the bits :
new XN_ISR_HANDLED == old XN_ISR_HANDLED + old XN_ISR_NO_ENABLE
ok.
new XN_ISR_NOENABLE == ~ old XN_ISR_ENABLE
ok.
new XN_ISR_PROPAGATE
Dmitry Adamushko wrote:
For RTDM I'm now almost determined to rework the API in way that only
HANDLED/UNHANDLED (or what ever their names will be) get exported, any
additional guru features will remain excluded as long as we have no
clean usage policy for them.
Good. Then let's go for
Hi Philippe,
I noticed you fixed the libtool warning during xenomai build - by
linking the testsuite statically... :-/ This is just a workaround and
doesn't help external users.
Isn't the reason for this warnings that -module in every skin
Makefile.am? At least, removing it also fixes external
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi Philippe,
I noticed you fixed the libtool warning during xenomai build - by
linking the testsuite statically... :-/ This is just a workaround and
doesn't help external users.
Yes, it's clearly hacky-patchy, however, I don't see how this would
Dmitry Adamushko wrote:
...
This said, I'm going to publish the shirq patch (after finalizing ISR return
bits,
where I still have some doubts) without enable/disable nesting support.
It can be supported at some point of time later, if it's really needed.
Regarding enable/disable nesting
1 - 100 of 2091 matches
Mail list logo
