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 them now, and keep the rest
for
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 start a
discussion about
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 for
this support which would
Philippe Gerum wrote:
On Fri, 2009-10-02 at 19:48 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Ok. So, if we add the core skin fdtable, this leaves us with two items:
- signals in primary domain
- core skin fdtable
Ack. Add the following I-pipe stuff as well:
- nios2 design
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 ASAP, we should try to think
Jan Kiszka wrote:
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
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Ok. How many interrupt controllers would be impacted by the PIC mute
feature?
Most of the ARM PICs (with their cascaded GPIOs). I have to admit that I
do not keep track of how many arm processors we actually support, but
there's a handful
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 with an addition in user-space for
most
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 that calling it again after a connection
Philippe Gerum wrote:
On Tue, 2009-09-29 at 19:50 +0200, Gilles Chanteperdrix wrote:
Hi,
During my flights and connections, I had a thought about this primary
mode signals issue.
Since the needs in term of primary mode signals greatly depends on what
the skins want to do with it (native
Philippe Gerum wrote:
On Tue, 2009-09-29 at 19:50 +0200, Gilles Chanteperdrix wrote:
Hi,
During my flights and connections, I had a thought about this primary
mode signals issue.
Since the needs in term of primary mode signals greatly depends on what
the skins want to do with it (native
Philippe Gerum wrote:
On Thu, 2009-10-01 at 12:17 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Tue, 2009-09-29 at 19:50 +0200, Gilles Chanteperdrix wrote:
Hi,
During my flights and connections, I had a thought about this primary
mode signals issue.
Since the needs in term
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 the native API and I'm creating
mqueues, wrapped to the pthread_rt library.
I can read and write the mqueue (and it goes
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 if we answer positively
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 if we answer positively
Peter Soetens wrote:
On Wed, Sep 30, 2009 at 16:27, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org 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
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.
Here is a first list, please feel free to criticize it:
- signals in primary domain (something that we almost forgot)
- xnsynch_acquire using
Hi,
During my flights and connections, I had a thought about this primary
mode signals issue.
Since the needs in term of primary mode signals greatly depends on what
the skins want to do with it (native wants hooks, posix wants posix
conformant signals), I think as much work as possible should
The following changes since commit 2d29c076e15c1e0bb2aa1fa83b132da230aeab60:
Philippe Gerum (1):
scripts: allow concurrent invocations of wrap-link.sh
are available in the git repository at:
git://git.xenomai.org/xenomai-gch.git for-head
Gilles Chanteperdrix (1):
Do not use
The following changes since commit 8e46e88f80eb8ff52f4af020e3b44b437df234e2:
Philippe Gerum (1):
scripts: allow concurrent invocations of wrap-link.sh
are available in the git repository at:
git://git.xenomai.org/xenomai-gch.git for-2.4
Gilles Chanteperdrix (1):
Do not use
Philippe Gerum wrote:
We had a couple of brown paper bag issues in v2.4.9, particularly in the
interrupt pipeline for the ARM port, but also a time conversion bug
which basically affects any architecture with high frequency CPUs
(x86-ers, this one is for you).
A note for users of Xenomai on
Felipe Castro wrote:
Hi ,
I'm trying xenomai running on PXA270 Voipac module.
Acctually i have a problem when running the lantency test program.
The module loads OK , but when i run latency program:
[ 110.874334] Xenomai: starting native API services.
[ 282.865308] I-pipe: Detected
Felipe Castro wrote:
Well , i found the topic, but I'm using kernel 2.6.27 with xenomai 2.4.8 and
the code to be patched is a little bit different. I dont't know how to do ,
can you help me ?
The code has not changed, but I think my patch was mangled, please try
the attached one.
--
The following changes since commit 1c6417e62b1c9412bb278c340c1512f8ba4660d0:
Matteo Facchinetti (1):
rtcan: fix MPC5xxx_GPIO definition for 2.6.2[0-4] kernels
are available in the git repository at:
git+ssh://g...@git.xenomai.org/xenomai-gch.git for-head
Gilles Chanteperdrix (12
felipe felipe wrote:
Hi all ,
I'm starting with xenomai, i tried to get a realtime linux embedded for
a medical device.
I run some examples, but I'm a little bit lost.
I tried to run the cross-link example , tha uses the module xeno_16550A
but it seems that this module is not compatible
Jan Kiszka wrote:
+#define LOAD_ARGS_0()asm volatile ( ::: memory);
g++, at least some verions in the past, chokes on ::: so, you should do
: /* */ : /* */ :
--
Gilles.
___
Xenomai-core mailing
Jan Kiszka wrote:
gcc-4.1.3 of kubuntu has problem with proper syscall register
initialization in rt_task_shadow if TLS is enabled. But it is likely
that more compiler versions below 4.3 and more configuration variants
are affected.
This patch installs a workaround for these gcc versions
Richard Cochran wrote:
A certain xenomai project on ARM Linux of mine has been working fine
using gcc 3.4.5. I wanted to use a more recent compiler and the EABI,
so I used a default setting from crosstool-NG-1.4.1, which produces
gcc version 4.3.2.
However, I get the following result
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi again,
this is now basically the patch which seems to stabilized x86 /wrt mmu
switches again:
There were 3 race windows between
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Philippe,
what problem did you had to address with commit 6346c046b1? I'm asking
as it most probably breaks what e7d889f56c tried to fix (e.g. double
definitions of PTHREAD_PRIO_* with recent glibcs).
The problem was that with uclibc
Jan Kiszka wrote:
Hi Philippe,
what problem did you had to address with commit 6346c046b1? I'm asking
as it most probably breaks what e7d889f56c tried to fix (e.g. double
definitions of PTHREAD_PRIO_* with recent glibcs).
The problem was that with uclibc, pthread_mutexattr_set_prio_inherit
Jan Kiszka wrote:
Hi again,
this is now basically the patch which seems to stabilized x86 /wrt mmu
switches again:
There were 3 race windows between setting active_mm of the current task
and actually switching it (that's a noarch issue), there were several
calls into switch_mm without
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Wed, 2009-07-01 at 20:15 +0200, Philippe Gerum wrote:
On Wed, 2009-07-01 at 19:56 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Gilles
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
On archs with non-atomic switch_mm(), use_mm() will require a different
strategy. I'm thinking about something like
use_mm():
set_some_flag();
barrier();
current-mm = new_mm;
current-active_mm = new_mm
Nocia wrote:
Hi all,
I'm a beginer in the Xenomai world.
I'm working on the Xenomai kernel in order to minimize the power
consumption, for my university final project
(/http/://xenomaiote.googlecode.com).
To do that I'm trying to implement OTE (one time extension).
Ok, I have found
Jan Kiszka wrote:
Jan Kiszka wrote:
It's still unclear what goes on precisely, we are still digging, but the
test system that can produce this is highly contended.
Short update: Further instrumentation revealed that cr3 differs from
active_mm-pgd while we are looping over that fault, ie.
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
It's still unclear what goes on precisely, we are still digging, but the
test system that can produce this is highly contended.
Short update: Further instrumentation revealed that cr3 differs from
active_mm
Jan Kiszka wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
It's still unclear what goes on precisely, we are still digging, but the
test system that can produce this is highly contended.
Short update: Further instrumentation revealed that cr3 differs
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi all,
seen such loops before? This particular trace is from a 2.6.29.3 kernel
with ipipe-2.3-01 (SMP/PREEMPT_VOLUNTARY), but the same happens with
2.6.29.5/2.3-03:
:| +func-6530.084 __ipipe_handle_exception+0x11
Philippe Gerum wrote:
On Tue, 2009-06-30 at 11:21 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Tue, 2009-06-30 at 10:42 +0200, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi all,
seen such loops before? This particular trace is from a 2.6.29.3 kernel
Philippe Gerum wrote:
On Tue, 2009-06-30 at 11:26 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Tue, 2009-06-30 at 11:21 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Tue, 2009-06-30 at 10:42 +0200, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Jan Kiszka wrote
Hi,
for people having problems posting to the list, that is who can send
mails to the list, but who do not see the message they posted either on
the mailing list or on the mailing list archives, your message probably
has been tagged as spam by gna.org, and you may find it in the spam
archives:
Shashank Bhatia wrote:
My CPU is a dual core intel processor 1.8 GHz, and i am using
xenomai-2.4.8 with 2.6.28.9 kernel.
Hi,
You are still posting to the xenomai-core mailing list whereas you
should post to the xenomai-help mailing list.
I can not reproduce your issue, so could you provide us
Ravikiran Saralaya wrote:
1. The uITRON specification requires task creation to accept base
address of task stack to be allocated. The xnarch_alloc_stack() currently
accepts only stack size but not the base address.
The solution is simple: let the system allocate the stack, or implement
Shashank Bhatia wrote:
Dear All,
I had tried using ubuntu with xenomai, but the installation
guide given on the Xenomai website does not work. I have the latest
ubuntu 9.04 jaunty. The steps written work, but finally, when i try to
boot into the newly patched and compiled
Gilles Chanteperdrix wrote:
Shashank Bhatia wrote:
Dear All,
I had tried using ubuntu with xenomai, but the installation
guide given on the Xenomai website does not work. I have the latest
ubuntu 9.04 jaunty. The steps written work, but finally, when i try to
boot into the newly
Shashank Bhatia wrote:
Thanks a lot Gilles,
I used the Xenomai 2.4.8 version with a newer kernel 2.6.28.9 to be
precise.
You are still posting to the wrong list. I will not answer, since
otherwise you will continue ignoring me when I tell you that you are
posting to the wrong list.
The mail
Sebastian Smolorz wrote:
Hi Philippe,
with latest head it is not possible to build the POSIX skin as module. It
gives:
ERROR: xnarch_divrem_billion [kernel/xenomai/skins/posix/xeno_posix.ko]
undefined!
Obviously an
EXPORT_SYMBOL(xnarch_divrem_billion);
is missing.
Well, no.
Philippe Gerum wrote:
On Mon, 2009-06-22 at 14:06 +0200, Gilles Chanteperdrix wrote:
Sebastian Smolorz wrote:
Hi Philippe,
with latest head it is not possible to build the POSIX skin as module. It
gives:
ERROR: xnarch_divrem_billion [kernel/xenomai/skins/posix/xeno_posix.ko]
undefined
Philippe Gerum wrote:
On Mon, 2009-06-22 at 14:47 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Mon, 2009-06-22 at 14:06 +0200, Gilles Chanteperdrix wrote:
Sebastian Smolorz wrote:
Hi Philippe,
with latest head it is not possible to build the POSIX skin as module. It
gives
Shashank Bhatia wrote:
Dear All,
I have been trying to install Xenomai on my Dual Core
Intel Machine. This CPU has 2 cores, so i wanted to enable the SMP flag
in the kernel configuration.
I started with downloading kernel ver 2.6.25.11 from kernel.org, and got
adeos patch as
Following usual Linux rules, asm/* headers should be included after linux/*
headers, and this fixes the following warning on ARM:
In file included from arch/arm/include/asm/pgtable.h:449,
from kernel/xenomai/skins/rtdm/drvlib.c:37:
include/asm-generic/pgtable.h:305: warning: 'struct
martin mangard wrote:
Hello
I made a patch in order to support the Atmel AT91SAM9G20 processor,
which has to be applied after the adeos-ipipe-2.6.27-arm-* patch.
Due to the similarities between the AT91SAM9260 and the AT91SAM9G20
processor, only a few changes were necessary. I booted the
Gilles Chanteperdrix wrote:
martin mangard wrote:
Hello
I made a patch in order to support the Atmel AT91SAM9G20 processor,
which has to be applied after the adeos-ipipe-2.6.27-arm-* patch.
Due to the similarities between the AT91SAM9260 and the AT91SAM9G20
processor, only a few changes
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
In case the user thinks rtdm_lock_get could be used like spin_lock or
messes up the IRQ protection for other reasons, catch this with a
XENO_BUGON.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/rtdm
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
In case the user thinks rtdm_lock_get could be used like spin_lock or
messes up the IRQ protection for other reasons, catch
Gilles Chanteperdrix (9):
Remove SIGSHADOW debug message
Use PIC mute routines on the ARM platform
Fix computation of heap overhead
Adapt to preemptible context switch proposed by newer I-pipe patches
Fix user-space tsc on ARM
Fix git whitespace warnings
Hi,
The following changes since commit 7790ec248f04581ca1194c5f48a82df51864761b:
Philippe Gerum (1):
Fix signedness of divisor
are available in the git repository at:
git+ssh://git.xenomai.org/xenomai-gch.git for-2.4
Gilles Chanteperdrix (3):
x86 FPU fixes
Fix
Jan Kiszka wrote:
I think the trick against /this/ is preempt_disable/enable in
kernel_fpu/begin/end. But that won't work for Xenomai, of course.
Well, that does not prevent an IRQ or a page fault from computing a RAID
cheksum...
--
Gilles.
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I think the trick against /this/ is preempt_disable/enable in
kernel_fpu/begin/end. But that won't work for Xenomai, of course.
Well, that does not prevent an IRQ or a page fault from computing a RAID
cheksum
Jan Kiszka wrote:
Martin Shepherd wrote:
On Wed, 13 May 2009, Jan Kiszka wrote:
...
Martin, could you check if this helps you, too?
It doesn't appear to help. To check, first I turned on the HPET and PM
timer options, and recompiled the kernel without your patch, to verify
that this
Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
I'm currently facing a nasty effect with switchtest over latest git
head
(only tested this so far): running it inside my test VM (ie. with
frequent excessive latencies) I get a stalled Linux timer IRQ quite
quickly. System
Philippe Gerum wrote:
On Thu, 2009-05-14 at 14:52 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Thu, 2009-05-14 at 12:20 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Wed, 2009-05-13 at 18:10 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Wed, 2009-05-13 at 17:28 +0200
Jan Kiszka wrote:
Hi Gilles,
I'm currently facing a nasty effect with switchtest over latest git head
(only tested this so far): running it inside my test VM (ie. with
frequent excessive latencies) I get a stalled Linux timer IRQ quite
quickly. System is otherwise still responsive, Xenomai
Philippe Gerum wrote:
On Wed, 2009-05-13 at 14:04 +0200, Steven Kauffmann wrote:
Hi all,
If I connect a debugger to my application, other Xenomai periodic
threads (threads that not belong to the current process I'm debugging
) are not scheduled anymore. Attached you can find a simple example
Philippe Gerum wrote:
On Wed, 2009-05-13 at 15:16 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Wed, 2009-05-13 at 14:04 +0200, Steven Kauffmann wrote:
Hi all,
If I connect a debugger to my application, other Xenomai periodic
threads (threads that not belong to the current
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
I'm currently facing a nasty effect with switchtest over latest git head
(only tested this so far): running it inside my test VM (ie. with
frequent excessive latencies
Jan Kiszka wrote:
[ Please pull from git://git.xenomai.org/xenomai-jki.git for-2.4.x ]
The test for __xn_access_ok was inverted, thus rejected valid requests.
Fix this and refactor the code in order to check for the actual size of
the passed fd sets.
Signed-off-by: Jan Kiszka
Steven Seeger wrote:
If a userspace application running xenomai threads is large (1MB or
so) then the code can't all live in cache on our puny 16kb instruction
cache. Does the cache handling occur as needed in the primary domain
or does it have to wait for Linux to handle it?
You should
Philippe Gerum wrote:
On Tue, 2009-04-28 at 07:50 +0200, Gilles Chanteperdrix wrote:
Hi,
currently, the situation is this:
- the timing core uses an approximate value of the cpu frequency (using
xnarch_llmulshft) to do conversions between tsc and ns;
- the APIC timer reprogrammation still
Philippe Gerum wrote:
On Tue, 2009-04-28 at 14:21 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Tue, 2009-04-28 at 07:50 +0200, Gilles Chanteperdrix wrote:
Hi,
currently, the situation is this:
- the timing core uses an approximate value of the cpu frequency (using
Gilles Chanteperdrix wrote:
Hi,
currently, the situation is this:
- the timing core uses an approximate value of the cpu frequency (using
xnarch_llmulshft) to do conversions between tsc and ns;
- the APIC timer reprogrammation still uses imuldiv, that is a more
exact cpu frequency, coupled
Jan Kiszka wrote:
...and clean up a duplicate wrapping.
Ok. I think however that we should try and use the restrict keyword
when the POSIX specs ask us to use it (and I know that it is probably
missing in some places else).
--
Gilles.
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Please pull from git://git.xenomai.org/xenomai-jki.git for-upstream
and run bootstrap.
--
Recent glibc versions come with support for
pthread_mutexattr_get/setprotocol and pthread_condattr_get/setclock.
Make sure we
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Please pull from git://git.xenomai.org/xenomai-jki.git for-upstream
and run bootstrap.
--
Recent glibc versions come with support for
pthread_mutexattr_get/setprotocol
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Please pull from git://git.xenomai.org/xenomai-jki.git for-upstream
and run bootstrap.
--
Recent glibc versions come
Steven Seeger wrote:
Can xenomai preempt its own system calls? We ran latency with our
app. We had a thread waiting on a cond, and when we signaled that
cond, the latency jumped from ~70us to almost 400us even though
latency runs a higher priority thread than the thread that we wake up.
Mark Saiia wrote:
Gilles and list,
I have tested out your latest patch with 2.4maint, 2.627.19. It
appears to work fine, no crashes related to 3dnow and no floating
point issues. However, we are observing rather high latencies. This
is without the hack described in the above thread.
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi,
it seems that rt_task_shadow currently leaves the self tsd assigned (and
uninitialized) in case of error. So, here is an attempt to fix this
situation:
Good point.
Index: src/skins/native/task.c
Hi,
it seems that rt_task_shadow currently leaves the self tsd assigned (and
uninitialized) in case of error. So, here is an attempt to fix this
situation:
Index: src/skins/native/task.c
===
--- src/skins/native/task.c
Steven Seeger wrote:
Can alarms be used in userspace? I ask because the docs still say RTDM
timers can be used in userspace but Gilles told me they can not be.
Also, does the alarm run at the priority of the thread that created it
or does it run at a priority higher than anything else?
Jan Kiszka wrote:
[ can be pulled from git.xenomai.org/xenomai-jki.git queues/assorted ]
Keep the result of rt_task_self() in a local variable to avoid the
second invocation.
Maybe we could create a pure/const variant of rt_task_self() for use in
task.c only which would avoid the double
Adam Bennett wrote:
On Wed, Apr 1, 2009 at 4:44 AM, Philippe Gerum r...@xenomai.org wrote:
On Tue, 2009-03-31 at 14:53 -0400, Adam Bennett wrote:
I'm running xenomai-head, linux-2.6.28.9, with uclibc-0.9.30.1.
I have to run configure with --build=i586-gentoo-linux-uclibc
--without-__thread.
Adam Bennett wrote:
On Wed, Apr 1, 2009 at 4:44 AM, Philippe Gerum r...@xenomai.org wrote:
On Tue, 2009-03-31 at 14:53 -0400, Adam Bennett wrote:
I'm running xenomai-head, linux-2.6.28.9, with uclibc-0.9.30.1.
I have to run configure with --build=i586-gentoo-linux-uclibc
--without-__thread.
Peter Wächtler wrote:
Hi Xenomai developers,
for automotive control units the boot time is essential. After power-up the
first status message has to be sent in about 50ms. This is usually achieved
by a RTOS with boot times far below.
Is it possible to construct a system with Xenomai
Peter Wächtler wrote:
As a side note, I have a question for the automotive industry people.
Would there be an interest in developing an OSEK skin for Xenomai? I
have been thinking about that for some time, but still have not found
time to start the job. I have read the OSEK spec, and found the
Peter Wächtler wrote:
Am Friday 27 March 2009 15:53:02 schrieb Gilles Chanteperdrix:
Xenomai kernel-space support is started somewhere in the middle of the
boot process, so, you can probably start kernel-space applications at
that time. User-space only works when init has been started, which
Peter Wächtler wrote:
Am Friday 27 March 2009 16:46:12 schrieb Gilles Chanteperdrix:
Peter Wächtler wrote:
As a side note, I have a question for the automotive industry people.
Would there be an interest in developing an OSEK skin for Xenomai? I
have been thinking about that for some time
Jan Kiszka wrote:
Do not return -EFAULT when the passed string has zero-length. Instead,
return -EINVAL when trying to create objects with empty names.
Ok. You can commit this.
--
Gilles.
___
Jan Kiszka wrote:
Obviously a conversion error while switching to __xn_safe*.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Well, I have just checked the kernel code, and 0 as a return value of
strncpy_from_user is treated as a value in most places, even if not -EFAULT.
--
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Obviously a conversion error while switching to __xn_safe*.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Well, I have just checked the kernel code, and 0 as a return value of
strncpy_from_user is treated as a value in most
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Obviously a conversion error while switching to __xn_safe*.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Well, I have just checked the kernel code, and 0 as a return value
Jan Kiszka wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Obviously a conversion error while switching to __xn_safe*.
Signed-off-by: Jan Kiszka jan.kis
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Meanwhile I played with some light-weight approach to relax a thread
that received a signal (according to do_sigwake_event). Worked, but only
once due
Steven Seeger wrote:
Gilles believes he's on the track of our FPU issue when using kernel
threads. Would using an RTDM timer to accomplish our need have the
same issue? We would not use the FPU in the timer of course, because
it is not allowed.
I just don't want to spend the time
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
the watchdog strikes. The second one brought me to another issue: Raise
SIGKILL for the current thread and make sure that it can be processed by
Linux (e.g. via xnpod_suspend_thread(cpu-hog). Unfortunately, there is
no way to force a
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Meanwhile I played with some light-weight approach to relax a thread
that received a signal (according to do_sigwake_event). Worked, but only
once due to a limitation (if not bug) of I-pipe x86: in
Jan Kiszka wrote:
Linux (e.g. via xnpod_suspend_thread(cpu-hog). Unfortunately, there is
no way to force a shadow thread into secondary mode to handle pending
Linux signals unless that thread issues a syscall once in a while. And
that raises the question if we shouldn't improve this as well
yi li wrote:
On Wed, Feb 25, 2009 at 6:23 PM, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
yi li wrote:
On Wed, Feb 25, 2009 at 12:30 AM, Philippe Gerum r...@xenomai.org wrote:
2. libpthread_rt.la should not depend on lpthread.
Nak. In flat mode, turning the link
yi li wrote:
On Thu, Feb 26, 2009 at 6:20 PM, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org wrote:
-lpthread does need to be set in libpthread_rt_la_LDFLAGS, if you look
at libpthread_rt code (which you apparently do not want to dot), you
will see that it uses libpthread functions
601 - 700 of 1571 matches
Mail list logo
