Gilles Chanteperdrix wrote:
* rtcan: on blackfin we seem to have a conflict with rtcan.
The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
define this in core headers which are included everywhere. This said,
not prefixing a Xenomai symbol with something like XN seems to be
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
* rtcan: on blackfin we seem to have a conflict with rtcan.
The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to
define this in core headers which
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Philippe,
as adeos-ipipe-2.4.35.5-i386-1.3-05.patch and
adeos-ipipe-2.6.29.5-x86-2.4-02.patch are no longer up to date /wrt to
latest i-pipe fixes, I would suggest to remove them for 2.5-final.
Avoids that people trap into known issues
Hi Philippe,
as adeos-ipipe-2.4.35.5-i386-1.3-05.patch and
adeos-ipipe-2.6.29.5-x86-2.4-02.patch are no longer up to date /wrt to
latest i-pipe fixes, I would suggest to remove them for 2.5-final.
Avoids that people trap into known issues.
Jan
signature.asc
Description: OpenPGP digital
Gilles Chanteperdrix wrote:
Hi,
I am working on automated build tests of several configurations of
Xenomai head. While running them, I found a few issues, and would need
acks, since it is in parts others maintain.
Alex: https://mail.gna.org/public/xenomai-git/2009-12/msg00112.html
hagen.langbart...@sieb-meyer.de wrote:
Hi all,
I tried to compile Xenomai 2.5rc4 with uClibc 0.9.30.1 and ran into some
problems with references to the
posix functions shm_open and shm_unlink in /src/skins/posix/wrappers.c,
which do not exist in uClibc.
Unlinke in
Philippe Gerum wrote:
On Thu, 2009-12-03 at 22:42 +0100, Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Hi,
On 03.12.2009, at 14:14, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org
wrote:
Wolfgang Mauerer wrote:
Hi,
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2009-12-03 at 22:42 +0100, Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Hi,
On 03.12.2009, at 14:14, Gilles Chanteperdrix
gilles.chanteperd
The following changes since commit 1d53d0298f6d50b5136080b3b3322efee8b05c8a:
Philippe Gerum (1):
doc: regenerate
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1):
nucleus: Try to send SIGXCPU to runaway threads first
Gilles Chanteperdrix wrote:
Hi,
here come the pull request for user-space signals support. The simple
solution; handling signals upon system call return, has been implemented
since the other solution (handling signals upon any return to
user-space) required to change the I-pipe patch, and
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi,
here come the pull request for user-space signals support. The simple
solution; handling signals upon system call return, has been implemented
since the other solution (handling signals upon any return to
user-space) required to change
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Hi,
we'd like to implement a gettimeofday() mechanism that works
in realtime context, both from user- and kernelland. Most importantly,
the correctins made to the wall time by the NTP protcol on Linux
must be transferred into the Xenomai
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Hi,
we'd like to implement a gettimeofday() mechanism that works
in realtime context, both from user- and kernelland. Most importantly,
the correctins made to the wall time by the NTP protcol
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Why? It delivers us the core mechanism we need for the rest as well -
and it does not require fancy I-pipe hooks.
Because relying on the vdso/vsyscall only works on x86. Whereas
implementing clock slew down/acceleration at nucleus level
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Why? It delivers us the core mechanism we need for the rest as well -
and it does not require fancy I-pipe hooks.
Because relying on the vdso/vsyscall
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi,
here come the pull request for user-space signals support. The simple
solution; handling signals upon system call return, has been implemented
since the other solution (handling signals upon
Michael Löffler wrote:
Hello List!
I have an application running rt_task_sleep() in a loop. After a more or
less random number of loops, something up to 5000 cycles, the system
reboots with the following error message:
Kernel panic - not syncing:
BUG!
4BUG: failure at
Wolfgang Grandegger wrote:
Sebastian Smolorz wrote:
can: Free I/O region when unloading the xeno_can_isa.ko driver
Signed-off-by: Sebastian Smolorz smol...@rts.uni-hannover.de
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
Philippe, should I apply the patch?
Do you have write
The following changes since commit 3fded6232aad90e2c6799857a21aa492a0fa8e22:
Philippe Gerum (1):
Merge commit 'jan'
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Luis Herrera-Bendezu (1):
rtdm: Extend rtdm_iomap_to_user to map phys
Herrera-Bendezu, Luis wrote:
Jan,
Thanks for your feedback and help.
Merged your patch (and sent out a pull request), though the line
wrapping issue persisted (manually fixed up).
Your next patch to an open source project probably deserves the use of a
better mail client.
Jan
Herrera-Bendezu, Luis wrote:
rtdm_iomap_to_user does not handle I/O memory mapping of
physical I/O address grater than 4 GB.
This patch changes the src_addr argument and underlying
code to handle this case.
Signed-off-by: Luis Herrera-Bendezu lherr...@xxx
Please make sure to always preserve CCs.
Herrera-Bendezu, Luis wrote:
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@siemens.com]
Sent: Wednesday, November 18, 2009 11:42 AM
To: Herrera-Bendezu, Luis
Cc: xenomai-core@gna.org
Subject: Re: rtdm_iomap_to_user with phys addr
The following changes since commit bdda0013bb4a666a1d2c55ef52c5dd55e5fb6f3b:
Jan Kiszka (1):
nucleus: Include all heaps in statistics
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1):
nucleus: Allow runtime setting
Herrera-Bendezu, Luis wrote:
Jan,
I think we can change rtdm_iomap_to_user to take src_addr as
phys_addr_t
and propagate this internally properly. We also need to add a wrapper
for phys_addr_t for kernels that doesn't support this (2.6.28). To my
current understanding, this should be
Philippe Gerum wrote:
...
I would rather pick your suggestion to introduce a display-oriented name
we could call a label instead, to make clear that we are only dealing
with pretty-printing in /proc.
I.e.
- xnheap_init() remains unchanged
- xnheap_set_label(fmt, args...) is introduced
: /proc label strings are
set via a new service xnheap_set_label, the existing API is not touched.
And I think I even fixed some bugs of the previous version.
Jan Kiszka (2):
rtdm: Fix copypaste mistake in instrumentation
nucleus: Include all heaps in statistics
include/nucleus/heap.h
Gilles Chanteperdrix wrote:
GIT version control wrote:
+void xnheap_set_label(xnheap_t *heap, const char *label, ...)
+{
+va_list args;
+spl_t s;
+
+va_start(args, label);
+
+xnlock_get_irqsave(nklock, s);
+vsnprintf(heap-label, sizeof(heap-label), label, args);
+
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
GIT version control wrote:
+void xnheap_set_label(xnheap_t *heap, const char *label, ...)
+{
+ va_list args;
+ spl_t s;
+
+ va_start(args, label);
+
+ xnlock_get_irqsave(nklock, s);
+ vsnprintf(heap-label
The following changes since commit cd3465f1862a4aa29e488a3876097d9e425ef907:
Philippe Gerum (1):
nios2: upgrade I-pipe support to 2.6.30-nios2-1.1-00
are available in the git repository at:
git://git.xenomai.org/xenomai-jki for-upstream
Jan Kiszka (1):
rtdm: Fix copypaste
here once we enabled it for our customer. The first one is a resend, the
other two are a cleanup and a minor instrumentation fix.
Jan Kiszka (4):
hal: Ensure atomicity of rthal_local_irq_disabled
nucleus: Cosmetic cleanup of lostage_handler
nucleus: Improve lostage_work
Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2009-10-20 at 13:37 +0200, Jan Kiszka wrote:
This extends /proc/xenomai/heap with statistics about all currently used
heaps. It takes care to flush nklock while iterating of this potentially
long list.
Signed-off-by: Jan Kiszka jan.kis
:
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@siemens.com]
Sent: Tuesday, November 10, 2009 1:55 PM
To: Herrera-Bendezu, Luis
Cc: xenomai-core@gna.org
Subject: Re: rtdm_iomap_to_user with phys addr 4GB
Herrera-Bendezu, Luis wrote:
-Original Message-
From
Anisha Kaul wrote:
Dear all,
How to define a tasklet using Xenomai for a serial port interrupt handler?
Does 'rtdm_event_init()' function work as a tasklet in Xenomai ?
An RTDM event is a binary semaphore for use inside a kernel driver -
probably not what you are looking for. What should be
Philippe Gerum wrote:
On Tue, 2009-11-10 at 01:34 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
[Patch is now also available in 'for-upstream']
ipipe_test_pipeline_from is not atomic /wrt reading the current cpu
number (or an offset for the per-cpu area) and actually reading
Anisha Kaul wrote:
Thanks for the prompt reply !
The tasklet I am talking about is supposed to re-set the registers of the
serial port each time an interrupt occurs ! We can do this the following
way in using Linux system calls :
void resetRegisters (unsigned long currentlyUnused);
Philippe Gerum wrote:
On Tue, 2009-11-10 at 12:33 +0100, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2009-11-10 at 11:43 +0100, Jan Kiszka wrote:
[...]
Oh, *_hw_smp is new, isn't it? Do we need to wrap it for older I-pipes?
Yes, it was introduced to solve the SMP migration issue actually
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
The following changes since commit
6d7d6bc436ef3d1fb51fa8de06d4ecf004e3b6a5:
Gilles Chanteperdrix (1):
nucleus: defer selector block deletion to an APC.
are available in the git
Herrera-Bendezu, Luis wrote:
Hello,
I am writing an RTDM driver to replace one that uses UIO. The device
resides in a physical address 4 GB on a PPC440EPx. The UIO could
not handle this address so I made a proposal to address it, details at:
Herrera-Bendezu, Luis wrote:
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@siemens.com]
Sent: Tuesday, November 10, 2009 12:03 PM
To: Herrera-Bendezu, Luis
Cc: xenomai-core@gna.org
Subject: Re: rtdm_iomap_to_user with phys addr 4GB
Herrera-Bendezu, Luis wrote
Herrera-Bendezu, Luis wrote:
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@siemens.com]
Sent: Tuesday, November 10, 2009 1:13 PM
To: Herrera-Bendezu, Luis
Cc: xenomai-core@gna.org
Subject: Re: rtdm_iomap_to_user with phys addr 4GB
Herrera-Bendezu, Luis wrote
Herrera-Bendezu, Luis wrote:
-Original Message-
From: Jan Kiszka [mailto:jan.kis...@siemens.com]
Sent: Tuesday, November 10, 2009 1:55 PM
To: Herrera-Bendezu, Luis
Cc: xenomai-core@gna.org
Subject: Re: rtdm_iomap_to_user with phys addr 4GB
Herrera-Bendezu, Luis wrote
Remco den Breeje wrote:
Hi all,
I'm having trouble trying to share a semaphore that is created in
user-space context with a rtdm-driver that runs in kernel-space. I was
hoping you could explain me what I'm doing wrong.
The design. :)
I'm using a posix-skin based user-space Xenomai
Philippe,
having a Xenomai heap mapped and then forking / exiting the fork is not
a good idea, is it? I mean for the sake of archdep.numaps...
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
___
Jan Kiszka wrote:
Philippe,
having a Xenomai heap mapped and then forking / exiting the fork is not
a good idea, is it? I mean for the sake of archdep.numaps...
OK, think I found the gremlin: xnheap_vmclose must be paired with a
xnheap_vmopen for proper reference counting, not simple mapping
The following changes since commit 6d7d6bc436ef3d1fb51fa8de06d4ecf004e3b6a5:
Gilles Chanteperdrix (1):
nucleus: defer selector block deletion to an APC.
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (2):
nucleus: Track
false-positives of RTDM driver debug checks.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-generic/hal.h |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/include/asm-generic/hal.h b/include/asm-generic/hal.h
index 97c549e..3095b85 100644
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
[Patch is now also available in 'for-upstream']
ipipe_test_pipeline_from is not atomic /wrt reading the current cpu
number (or an offset for the per-cpu area) and actually reading the
virtualized interrupt state. Work around this by disabling
Jan Kiszka wrote:
The following changes since commit 6b1a185b460765c933b17932d77be6967d2e42dc:
Philippe Gerum (1):
nucleus: fix locking in shared heap deletion
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1
Philippe Gerum wrote:
On Mon, 2009-11-02 at 19:01 +0100, Jan Kiszka wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2009-11-02 at 17:41 +0100, Jan Kiszka wrote:
Philippe Gerum wrote:
On Sat, 2009-10-24 at 19:22 +0200, Philippe Gerum wrote:
On Tue, 2009-10-20 at 13:37 +0200, Jan
The following changes since commit 6b1a185b460765c933b17932d77be6967d2e42dc:
Philippe Gerum (1):
nucleus: fix locking in shared heap deletion
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1):
rtdm: Add padding
Philippe Gerum wrote:
On Sat, 2009-10-24 at 19:22 +0200, Philippe Gerum wrote:
On Tue, 2009-10-20 at 13:37 +0200, Jan Kiszka wrote:
Allowing xnheap_delete_mapped to return an error and then attempting to
recover from it does not work out very well: Corner cases are racy,
intransparent
Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2009-11-02 at 17:41 +0100, Jan Kiszka wrote:
Philippe Gerum wrote:
On Sat, 2009-10-24 at 19:22 +0200, Philippe Gerum wrote:
On Tue, 2009-10-20 at 13:37 +0200, Jan Kiszka wrote:
Allowing xnheap_delete_mapped to return an error
Stefan Schaal wrote:
Hi,
I am working with the latest xenomai-head tree (we need analogy for
our NI board ...). Under Xenomai 2.4.8 our code did not have any mode
switches. Using the xenomai-head, we get a lot of mode switches. Using
he backtrace_symbols_fd, we get print-outs like:
Hi Philippe,
your commit dbbd33f50d (nios2: introduce architecture support) broke any
.so generation, at least for x86. Not sure why, but it is related to
moving AC_PROG_LIBTOOL around in configure.in. You had to push it after
nios2's AC_DISABLE_SHARED, right?
Jan
--
Siemens AG, Corporate
Jan Kiszka wrote:
Hi Philippe,
your commit dbbd33f50d (nios2: introduce architecture support) broke any
.so generation, at least for x86. Not sure why, but it is related to
moving AC_PROG_LIBTOOL around in configure.in. You had to push it after
nios2's AC_DISABLE_SHARED, right?
diff
This fixes a regression of dbbd33f50d: There must be no
AC_DISABLE_SHARED without AS_ENABLE_SHARED for the cases where it shall
remain enabled. Autotools are great, aren't they?
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
configure.in | 12 ++--
1 files changed, 10 insertions
This fixes a regression of dbbd33f50d: There must be no
AC_DISABLE_SHARED without AS_ENABLE_SHARED for the cases where it shall
remain enabled.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
configure.in | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
v2: properly
Philippe Gerum wrote:
On Thu, 2009-10-29 at 12:33 +0100, Jan Kiszka wrote:
This fixes a regression of dbbd33f50d: There must be no
AC_DISABLE_SHARED without AS_ENABLE_SHARED for the cases where it shall
remain enabled.
Makes sense. Will you queue this in your tree?
Done, it's ready
Philippe Gerum wrote:
On Sat, 2009-10-24 at 10:03 +0200, Jan Kiszka wrote:
Please pull Oliver's rt_print patches from
git://xenomai.org/xenomai-jki.git for-upstream
Oliver Schlenker (2):
Fork-safe rt_print
Syslog extension of rt_print
include/rtdk.h |2 +
src
Please pull Oliver's rt_print patches from
git://xenomai.org/xenomai-jki.git for-upstream
Oliver Schlenker (2):
Fork-safe rt_print
Syslog extension of rt_print
include/rtdk.h |2 +
src/rtdk/rt_print.c | 72 ++-
2 files
From: Oliver Schlenker oliver.schlen...@smmotioncontrol.de
Extension of rt_print library with rt_syslog() and rt_vsyslog() to print
messages rt-safe directly to syslog.
Signed-off-by: Oliver Schlenker oliver.schlen...@smmotioncontrol.de
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
From: Oliver Schlenker oliver.schlen...@smmotioncontrol.de
Fork-safe initialisation of rt_print library, necessary child initialisation are
done via pthread_atfork() when child process is started.
Signed-off-by: Oliver Schlenker oliver.schlen...@smmotioncontrol.de
Signed-off-by: Jan Kiszka
Jan Kiszka wrote:
We are currently leaking user space heap/queue objects when the owner
terminates without deleting them before. Fix it by releasing the objects
in the corresponding cleanup callbacks which are also called on owner
termination.
Just realized that we need this patch in addition
Philippe Gerum wrote:
On Tue, 2009-10-20 at 13:37 +0200, Jan Kiszka wrote:
This extends /proc/xenomai/heap with statistics about all currently used
heaps. It takes care to flush nklock while iterating of this potentially
long list.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Philippe Gerum wrote:
Well, I can tell you that there are quite a few corner cases you would
face in rewriting the queue/heap cleanup code. I'm not saying this
should not be done, I just won't merge this to 2.5.0 to avoid more
regressions. Let's fix the obvious for now, such as the missing
We are currently leaking user space heap/queue objects when the owner
terminates without deleting them before. Fix it by releasing the objects
in the corresponding cleanup callbacks which are also called on owner
termination.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
ksrc/skins
No need for hard nklock protection of kheapq and the map counter, a
normal spin lock suffices as all users must run over the root thread
anyway.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
ksrc/nucleus/heap.c | 26 --
1 files changed, 12 insertions(+), 14
-deletion and introduces
complete heap statistics (this time without using a Linux spin lock).
Please pull the series (or cherry-pick individual patches) from
git://xenomai.org/xenomai-jki.git for-upstream
if there are no concerns.
Jan Kiszka (9):
native: Release fastlock to the proper heap
.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/native/ppd.h | 16
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/include/native/ppd.h b/include/native/ppd.h
index 3dbda6a..c6e7479 100644
--- a/include/native/ppd.h
+++ b/include/native/ppd.h
@@ -101,19
handler
that belongs to the module text, deferred release will cause a crash.
But this corner case is no new regression, so let's keep the head in the
sand.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/nucleus/heap.h|6 +++---
ksrc/nucleus/heap.c | 45
with declaring
the heap valid. Otherwise xnheap_destroy_mapped may draw wrong
conclusions about the heap mapping state.
As archdep.numaps is now exclusively modified under heapq_lock, we can
switch it to a non-atomic counter.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-generic/bits
Don't assume rt_task_delete is only called for in-kernel users, it may
be triggered via auto-cleanup also on user space objects. So check for
the creator and release the fastlock to the correct heap.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
ksrc/skins/native/mutex.c | 14
This is totally untested but should not make things worse than they
already are.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
ksrc/skins/rtai/shm.c | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/ksrc/skins/rtai/shm.c b/ksrc/skins
This extends /proc/xenomai/heap with statistics about all currently used
heaps. It takes care to flush nklock while iterating of this potentially
long list.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/nucleus/heap.h| 12 +++-
ksrc/drivers/ipc/iddp.c |3 +
ksrc
Philippe Gerum wrote:
On Mon, 2009-10-19 at 21:09 +0200, Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
@@ -234,12 +239,65 @@ int xnheap_init(xnheap_t *heap,
appendq(heap-extents, extent-link);
+ vsnprintf(heap-name, sizeof(heap-name), name, args);
+
+ spin_lock
Don't assume rt_task_delete is only called for in-kernel users, it may
be triggered via auto-cleanup also on user space objects. So check for
the creator and release the fastlock to the correct heap.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
ksrc/skins/native/mutex.c | 14
deletion.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/nucleus/sys_ppd.h | 11 +++
ksrc/nucleus/heap.c | 30 ++
ksrc/nucleus/shadow.c | 23 +++
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git
in this pull request is a statistic enhancement for
/proc/xenomai/heap: It was lacking the sem heaps so far.
Please pull the series from
git://xenomai.org/xenomai-jki.git for-upstream
if there are no concerns.
Jan Kiszka (2):
nucleus: Add semaphore heap statistics
native: Release
No need for hard nklock protection of kheapq and the map counter, a
normal spin lock suffices as all users must run over the root thread
anyway.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
ksrc/nucleus/heap.c | 26 --
1 files changed, 12 insertions(+), 14
of heavy nklock.
Please pull the series from
git://xenomai.org/xenomai-jki.git for-upstream
if there are no concerns.
Jan Kiszka (3):
nucleus: Use Linux spin lock for heap list management
nucleus: Include all heaps in statistics
native: Release fastlock to the proper heap
Don't assume rt_task_delete is only called for in-kernel users, it may
be triggered via auto-cleanup also on user space objects. So check for
the creator and release the fastlock to the correct heap.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
ksrc/skins/native/mutex.c | 14
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
No need for hard nklock protection of kheapq and the map counter, a
normal spin lock suffices as all users must run over the root thread
anyway.
At the very least, this should use rthal_spin_lock, in order to seem to
respect the layering
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
@@ -234,12 +239,65 @@ int xnheap_init(xnheap_t *heap,
appendq(heap-extents, extent-link);
+vsnprintf(heap-name, sizeof(heap-name), name, args);
+
+spin_lock(heapq_lock);
+appendq(heapq, heap-stat_link);
+spin_unlock
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
No need for hard nklock protection of kheapq and the map counter, a
normal spin lock suffices as all users must run over the root thread
anyway.
At the very least, this should use rthal_spin_lock, in order to seem to
respect
Philippe Gerum wrote:
On Fri, 2009-10-16 at 19:08 +0200, Jan Kiszka wrote:
Hi,
our automatic object cleanup on process termination is slightly broken
for the native skin. The inline and macro magic behind
__native_*_flush_rq() blindly calls rt_*_delete(), but that's not
correct for mutexes
Philippe Gerum wrote:
On Sun, 2009-10-18 at 14:54 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Fri, 2009-10-16 at 19:08 +0200, Jan Kiszka wrote:
Hi,
our automatic object cleanup on process termination is slightly broken
for the native skin. The inline and macro magic behind
__native_
Hi,
our automatic object cleanup on process termination is slightly broken
for the native skin. The inline and macro magic behind
__native_*_flush_rq() blindly calls rt_*_delete(), but that's not
correct for mutexes (we can leak memory and/or corrupt the system heap),
queues and heaps (we may
Jan Kiszka wrote:
Hi,
our automatic object cleanup on process termination is slightly broken
for the native skin. The inline and macro magic behind
__native_*_flush_rq() blindly calls rt_*_delete(), but that's not
correct for mutexes (we can leak memory and/or corrupt the system heap),
Hmm
[restoring CC]
Edouard TISSERANT wrote:
[...] And I hope
we will find the required resources/contributor to welcome a cleaned up
RTnet stack inside the Xenomai 3 source tree one day.
Could you detail that point ? What is to be changed in RTnet to fit
with Xenomai 3 ?
No ground shaking
The following changes since commit cd669afa1b220242c157de74b9e3cd86c37b8433:
Philippe Gerum (1):
x86: upgrade I-pipe support to 2.6.30.8-x86-2.4-06, 2.6.31.1-x86-2.4-06
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Then please summarize again what you want change from the user's POV (fd
range and arbitration, I guess, but also their scope?)
Basically, when going from user-space to kernel-space, instead of a
simple translation, currently done
The following changes since commit 50ee47db78117e8711d4d2f5310dff262a425eb7:
Gilles Chanteperdrix (1):
Do not use the 2 stages build for building non-posix applications
are available in the git repository at:
git://xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1):
POSIX
Gilles Chanteperdrix wrote:
Hi Jan,
from discussions on the mailing list, it seems that we are going to need
that unified file descriptors thing. However, since everybody wants
2.5.0 to be released ASAP, we should try to think about any changes for
this support which would break the ABI, do
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
from discussions on the mailing list, it seems that we are going to need
that unified file descriptors thing. However, since everybody wants
2.5.0 to be released ASAP, we should try to think about any changes
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Tue, 2009-09-29 at 19:31 +0200, Gilles Chanteperdrix wrote:
Hi guys,
full of energy after this tremendous first XUM,
Agreed, thanks to the DENX folks for having thought of it in the first
place, and organized it nicely.
I would like to
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
from discussions on the mailing list, it seems that we are going to need
that unified file descriptors thing. However, since everybody wants
2.5.0 to be released
Philippe Gerum wrote:
On Fri, 2009-10-02 at 21:25 +0200, Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Tue, 2009-09-29 at 19:31 +0200, Gilles Chanteperdrix wrote:
Hi guys,
full of energy after this tremendous first XUM,
Agreed, thanks to the DENX folks for having
Gilles Chanteperdrix wrote:
Peter Soetens wrote:
On Tue, Sep 29, 2009 at 19:31, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
Hi guys,
full of energy after this tremendous first XUM, I would like to start a
discussion about what people would like to see in the 2.5 branch.
So
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Matthieu Nottale wrote:
Hi,
I believe I found a bug in the Xenomai Posix skin while trying to use
boost::asio: The accept() call in asychronous mode
fails with ENOPEM instead of EAGAIN. Other than that, the call 'works'
in the sense
The following changes since commit 13d66eb4c8f1648614095d43dd529a3c98fc5278:
Philippe Gerum (1):
x86: upgrade I-pipe support to 2.6.31-x86-2.4-05
are available in the git repository at:
git://xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1):
rtipc: Fix 64-bit related
401 - 500 of 2091 matches
Mail list logo
