Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
This patch implements the _read, _set, and _cmpxchg operations on
atomic_long_t
and atomic_ptr_t in user-space in include/asm-generic/atomic.h which
should
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 3:44 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 2:59 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Hi,
trunk check-in #3369 did not just remove some questionable critical
sections, it
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
This patch implements the _read, _set, and _cmpxchg
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 4:01 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 4:01 PM, Philippe Gerum [EMAIL PROTECTED]
wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED]
wrote:
Gilles
Jan Kiszka wrote:
Hi,
after hacking away the barriers I-pipe erected in front of lockdep
(patches will follow on adeos-main), I was finally able to visualize a
bit more what our colleagues see in reality on SMP: some ugly, not yet
understood circular dependency when running some Xenomai app
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
On Mon, May 5, 2008 at 6:08 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
do_schedule_event() is the culprit when it reads the pending signals on the
shared queue (XNDEBUG check for rearming the timers),
A stupid suggestion: if we know
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
On Mon, May 5, 2008 at 6:08 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
do_schedule_event() is the culprit when it reads the pending signals on the
shared queue (XNDEBUG check for rearming the timers),
A stupid suggestion: if we know
Gilles Chanteperdrix wrote:
On Sat, May 3, 2008 at 12:34 AM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
The include/asm-arm/atomic.h header now defines the xnarch_memory_barrier in
addition to user-space atomic operations. The pxa3xx deserves a special
treatment since it uses the ARMv6
Klaas Gadeyne wrote:
Hi,
it seems -ETIMEDOUT is not mentioned as a possible return value of
rt_cond_wait() in the API docs [1], although it *is* returned in case
of the timeout having expired [2]?
Indeed. Applied, thanks.
Attached patch tries to solve this against the 2.4 branch.
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
On Mon, May 5, 2008 at 6:08 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
do_schedule_event() is the culprit when it reads the pending signals on
the
shared queue (XNDEBUG check for rearming the timers
Jan Kiszka wrote:
This has been posted earlier already: Fix deadlocks when debugging
Xenomai applications via gdb by removing any attempt to acquire
sighand_lock (while holding rq_lock). This patch also cleans up the now
unused lock wrapper.
Unless someone complains, I'm going to merge this
Jan Kiszka wrote:
I expressed my skepticism about this global timer freeze before :-, and
Just try debugging periodic code without it...
We should have an opt-out mechanism to hide timers from the auto-freeze feature,
that is the real issue yet to be fixed.
now it hit me unpleasantly
Gilles Chanteperdrix wrote:
On Fri, May 9, 2008 at 11:29 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
+ if (xnthread_test_info(thread, XNDEBUG))
+ unlock_timers();
+
Will this work if several threads are currently being debugged ?
Yes, because we freeze timers when a
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
This has been posted earlier already: Fix deadlocks when debugging
Xenomai applications via gdb by removing any attempt to acquire
sighand_lock (while holding rq_lock). This patch also cleans up the now
unused lock wrapper.
Unless
Gilles Chanteperdrix wrote:
On Fri, May 9, 2008 at 11:44 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
I expressed my skepticism about this global timer freeze before :-, and
Just try debugging periodic code without it...
We should have an opt-out mechanism to hide timers
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 11:10 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
@@ -1236,6 +1236,9 @@ void xnpod_delete_thread(xnthread_t *thr
Markus Osterried wrote:
Hello,
there is a bug in the pSOS user-space skin, calling the wrong
kernel-space function for tm_evevery().
The file xenomai/src/skins/psos+/tm.c should be fixed like this:
--- xenomai-2.4/src/skins/psos+/tm.c
+++ xenomai-2.4/src/skins/psos+/tm.c
@@ -71,7
Hillier, Gernot wrote:
Hi there!
Just noted that prepare-kernel.sh ends up in an endless loop when you
use --default together with an invalid --arch parameter.
Here's a small patch. Please apply. TIA!
Index: scripts/prepare-kernel.sh
Hillier, Gernot wrote:
Hi again!
Current SVN head fails to do make install when you use --prefix=/usr
resulting in the includedir /usr/include:
--- SNIP ---
make[2]: Entering directory `/home/gernot/xenomai/include'
make[3]: Entering directory `/home/gernot/xenomai/include'
make[3]:
Niklaus Giger wrote:
Hi
I just tried to get a sample test program to run under Xenomai-SOLO
and run into this panic message:
Xenomai/SOLO: current implementation restricts VxWorkspriority levels to
range [-2..0]
looking at the code I found at taskLib.c
263 {
264 if
Niklaus Giger wrote:
Hi
I just tried to get a sample test program to run under Xenomai-SOLO
and run into this panic message:
Xenomai/SOLO: current implementation restricts VxWorkspriority levels to
range [-2..0]
looking at the code I found at taskLib.c
263 {
264 if
Niklaus Giger wrote:
Am Sonntag, 18. Mai 2008 schrieb Philippe Gerum:
Niklaus Giger wrote:
Hi
I just tried to get a sample test program to run under Xenomai-SOLO
and run into this panic message:
Xenomai/SOLO: current implementation restricts VxWorkspriority levels to
range [-2..0
Philippe Gerum wrote:
Niklaus Giger wrote:
Am Sonntag, 18. Mai 2008 schrieb Philippe Gerum:
Niklaus Giger wrote:
Hi
I just tried to get a sample test program to run under Xenomai-SOLO
and run into this panic message:
Xenomai/SOLO: current implementation restricts VxWorkspriority levels
Gilles Chanteperdrix wrote:
In addition to support for non cached memory mappings, this patch implements
xnheap_init_mapped and xnheap_destroy_mapped in the !CONFIG_XENO_OPT_PERVASIVE
case. This avoids a lot of #ifdefs for users of these functions without
user-space support (posix skin shared
Gilles Chanteperdrix wrote:
The two syscalls defined in the posix skin now moved to the sys skin, they are
used in user-space by include/asm-generic/bits/bind.h and the new header
include/asm-generic/bits/current.h. The global and process-specific shared
heaps
are now part of this patch.
Gilles Chanteperdrix wrote:
Since binding of the semaphore heaps is now made by xeno_skin_bind, there is
much less modifications in src/skins/posix/init.c. However, I had to do
something really ugly: since binding the semaphore heaps by xeno_skin_bind
requires calls to open, ioctl, mmap, close
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Since binding of the semaphore heaps is now made by
xeno_skin_bind
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The two syscalls defined in the posix skin now moved to the sys skin,
they are
used in user-space by include/asm-generic/bits/bind.h and the new header
include/asm-generic/bits/current.h. The global
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The two syscalls defined in the posix skin now moved to the sys
skin, they are
used in user-space by include/asm-generic/bits/bind.h
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
As far as I understood, the user-space atomic operations, used to
acquire a free mutex in user-space, are not part of the futex API. In
our case, we are using xnarch_atomic_* operations to implement
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Since binding
yi li wrote:
Hi,
Attached two patches to make xenomai/adeos work with ADI's blackfin
process BF52x and BF54x.
The patches are based on xenomai-2.4.0. It has been tested on
BF527-EZkit, BF548-Ezkit and BF561-Ezkit, using blackfin uClinux 2008R1
branch.
Merged, thanks.
Adeos patch in
Wolfgang Grandegger wrote:
Hello,
the following patch fixes a problem building the Xenomai user
space applications for the MPC5200 using the ELDK 4.2. It can't
find the type uint64_t:
Index: include/asm-powerpc/fptest.h
===
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
when compiling xenomai v2.4.x for ARM with gcc 4.2.1, I get plenty of
warnings like:
xenomai-arm/kernel/xenomai/skins/posix/syscall.c:38:
xenomai-arm/include/xenomai/rtdm
Aitor Viana wrote:
I am new in Xenomai issues. I would like to begin porting Xenomai to the
LEON2 architecture (sparcv8) but I don't know how to begin from. Is
there any documentation or so explaining how to port xenomai to support
another architecture?
There is no cookbook for that, so here
yi li wrote:
Hi Philippe,
Attached patch adds other two fixes to make adeos work on BF548. The
patch is based on previous adeos-bf54x.patch. Please have a look.
Merged, thanks.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
Markus Osterried wrote:
Hi,
our kernel (along with the device drivers) is specifically adapted to
our embedded system, it would be a huge bunch of work to change the
kernel.
I think to do the ipipe backport is a lot easier.
Here is the fourth maintenance release for the v2.4.x branch. Short
log follows:
[nucleus]
* Prevent drifts between large calculated versus measured dates.
* Fix potential deadlock on SMP when ptracing shadow threads.
* Thaw timers when a ptraced shadow thread
Gilles Chanteperdrix wrote:
On Fri, Jun 13, 2008 at 4:18 PM, Markus Osterried
[EMAIL PROTECTED] wrote:
Hello,
there is a bug in the pSOS kernel-space skin, calculating calendar time to
ticks and vice versa.
The file xenomai/ksrc/skins/psos+/tm.c should be fixed like this:
Have you tried
Steven A. Falco wrote:
I am building kernel 2.6.25.4 from DENX with Xenomai 2.4.4 for PPC440EPx
(sequoia development board).
The kernel tries to use DHCP to obtain network settings. With IPIPE
disabled, this works perfectly. However, when I enable IPIPE, the board
sends packets ok, but
Benjamin ZORES wrote:
Philippe Gerum a écrit :
FYI, I'm running on PowerPC 603e core with Linux 2.6.23, Adeos 2.0-09
(latest) and Xenomai 2.3.4 (latest).
read Xenomai 2.4.4 here, of course ...
See arch/powerpc/switch_32.S, rthal_switch_threads(), for the part
that does the
actual
Benjamin ZORES wrote:
Philippe Gerum a écrit :
See arch/powerpc/switch_32.S, rthal_switch_threads(), for the part that does
the
actual stack switching.
Note that this code is obfuscated by the fact that we have to handle
so-called
hybrid switching, between Xenomai kernel threads (which
Benjamin ZORES wrote:
Hi,
I'm facing a problem with the PowerPC version of Xenomai/Adeos that I
have difficulties
to identify the exact source.
I'm running a Xenomai RT kernel thread that use to crash sometimes due
to potential register corruption.
Problem occurs after a context
Steven A. Falco wrote:
Philippe Gerum wrote:
Steven A. Falco wrote:
I am using the patch that came with Xenomai 2.4.4, namely:
adeos-ipipe-2.6.25-powerpc-DENX-2.2-02.patch
I can't reproduce this issue on a 440EP board, but I still have to to put
my
hands on a 440EPX
Steven A. Falco wrote:
Philippe Gerum wrote:
Steven A. Falco wrote:
I am building kernel 2.6.25.4 from DENX with Xenomai 2.4.4 for PPC440EPx
(sequoia development board).
The kernel tries to use DHCP to obtain network settings. With IPIPE
disabled, this works perfectly. However, when I
Steven A. Falco wrote:
Beautiful. The patch works! I now get DHCP replies.
Is this the patch you will put into the official tree, or do you still
need to do more?
One thing, could you confirm that your network card relies on edge interrupts
(and not level)?
Aside of that, it
Jan Kiszka wrote:
Philippe Gerum wrote:
Author: rpm
Date: Sat Jun 28 18:23:51 2008
New Revision: 3998
URL: http://svn.gna.org/viewcvs/xenomai?rev=3998view=rev
Log:
Merge COMEDI over RTDM framework
Added:
...
trunk/ksrc/skins/comedi/
trunk/ksrc/skins/comedi/Config.h
trunk
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is
Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is actually a native
task. Therefore this patch
Atsushi Katagiri wrote:
Hello all.
This is a small patch that fixes a serious bug.
When we open /proc/xenomai/stat, function stat_seq_open kmalloc the area,
write the data and increment iter-nentries.
The last increment of this value reaches count,
and at the next iteration
Philippe Gerum wrote:
Atsushi-san,
Atsushi Katagiri wrote:
Yes, I actually encountered this bug and my Linux was crashed by NULL
pointer dereference.
I think this is a very simple bug.
It happens everytime we open /proc/xenomai/stat,
because the last iter-nentries++; (line 466) surely
Jan Kiszka wrote:
Philippe Gerum wrote:
Philippe Gerum wrote:
Atsushi-san,
Atsushi Katagiri wrote:
Yes, I actually encountered this bug and my Linux was crashed by NULL
pointer dereference.
I think this is a very simple bug.
It happens everytime we open /proc/xenomai/stat,
because
Jan Kiszka wrote:
Jan Kiszka wrote:
Petr Cervenka wrote:
I ran a test during last weekend (and nothing wrong happened). But the
/proc/xenomai/stat output is strange. Probably some type cast error,
because 18446744071739514846 = 0x8A939FDE and the appropriate value
perhaps should
Fillod Stephane wrote:
Jan Kiszka wrote:
/proc/xenomai/stat output is strange. Probably some type cast error,
because 18446744071739514846 = 0x8A939FDE and the appropriate
value perhaps should be 0x8A939FDE = 2324930526.
[...]
Reminds me that other pending patch for
Gilles Chanteperdrix wrote:
Fillod Stephane wrote:
Jan Kiszka wrote:
/proc/xenomai/stat output is strange. Probably some type cast error,
because 18446744071739514846 = 0x8A939FDE and the appropriate
value perhaps should be 0x8A939FDE = 2324930526.
[...]
Reminds me that
Jan Kiszka wrote:
Philippe Gerum wrote:
...
This would be even better with a proper iterator construct.
Something like this? I think I tested most cases successfully (e.g. 4
CPUs with a shared IRQ), but the code should also be better readable,
thus better reviewable. Comments/feedback
Jan Kiszka wrote:
Hi,
bad news, everyone :(. According to the result of some lengthy debug
session with a customer and several ad-hoc lttng instrumentations, we
have a fatal bug in the nucleus' implementation of the lock stealing
algorithm. Consider this scenario:
1. Thread A acquires
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
bad news, everyone :(. According to the result of some lengthy debug
session with a customer and several ad-hoc lttng instrumentations, we
have a fatal bug in the nucleus' implementation of the lock stealing
algorithm. Consider
Here is the fifth maintenance release for the v2.4.x branch. Short
log follows:
[nucleus]
* xnpipe_poll: fix race (message pipe poll/select support).
* Fix memory overwrite when reading /proc/xenomai/stat.
* xnsleep_sleep_on: fix early timeouts (ownership
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
bad news, everyone :(. According to the result of some lengthy debug
session with a customer and several ad-hoc lttng instrumentations, we
have
Jan Kiszka wrote:
According to Linux and the Intel spec, this prefix is not needed.
Obviously, it's not, since the whole purpose of xchg() is to guarantee bus
locking for memory operands anyway. Please merge.
---
include/asm-x86/atomic_32.h |2 +-
1 file changed, 1 insertion(+), 1
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
Please do not use my address at gmail, gna does not want me to post from
this address:
2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org
Xenomai-core@gna.org
R=dnslookup T=remote_smtp: SMTP
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
+#include asm/atomic.h
+
+#if BITS_PER_LONG != 32
+#error Upgrade to kernel 2.6!
+#endif
I am not well versed with the 2.4 support. But are we sure we support no
64 bits architecture with 2.4 ? What about ppc64 ?
No other 2.4 port will be
Jan Kiszka wrote:
Hi,
next issue on my way towards fast native mutexes: as mutexes are now
mostly acquired in user space, the recursion counter lockcnt will only
be maintained in the context of the owning thread (at best: its process)
in user space. No update on the kernel-side lockcnt will
Jan Kiszka wrote:
Hi,
trying to select a sane kernel-side looking scheme for fast native
mutexes, I had a closer look at the registry usage in that skin (and
many others). The typical pattern is
object = xnregistry_fetch(handle);
perform_operation(object);
There is no lock around
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer we want to dereference; we'd better
keep
this unpreemptable, although it's
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer we want to dereference; we'd better
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
But then I wonder
a) why xnregistry_fetch uses nklock at all (even for totally uncritical
XNOBJECT_SELF!)
registry_validate() returns a pointer
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Here comes the complete series of patches to improve the Xenomai
registry. #1, #5, and #6 are resends of already posted patches, the
middle part is fresh from the editor. The series reduces overhead
and simplifies the registry code. Overall
Jan Kiszka wrote:
Some customer ran into the problem of lacking registry slots without
prior warning. We are lacking some report mechanism, specifically for
unexported (anonymous) entries (every native user object requires one
for its handle).
This patch introduces
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Some customer ran into the problem of lacking registry slots without
prior warning. We are lacking some report mechanism, specifically for
unexported (anonymous) entries (every native user object requires one
for its handle
Jan Kiszka wrote:
Here comes the complete series of patches to improve the Xenomai
registry. #1, #5, and #6 are resends of already posted patches, the
middle part is fresh from the editor. The series reduces overhead
and simplifies the registry code. Overall diffstat:
Merged, thanks.
Jan Kiszka wrote:
[ Trying the keep my queue short... ]
This version, posted earlier already, should address all remarks brought
up. OK to commit?
Fine with me.
---
include/nucleus/intr.h | 25 +++-
ksrc/nucleus/intr.c| 76
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
...
I think I'm getting closer to the issue. Our actual problem comes from
the fact that the xnsynch_owner is easily out of sync with the real
owner, it even sometimes points to a former owner:
Jan Kiszka wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
...
I think I'm getting closer to the issue. Our actual problem comes from
the fact that the xnsynch_owner is easily out of sync with the real
owner, it even
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
bad news, everyone :(. According to the result of some lengthy debug
session with a customer and several
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
...
I
Jan Kiszka wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles
Niklaus Giger wrote:
Hi
The attached program works fine under vxWorks 6.6 (powerpc).
Running it under the current xenomai-solo (trunk) on my GNU/Debian
x86 system it gets stuck at line 82:
Here is the output from vxWorks
timex tSysMain
assert passed at tSysMain line 66
assert passed at
Philippe Gerum wrote:
Niklaus Giger wrote:
Hi
The attached program works fine under vxWorks 6.6 (powerpc).
Running it under the current xenomai-solo (trunk) on my GNU/Debian
x86 system it gets stuck at line 82:
Here is the output from vxWorks
timex tSysMain
assert passed at tSysMain line
Jan Kiszka wrote:
Jan Kiszka wrote:
Slowly moving on toward generic fast mutex support for Xenomai, this
patch is a proposal to address the increasing divergence of
owner-tracking vs. owner-less xnsynch objects.
The services dealing with the former will likely include a new, lockless
Niklaus Giger wrote:
Hi
Thanks a lot to Philippe for fixing the previous bug so quickly! Never got
fixed a bug as fast by WindRIver despite having paid quite a lot of money
for it!
inertia = success / competition
Now my testsuite passes almost all tests but crashes, when it spawns
twice
Jan Kiszka wrote:
Hi,
my ipipe patch to detect stalled top-most domains (a new, NMI-safe
version will be posted soon) just reported this:
[1.853028] Xenomai: real-time nucleus v2.5-devel (Flying In A Blue Dream)
loaded.
[2.059367] I-pipe: Detected stalled topmost domain,
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
[1]http://thread.gmane.org/gmane.linux.real-time.xenomai.devel/5412/focus=5405
always-put-xnthread-base-into-registry.patch:
I understand the need, but I will cowardly let Philippe decide whether
he likes the implementation details.
I'm
Gilles Chanteperdrix wrote:
Hi,
on some (all ?) platforms, we get a SIGILL when trying to emit the first
Xenomai syscall, instead of the -ENOSYS return value. This patches
handles the SIGILL by printing an error message and exiting.
This is an issue for archs that encode the syscall
Niklaus Giger wrote:
Hi
Examining errors in my big testsuite I discovered that giving a second
time a binary semaphore xenomai returns an error where vxWorks reports OK.
Thanks for reporting. That patch should fix this issue:
diff --git a/vxworks/semLib.c b/vxworks/semLib.c
index
Gilles Chanteperdrix wrote:
Niklaus Giger wrote:
Hi
Shouldn't the signature not bee
STATUS kernelInit(FUNCPTR rootRtn, int argc, const char * argv[]);
instead of
STATUS kernelInit(FUNCPTR rootRtn, int argc, char *const argv[]);
I think this would be more like a classical definition main.
Niklaus Giger wrote:
While testing I found that the behaviour of lstLib is not mimicked
correctly by Xenomai-Solo.
I wrote a simple testsuite which passed all assertions on my
vxWorks 6.6 system. It compiles under xxWorks and xenomai-solo.
I do not object, if you remove the conditional
Niklaus Giger wrote:
Am Montag 22 September 2008 18.17:10 schrieb Philippe Gerum:
Niklaus Giger wrote:
Hi
For various reasons we were forced to examine under vxWorks 5.5 the
private WIND_TCB safeCnt field to determine whether a task was safe or
not.
With the attached patch I try to add
Niklaus Giger wrote:
Am Montag 22 September 2008 18.17:10 schrieb Philippe Gerum:
Niklaus Giger wrote:
Hi
For various reasons we were forced to examine under vxWorks 5.5 the
private WIND_TCB safeCnt field to determine whether a task was safe or
not.
With the attached patch I try to add
Niklaus Giger wrote:
After a ./configure in my git clone, git status cluttered my screen withe a
lot
of uninteresting files. In order to get rid of them I created the attached
.gitignore files.
Merged, thanks.
Signed-off-by: Niklaus Giger [EMAIL PROTECTED]
---
.gitignore
stephane ancelot wrote:
Hi,
I have the following kernel bug, when using a string name in
rt_sem_create. using NULL as name do not report this problem.
BUG: unable to handle kernel paging request at virtual address de82a268
printing eip: c025d51a *pde = 1dd3e067 *pte =
Oops:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi,
on some (all ?) platforms, we get a SIGILL when trying to emit the first
Xenomai syscall, instead of the -ENOSYS return value. This patches
handles the SIGILL by printing an error message and exiting
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi,
on some (all ?) platforms, we get a SIGILL when trying to emit the first
Xenomai syscall, instead of the -ENOSYS return value. This patches
handles
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes. Actually, translating the native priority
to sched_setscheduler
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Quick question $customer stumbled over: Shouldn't the user space part of
rt_task_set_priority also (or rather?) adjust the Linux priority of the
caller? My impression is yes.
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
AFAIC, I don't see how changing priorities on the fly within a time critical
section could be considered as good programming practice; this would tend to
indicate that somebody is playing with priorities to paper over an
application
design
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
So we should warn the user (in the doc) that rt_task_set_priority will
leave an inconsistent priority distribution between Linux and Xenomai
behind? But what is that propagation path in xnpod_renice_thread_inner
good
Gilles Chanteperdrix wrote:
Hi,
I am working on using SIGWINCH to trigger priority changes in
user-space. And I am afraid it will never really work:
- Xenomai makes a difference between the base priority of a thread and
its current priority. But pthread_getschedparam should return the base
1001 - 1100 of 1458 matches
Mail list logo
