Re: [Xenomai-core] Kernel 2.6.26 Hung With Xenomai 2.4.5

Hi, I noticed some problems, if you disable the apic in kernel (lapic=no) My kernel keeps stable while I am not going into xenomai interrupt driver context. In interrupt driver context, at the moment , for unknown reasons, my driver is called but this is a spurious interrupt and the

[Xenomai-core] [RFC][PATCH 7/9] Switch POSIX mutexes to XNSYNCH_FWDROB

Switch POSIX over to XNSYNCH_FWDROB, demonstrating the use of this flag (and aligning the implementation for following native version). This can save the syscall so far required on releasing a stolen mutex. --- ksrc/skins/posix/mutex.c | 10 ++ ksrc/skins/posix/mutex.h | 42

[Xenomai-core] [RFC][PATCH 6/9] Add XNSYNCH_FWDROB

Intermediate helper as long as skins implement fast locking and related owner tracking on their own: Add 'forward XN_ROBBED state' to the caller of xnsynch_sleep_on so that the correct owner can be looked up there. --- include/nucleus/synch.h |3 ++- ksrc/nucleus/pod.c |6 --

[Xenomai-core] [PATCH 3/9] Remove xnarch_atomic_intptr wrappers

No more users, no more use cases in sight, let's get rid of it. --- include/asm-arm/atomic.h|3 --- include/asm-blackfin/atomic.h |2 -- include/asm-generic/Makefile.am |2 +- include/asm-generic/Makefile.in |2 +- include/asm-generic/atomic.h| 24

[Xenomai-core] [PATCH 1/9] Always register threads by their base

In order to use xnthread_handle(thread) for the fast mutex lock variable, we have to ensure that all skins pass the generic object on xnregistry_enter. The following patch ensures this for preexisting registrations. --- ksrc/skins/native/syscall.c | 56

[Xenomai-core] [RFC][PATCH 5/9] Allow lock stealing via pthread_mutex_trylock

By calling into the kernel in the contended case and exploiting XN_NONBLOCK for xnsynch_sleep_on, this patch adds lock stealing support to pthread_mutex_trylock. The latter part may change if we decide to go for a dedicates xnsynch trylock service. Maybe we are even lucky and able to implement

Re: [Xenomai-core] [RFC][PATCH 5/9] Allow lock stealing via pthread_mutex_trylock

Jan Kiszka wrote: By calling into the kernel in the contended case and exploiting XN_NONBLOCK for xnsynch_sleep_on, this patch adds lock stealing support to pthread_mutex_trylock. The latter part may change if we decide to go for a dedicates xnsynch trylock service. Maybe we are even lucky

Re: [Xenomai-core] [RFC][PATCH 6/9] Add XNSYNCH_FWDROB

Jan Kiszka wrote: Intermediate helper as long as skins implement fast locking and related owner tracking on their own: Add 'forward XN_ROBBED state' to the caller of xnsynch_sleep_on so that the correct owner can be looked up there. Nak. We already discussed this with Philippe, XNROBBED is an

[Xenomai-core] [PATCH 0/9] Fast mutex rework, native support

Here comes our current patch series to fix and enhance fast mutexes for both the POSIX as well as the native skin. After the long discussion on this list, it is clear that this is not the last word. However, we are currently not aware of regressions or still broken corner cases, so this series may

[Xenomai-core] [PATCH 4/9] Spread xeno_set_current

Spread xeno_set_current under all user space supporting skins. --- src/skins/native/task.c | 13 +++-- src/skins/psos+/task.c | 18 ++ src/skins/uitron/task.c | 18 +- src/skins/vrtx/task.c |3 +++ src/skins/vxworks/taskLib.c |

[Xenomai-core] [RFC][PATCH 8/9] Native support for fast mutexes

Analogously to POSIX, this patch adds fast mutex support to the native skin. --- include/native/mutex.h | 29 +++- ksrc/skins/native/cond.c| 17 +- ksrc/skins/native/mutex.c | 305 ++-- ksrc/skins/native/syscall.c | 71 --

[Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners

To improve robustness of the fast mutex implementation in POSIX (and later on in native), it is better to track the mutex owner by handle instead of kernel object pointer. Therefore, this patch changes __xn_sys_current (xeno_set_current) so that it returns xnthread_handle(current_thread). It

Re: [Xenomai-core] [RFC][PATCH 7/9] Switch POSIX mutexes to XNSYNCH_FWDROB

Jan Kiszka wrote: Switch POSIX over to XNSYNCH_FWDROB, demonstrating the use of this flag (and aligning the implementation for following native version). This can save the syscall so far required on releasing a stolen mutex. Nak. -- Gilles.

Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners

Jan Kiszka wrote: To improve robustness of the fast mutex implementation in POSIX (and later on in native), it is better to track the mutex owner by handle instead of kernel object pointer. Therefore, this patch changes __xn_sys_current (xeno_set_current) so that it returns

Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners

Gilles Chanteperdrix wrote: Jan Kiszka wrote: To improve robustness of the fast mutex implementation in POSIX (and later on in native), it is better to track the mutex owner by handle instead of kernel object pointer. Therefore, this patch changes __xn_sys_current (xeno_set_current) so that

Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners

Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: To improve robustness of the fast mutex implementation in POSIX (and later on in native), it is better to track the mutex owner by handle instead of kernel object pointer. Therefore, this patch changes __xn_sys_current

Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners

Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: To improve robustness of the fast mutex implementation in POSIX (and later on in native), it is better to track the mutex owner by handle instead of kernel object pointer. Therefore, this patch

Re: [Xenomai-core] [PATCH 2/9] Switch to handle-based fast mutex owners

Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: To improve robustness of the fast mutex implementation in POSIX (and later on in native), it is better to track the mutex owner by handle instead of kernel object pointer.