Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
This patch fixes type long overflows, invalid command line argument
types and gives the receiver and transmitter thread dedicated names.
Signed-off-by: Wolfgang Grandegger w...@denx.de
diff --git a/examples
Hi,
here is a second attempt of debugging stuff, taking into account the previous
remarks.
--
Gilles Chanteperdrix
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
---
include/asm-generic/bits/bind.h |2 ++
src/skins/common/bind.c | 14 ++
src/skins/native/task.c |2 ++
src/skins/posix/thread.c|2 ++
src/skins/psos+/task.c |2 ++
src/skins/uitron/task.c |9 +++--
6 files changed,
---
src/testsuite/latency/latency.c | 109 ---
1 files changed, 78 insertions(+), 31 deletions(-)
diff --git a/src/testsuite/latency/latency.c b/src/testsuite/latency/latency.c
index f82a072..ca5f1bf 100644
--- a/src/testsuite/latency/latency.c
+++
---
include/asm-generic/bits/pod.h |2 +-
include/asm-generic/system.h | 27 +--
include/nucleus/queue.h| 16
ksrc/nucleus/Kconfig | 12
ksrc/nucleus/intr.c|4 ++--
ksrc/nucleus/pod.c |
Wolfgang Grandegger wrote:
Hi Gilles
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
From: Wolfgang Grandegger w...@denx.de
This patch series adds RT-Socket-CAN support for the MSCAN on the MPC512x
from Freescale
Hi,
I post here, for review, 3 patches which helped me debugging. I await
your opinion before merging them.
TIA,
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
---
include/asm-generic/bits/bind.h |2 ++
src/skins/common/bind.c | 14 ++
src/skins/native/task.c |2 ++
src/skins/posix/thread.c|2 ++
src/skins/psos+/task.c |2 ++
src/skins/uitron/task.c |9 +++--
6 files changed,
---
src/testsuite/latency/latency.c | 103 +++---
1 files changed, 73 insertions(+), 30 deletions(-)
diff --git a/src/testsuite/latency/latency.c b/src/testsuite/latency/latency.c
index f82a072..9af785e 100644
--- a/src/testsuite/latency/latency.c
+++
---
include/asm-generic/bits/pod.h |2 +-
include/asm-generic/system.h | 19 +--
include/nucleus/queue.h| 16
ksrc/nucleus/intr.c|4 ++--
ksrc/nucleus/pod.c | 16
ksrc/skins/posix/signal.c |
Wolfgang Grandegger wrote:
From: Wolfgang Grandegger w...@denx.de
This patch series adds RT-Socket-CAN support for the MSCAN on the MPC512x
from Freescale by introducing a new OF platform driver for both, the
MPC521x and MPC5200, while still keeping the old driver for the MPC5200
for
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
From: Wolfgang Grandegger w...@denx.de
This patch series adds RT-Socket-CAN support for the MSCAN on the MPC512x
from Freescale by introducing a new OF platform driver for both, the
MPC521x and MPC5200, while
Wolfgang Grandegger wrote:
Wolfgang Grandegger wrote:
pdir=../send-rtcan-mscan-mpc5xxx/
sprefix=PATCH xenomai-2.5
commitid=b197fe0f370d92ee1838b370fbf927ca50a0e573
subject=rtcan: mscan: new OF platform driver for MPC521x and MPC5200
blurb=\
This patch series adds RT-Socket-CAN support for
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
When exiting a process, rtdk buffers are not flushed. Fix that by
introducing a destructor for the library which flushes the buffers.
When forking, if the main thread has an rt_printf buffer
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
When exiting a process, rtdk buffers are not flushed. Fix that by
introducing a destructor for the library which flushes the buffers.
When forking, if the main thread has an rt_printf buffer, it is reused by
the child, which is a good thing
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
When exiting a process, rtdk buffers are not flushed. Fix that by
introducing a destructor for the library which flushes the buffers.
When forking, if the main thread has an rt_printf buffer
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
When exiting a process, rtdk buffers are not flushed. Fix that by
introducing a destructor for the library which flushes the buffers.
When forking, if the main thread has an rt_printf buffer
Hi,
due to bugs, it may happen that the latency test spots are due to
involuntary mode switches to secondary mode. This is bad, because users
testing xenomai quickly on their platform may find a bad latency, and go
quickly to conclusions without even posting a mail on the mailing lists.
When exiting a process, rtdk buffers are not flushed. Fix that by
introducing a destructor for the library which flushes the buffers.
When forking, if the main thread has an rt_printf buffer, it is reused by
the child, which is a good thing, however, it is not emptied, so could cause
the same
Wolfgang Grandegger wrote:
Hello,
I get the following error when building GIT head of xenomai-2.4 for PowerPC:
Making all in cyclic
make[3]: Entering directory
`/work/wolf/pdm360ng/xenomai-2.4/src/testsuite/cyclic'
/bin/sh ../../../libtool --tag=CC --mode=link
Wolfgang Grandegger wrote:
Hello,
I get the following error when building GIT head of xenomai-2.4 for PowerPC:
Making all in cyclic
make[3]: Entering directory
`/work/wolf/pdm360ng/xenomai-2.4/src/testsuite/cyclic'
/bin/sh ../../../libtool --tag=CC --mode=link
The following changes since commit e1db93a63545cb99b8f615b69aff22920fa0ee39:
Philippe Gerum (1):
blackfin: export atomic set/clear mask fns
are available in the git repository at:
git://git.xenomai.org/xenomai-gch.git for-head
Gilles Chanteperdrix (3):
analogy: comment out
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
This testcase checks if the value in xnvdso-features matches the
value of XNVDSO_FEATURES, that is, if the information is correctly
transferred from kernel to userland.
Notice
Alexis Berlemont wrote:
Hi Gilles,
Gilles Chanteperdrix wrote:
Alexis Berlemont wrote:
Hi Gilles,
Gilles Chanteperdrix wrote:
Hi,
Since I started talking about it, I have run build tests fixing a few
things here and there. The current status is this (still at the same
place: http
Philippe Gerum wrote:
On Sat, 2009-12-26 at 19:09 +0100, Gilles Chanteperdrix wrote:
Alexis Berlemont wrote:
Hi Gilles,
Gilles Chanteperdrix wrote:
Alexis Berlemont wrote:
Hi Gilles,
Gilles Chanteperdrix wrote:
Hi,
Since I started talking about it, I have run build tests fixing a few
Wolfgang Mauerer wrote:
This testcase checks if the value in xnvdso-features matches the
value of XNVDSO_FEATURES, that is, if the information is correctly
transferred from kernel to userland.
Notice that the approach will fail once configurations are supported
that know of multiple
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
This testcase checks if the value in xnvdso-features matches the
value of XNVDSO_FEATURES, that is, if the information is correctly
transferred from kernel to userland.
Notice that the approach will fail once
Patrice Kadionik wrote:
Gilles Chanteperdrix a écrit :
Hi,
Since I started talking about it, I have run build tests fixing a few
things here and there. The current status is this (still at the same
place: http://sisyphus.hd.free.fr/~gilles/bx):
Hi,
I've watched your log file
Alexis Berlemont wrote:
Hi Gilles,
Gilles Chanteperdrix wrote:
Hi,
Since I started talking about it, I have run build tests fixing a few
things here and there. The current status is this (still at the same
place: http://sisyphus.hd.free.fr/~gilles/bx):
* analogy: I have tried to disable
wolfgang.maue...@siemens.com wrote:
From: Wolfgang Mauerer wolfgang.maue...@siemens.com
A new structure (struct xnshared) is introduced. It allows us to share
generic data between user and kernel of Linux and Xenomai; a bitmap
of feature flags located at the beginning of the structure
Hi,
Since I started talking about it, I have run build tests fixing a few
things here and there. The current status is this (still at the same
place: http://sisyphus.hd.free.fr/~gilles/bx):
* analogy: I have tried to disable some parts of analogy when compiling
on machines without CONFIG_PCI,
The following changes since commit 0cb257bf7393b5a53eb35b021b95730bd40dd561:
Philippe Gerum (1):
Merge commit 'gilles'
are available in the git repository at:
git://git.xenomai.org/xenomai-gch.git for-head
Gilles Chanteperdrix (3):
arith: avoid ARM Linux do_div compile-time
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 are included everywhere. This said,
not prefixing a Xenomai symbol with something
Gilles Chanteperdrix wrote:
wolfgang.maue...@siemens.com wrote:
+/*
+ * We re-use the global semaphore heap to provide a multi-purpose shared
+ * memory area between Xenomai and Linux - for both kernel and userland
+ */
+void __init xnheap_init_shared(void)
+{
+xnshared = (struct
Wolfgang Mauerer wrote:
+enum xnshared_features {
+/* XNSHARED_FEAT_A = 1,
+ XNSHARED_FEAT_B, */
+ XNSHARED_MAX_FEATURES,
+};
Xenomai style is to use defines bit with the bit shifted directly, so,
XNSHARED_FEAT_A would rather be 0x0001, and I am not sure an
enum can be 64
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 are included everywhere
Jan Kiszka wrote:
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
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
+enum xnshared_features {
+/* XNSHARED_FEAT_A = 1,
+ XNSHARED_FEAT_B, */
+ XNSHARED_MAX_FEATURES,
+};
Xenomai style is to use defines bit with the bit shifted directly, so,
XNSHARED_FEAT_A would rather
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
+enum xnshared_features {
+/* XNSHARED_FEAT_A = 1,
+ XNSHARED_FEAT_B, */
+ XNSHARED_MAX_FEATURES,
+};
Xenomai style is to use defines bit
Philippe Gerum wrote:
On Mon, 2009-12-21 at 09:58 +0100, Jan Kiszka wrote:
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
Jan Kiszka wrote:
xenomai-git-requ...@gna.org wrote:
Date: Mon, 21 Dec 2009 16:04:33 +0100
From: GIT version control g...@xenomai.org
Subject: [Xenomai-git] Gilles Chanteperdrix : rtcan: use the new
pci_ids header for pci rtcan drivers
To: xenomai-...@gna.org
Message-ID: e1nmjoh-0003st
variables
Gilles Chanteperdrix (9):
nmi: fix build for linux 2.4
analogy: fix build for 2.4 kernel
rtcan: make rtcan pci board depend on CONFIG_PCI
posix: add missing space to Config.in
xconfig 2.4: make xconfig work again with linux 2.4
build: fix prepare
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.
What latest fixes? Are they
Philippe Gerum wrote:
On Mon, 2009-12-14 at 14:32 +0100, 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
Philippe Gerum wrote:
On Mon, 2009-12-14 at 14:32 +0100, 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
Richard Cochran wrote:
On Wed, Dec 02, 2009 at 02:23:39PM +0100, Gilles Chanteperdrix wrote:
This issue has been discussed several times, but never a lot. We have a
simple solution: starting with 2.4 (if I remember correctly) xenomai
provides clock_settime, so you can simply rely
Peter Soetens wrote:
Hi guys,
I'm using the master branch, 4f42de74 with Linux 2.6.31.1 and the
adeos patch from that tree. My app links with both -lnative and
-lposix with the wrappers (using xeno-config).
I'm experiencing a segfault within pthread_cancel() when calling
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
Wolfgang:
Jan Kiszka wrote:
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
Paolo Bernini wrote:
Hello all, first of all I introduce myself: I am Paolo Bernini and I
am a student of University of Pisa.
While working on my thesis I wrote a real time driver for i.MX
special serial devices based on current implementation of 16550A. It
is very simple, it has several
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...@xenomai.org
wrote:
Wolfgang
The following changes since commit 4f42de74f9b9a1d29093ba695e5ae0ff4a66a132:
Philippe Gerum (1):
x86: upgrade I-pipe support to 2.6.31.1-x86-2.4-07
are available in the git repository at:
git+ssh://git.xenomai.org/xenomai-gch.git for-head
Gilles Chanteperdrix (2):
signals
://git.xenomai.org/xenomai-gch.git for-head
Gilles Chanteperdrix (3):
signals: reduce signals handling memory footprint
posix: cosmetic cleanup of pthread_cond_*wait
posix: revert commit 58c1b922a96fedaef110c925a0dddb0e86dbcaf4
Peter Soetens (1):
posix: Fix __wrap_select() when timeout
The following changes since commit 0b6b63885e91bd18c0aa31c935a0a1a5d44ef152:
Philippe Gerum (1):
blackfin: fix all syscall templates
are available in the git repository at:
git+ssh://git.xenomai.org/xenomai-gch.git for-2.4
Gilles Chanteperdrix (5):
posix: fix pthread_cond_wait
Wolfgang Mauerer wrote:
The kernel need to synchronize with user land, so the problem is
(almost) the same as with obtaining the original data from Linux
directly: user land can only use a retry or a smart fall-back
mechanism
to obtain consistent data.
Well, ok, I imagine something like a
Wolfgang Mauerer wrote:
Hi,
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
So that means, in essence, that you would accept probabilistic
algorithms in realtime context?
Ah, today's troll!
though it seems that I have to replace Jan this time ;-)
As I think I explained, the use
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:
Wolfgang Mauerer wrote:
So that means, in essence, that you would accept probabilistic
algorithms in realtime
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:
Wolfgang Mauerer wrote:
So that means, in essence
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
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 domain.
Yes, the real issue
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 on Linux
must be transferred
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 and simply
sharing data between kernel
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 only works on x86. Whereas
implementing clock slew down/acceleration
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 only works on x86. Whereas
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 any return to
user-space
Jan Kiszka wrote:
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
Jan Kiszka wrote:
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
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I surely don't want to duplicate ntp code, just the results it spits out
(e.g. into the vdso page).
Ok, good point, we can avoid duplicating ntp code, but the vdso page
trick only works on two architectures. So, IMO, the nucleus should get
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I surely don't want to duplicate ntp code, just the results it spits out
(e.g. into the vdso page).
Ok, good point, we can avoid duplicating ntp code, but the vdso page
trick only works on two
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I surely don't want to duplicate ntp code, just the results it spits out
(e.g. into the vdso page).
Ok, good point, we can avoid duplicating ntp code, but the vdso
the signal
support.
The following changes since commit 5a29ba38d7563097b73f53615fb3fcb7a7e5a6a5:
Philippe Gerum (1):
nucleus: initialize heap-stat_link holder
are available in the git repository at:
git+ssh://git.xenomai.org/xenomai-gch.git for-head
Gilles Chanteperdrix (12):
bind
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
Peter Soetens wrote:
On Thu, Nov 5, 2009 at 02:46, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
Peter Soetens wrote:
Hi,
I'm creating my RT threads using the native API and I'm creating
mqueues, wrapped to the pthread_rt library.
I can read and write the mqueue (and it goes
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);
+
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, sizeof(heap-label), label
Hi,
in preparation for adding more code common to all skins (signals
handling), I split bind.h into three files, which are compiled as a
convenience library linked to every skin library.
I have pushed this first modification for review, you can see the
changes here:
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 repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka
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 repository at:
git
Anisha Kaul wrote:
hi,
Hi,
Please do not reply to an unrelated mail when asking a new question.
Mail clients which do proper threading, such as the mailing list
archives will show it in the same thread as the mail you reply to.
Is there any command or technique to know when your kernel
Anisha Kaul wrote:
Dear all,
Hi,
I know that outb() being a linux system call can be used to write to the
serial/parallel ports. Currently I am working on a real time operating system
with Xenomai and a micro kernel. If I use outb() for port access, control
will shift to the soft-real
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.
I'm using a posix-skin based user-space Xenomai application that runs
Remco den Breeje wrote:
Attached you find an example.
No. There is nothing attached.
--
Gilles
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Remco den Breeje wrote:
Classic.
Ok. I see nothing wrong, I will have a look at this tonight.
--
Gilles
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Remco den Breeje wrote:
Classic.
Ah. Sorry. Found the bug in the mean time. It is in the Makefile. You do
not pass the compilation flags for compilation for Xenomai posix skin.
So, your user space application uses plain linux semaphores.
See:
doc/txt/pse51-skin.txt in xenomai sources
or:
Remco den Breeje wrote:
On Mon, Nov 9, 2009 at 3:49 PM, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
Ah. Sorry. Found the bug in the mean time. It is in the Makefile. You do
not pass the compilation flags for compilation for Xenomai posix skin.
So, your user space application
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 hard IRQs
while accessing this
tarek ben ali wrote:
-- Forwarded message --
From: *tarek ben ali* tarekben...@gmail.com mailto:tarekben...@gmail.com
Date: 2009/11/3
Subject: How to fix static priority to processes known in advance
To: xenomai-core@gna.org mailto:xenomai-core@gna.org
Hi All,
I am
cagnul...@tin.it wrote:
I've tried with your patch and asking to do latency test with 1000ns but
It is 1000us, not 1000ns. No platform running xenomai is able to sustain
a task with a 1000ns period.
the result is still the same :(
Do you have any other ideas? I'm very lost in space :(
The
Rubén González del Pozo wrote:
Hello all,
I am working with Xenomai 2.4.9.1 on Kernel 2.6.30. I try to test the
pperiodic example and I always get the error code 3 in
pthread_make_periodic_np function: ESRCH - invalid thread.
Why I get that code?
Thanks a lot,
It is hard to say why it
Guanghui, Cheng wrote:
Hello:
I need to use hpet device as my clock event source in my os
and i have mapped this device to local place. But when i read the
configuration or value all the bit is 1. Is it something wrong?
Excuse me, but what is the relation with Xenomai?
--
Peter Soetens wrote:
Hi,
I'm creating my RT threads using the native API and I'm creating
mqueues, wrapped to the pthread_rt library.
I can read and write the mqueue (and it goes through Xenomai), but
when I select() on a receiving mqd_t, the select() calls returns that
there is data
cagnul...@tin.it wrote:
Hi, i've got a system running kernel 2.6.22 on a ARM9 / Freescale i.MX27
The system running well, but every time i run latency it hangs.
It occurs with rtprint too.
Could you help me?
See:
https://mail.gna.org/public/xenomai-core/2009-08/msg00021.html
And you can not
Stefan Schaal wrote:
Hi Jan,
you pointer to the 4a2cb7b817 help! We had -lrtdk before -
lpthread -lpthread_rt in our compile statement. Just in 2.4.8, this
seems to make no difference.
Do you use the wrap-link.sh script, or is this order change unrelated?
--
Alexis Berlemont wrote:
Hi Philippe,
Sorry, I forgot the prefix rule for the short log for many commits. I will
take more care starting from now.
You can edit commit messages with git rebase --interactive
Of course, if you want to push the changes on the server, you will have
to use git
Jan Kiszka wrote:
This extends /proc/xenomai/heap with statistics about the global as well
as all per-process semaphore heaps. This is helpful to track down the
reason for ENOMEM (system or sem heap full?) and to find out that we
are leaking memory from the global heap on automatic native
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(heapq_lock);
You can not
Peter Soetens wrote:
On Thu, Oct 1, 2009 at 17:34, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
Peter Soetens wrote:
On Thu, Oct 1, 2009 at 16:47, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
Peter Soetens wrote:
Hi,
I'm creating my RT threads using
Hi,
for those interested into the FCSE patch, as told in the paper presented
to the XUM (but that is a detail which I forgot to mention in the
presentation), the FCSE patch was split into several parts (10 actually)
and submitted to the linux arm kernel mailing list.
You may find the post here:
Henri Roosen wrote:
Hi Gilles,
We are using the FCSE on our at91sam9263 boards because we need the
lowest latency. Our measurements show almost a factor of 2 in latency
reduction, which is very similar to what you presented at the XUM.
Good to know.
Are there any known issues with FCSE
Gilles Chanteperdrix wrote:
Peter Soetens wrote:
On Thu, Oct 1, 2009 at 17:34, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
Peter Soetens wrote:
On Thu, Oct 1, 2009 at 16:47, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
Peter Soetens wrote:
Hi,
I'm
501 - 600 of 1571 matches
Mail list logo
