On Tue, 2007-09-04 at 15:12 +0200, Johan Borkhuis wrote:
I made the following change to Xenomai (version 2.3.2, but it could also
be applied to 2.4 as the watchdog code has not been changed).
Merged, with forward port to 2.4. Thanks.
The watchdog timeout is fixed at 4 seconds. For us this
On Wed, 2007-09-05 at 11:15 +0200, Ravid Baruch Naali wrote:
Moving to a new thread subject.
The following thread will be dedicated to development of the Automated
performance testing and it's presentation.
At first stage an infrastructure will be design and created. later on
the
.
Please, somebody implement this, damnit! Or I'm going to rewrite the
entire Xenomai stack in Bourne shell with Java applets for speedups, so
you could not complain about bad latencies and unwanted overhead
anymore.
Thank you,
Philippe Gerum wrote:
On Mon, 2007-09-03 at 17:05 +0300, Ravid
On Tue, 2007-09-04 at 15:12 +0200, Johan Borkhuis wrote:
I made the following change to Xenomai (version 2.3.2, but it could also
be applied to 2.4 as the watchdog code has not been changed).
The watchdog timeout is fixed at 4 seconds. For us this is a problem as
there are some processes
On Tue, 2007-09-04 at 10:50 +0200, Gilles Chanteperdrix wrote:
On 9/3/07, Ravid Baruch Naali [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On 9/3/07, Ravid Baruch Naali [EMAIL PROTECTED] wrote:
Hello again,
Hi,
I'm not sure what is the preferred way to commit
On Mon, 2007-09-03 at 14:11 +0200, ROSSIER Daniel wrote:
Hello,
I'm doing a small RT application using the I2C driver from Linux.
At a certain time, when the task is activated and data are written to
the I2C bus,
the driver waits for a IRQ that confirmed the data have been sent
On Mon, 2007-09-03 at 17:32 +0200, Gilles Chanteperdrix wrote:
On 9/3/07, Ravid Baruch Naali [EMAIL PROTECTED] wrote:
Hello again,
Hi,
I'm not sure what is the preferred way to commit my changes, so before I
commit i'm Attaching my patch in order to get you remarks and further
On Wed, 2007-08-29 at 17:28 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Wed, 2007-08-29 at 16:32 +0200, Jan Kiszka wrote:
Markus Osterried (BA/EDD) wrote:
Hi,
it seems that in the RTDM API, all the timeout functions which use
nanosecs_rel_t have a strange behaviour
On Wed, 2007-08-29 at 16:32 +0200, Jan Kiszka wrote:
Markus Osterried (BA/EDD) wrote:
Hi,
it seems that in the RTDM API, all the timeout functions which use
nanosecs_rel_t have a strange behaviour.
The timeout in nanoseconds is converted to ticks and the number of ticks
is rounded
Here is the second candidate release for the v2.4.x branch. Short log
follows:
[nucleus]
* Fix shared interrupt support.
* Fix RPI-disabled build.
* IPI annotation in /proc/xenomai/irq.
[native]
* Add task exectime, context and mode switches as
Benjamin,
On Tue, 2007-08-07 at 14:03 +0200, Benjamin ZORES wrote:
Benjamin ZORES wrote:
Benjamin ZORES wrote:
Hi,
I've seen that Adeos has been officially ported to PowerPC architecture.
Please find an update of the adeos-ipipe-2.6.20-powerpc-1.6-02 to
Linux 2.6.21 (.5) kernel, in
On Fri, 2007-08-10 at 13:46 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
this appears to be related to 2.6.22+ only:
[ cut here ]
kernel BUG at fs/buffer.c:1230!
invalid opcode: [#1]
PREEMPT
Modules linked in: xeno_rtdm xeno_nucleus
On Fri, 2007-08-10 at 20:06 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Fri, 2007-08-10 at 13:46 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
this appears to be related to 2.6.22+ only:
[ cut here ]
kernel BUG at fs/buffer.c:1230
On Tue, 2007-08-07 at 17:09 +0200, Gilles Chanteperdrix wrote:
On 8/7/07, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
The fact that you are in a hurry should not be an excuse to propose a
fix which is much worse than the bug itself.
Please explain.
Using
On Wed, 2007-08-01 at 11:26 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Wed, 2007-08-01 at 11:10 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:56 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:47 +0200, Philippe Gerum wrote
On Wed, 2007-08-01 at 11:10 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:56 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:47 +0200, Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:31 +0200, Jan Kiszka wrote:
Philippe Gerum wrote
On Tue, 2007-07-31 at 18:31 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:11 +0200, Jan Kiszka wrote:
Already a plain command sequence causes this problem:
# modprobe xeno_nucleus
# rmmod xeno_nucleus
rmmod: xeno_nucleus: Resource temporarily unavailable
On Tue, 2007-07-31 at 18:47 +0200, Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:31 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:11 +0200, Jan Kiszka wrote:
Already a plain command sequence causes this problem:
# modprobe xeno_nucleus
# rmmod
On Tue, 2007-07-31 at 18:56 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:47 +0200, Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:31 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2007-07-31 at 18:11 +0200, Jan Kiszka wrote:
Already a plain command
On Tue, 2007-07-31 at 20:05 +0200, Jan Kiszka wrote:
Oh my dear. The ground may open and swallow me. This crappy piece of
optimisation in xnintr_edge_shirq_handler() I introduced both to 2.4 and
(sadly) the 2.3.x stable series cannot work. It must stay as it used to:
--- ksrc/nucleus/intr.c
On Tue, 2007-07-31 at 20:17 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Oh my dear. The ground may open and swallow me. This crappy piece of
optimisation in xnintr_edge_shirq_handler() I introduced both to 2.4 and
(sadly) the 2.3.x stable series cannot work. It must stay as it used to:
Here is the first candidate release for the v2.4.x branch, on the road
to 2.4 final. The following short log only lists the most significant
evolutions; a slew of optimizations, cleanups and bug fixes all over the
place come with this release as well:
[nucleus]
* Introduction
Merged, thanks.
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Here is the latest maintenance release for the v2.3.x branch. Short
log follows:
[nucleus]
* Fix deadlock and migration issues in RPI support.
* Sanitize deletion path of shadow threads.
[powerpc]
* Upgrade to kernel 2.6.20, powerpc/ tree.
[arm]
to reproduce it first. Thanks for this.
Regards
Mathias
Hi Philippe,
I have attached this patch to my application. So far it looks really good.
However, I leave my test running to be sure that it works.
Regards
Mathias
On Fri, 2007-07-20 at 14:16 +0200, Philippe Gerum
On Wed, 2007-07-25 at 13:40 +0200, Jan Kiszka wrote:
Philippe Gerum schrieb:
On Fri, 2007-07-20 at 14:16 +0200, Philippe Gerum wrote:
Now, regarding the deadlock issue, suppressing the RPI-specific locking
entirely would have been the best solution, but unfortunately, the
migration
On Mon, 2007-07-23 at 19:15 +0200, Philippe Gerum wrote:
On Mon, 2007-07-23 at 17:01 +0200, Philippe Gerum wrote:
On Fri, 2007-07-20 at 14:16 +0200, Philippe Gerum wrote:
On Fri, 2007-07-20 at 13:54 +0200, M. Koehrer wrote:
Hi Philippe,
I left my test running for a couple of hours
On Fri, 2007-07-20 at 14:16 +0200, Philippe Gerum wrote:
On Fri, 2007-07-20 at 13:54 +0200, M. Koehrer wrote:
Hi Philippe,
I left my test running for a couple of hours - no freeze so far...
However, I have to do some other stuff on this machine, I have to stop the
test now
On Mon, 2007-07-23 at 17:01 +0200, Philippe Gerum wrote:
On Fri, 2007-07-20 at 14:16 +0200, Philippe Gerum wrote:
On Fri, 2007-07-20 at 13:54 +0200, M. Koehrer wrote:
Hi Philippe,
I left my test running for a couple of hours - no freeze so far...
However, I have to do some other
On Mon, 2007-07-23 at 10:45 -0700, Jeff Koftinoff wrote:
Hi!
We are trying to compile xenomai for x86_64. Yesterday, revision
r2773 Add Adeos 2.6.22/x86_64, added the file adeos-ipie-2.6.22-
x86_64-1.1-00.patch.
However it appears that the patch is only patching files in arch/
i386/
On Fri, 2007-07-20 at 16:20 +0200, Jan Kiszka wrote:
OK, let's go through this another time, this time under the motto get
the locking right. As a start (and a help for myself), here comes an
overview of the scheme the final version may expose - as long as there
are separate locks:
On Thu, 2007-07-19 at 19:57 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
Ok, the rpilock is local, the nesting level is bearable, let's focus on
putting this thingy straight.
Sorry, I missed this one, which in fact explains that you were referring
to Xenomai PI and not PREEMPT_RT PI
On Fri, 2007-07-20 at 13:54 +0200, M. Koehrer wrote:
Hi Philippe,
I left my test running for a couple of hours - no freeze so far...
However, I have to do some other stuff on this machine, I have to stop the
test now...
Ok, thanks for the feedback. I will send an
On Fri, 2007-07-20 at 16:20 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
...
Read my mail, without listening to your own grumble at the same time,
you should see that this is not a matter of being right or wrong, it is
a matter of who needs what, and how one will use Xenomai. Your
On Thu, 2007-07-19 at 09:22 +0200, Jan Kiszka wrote:
Philippe,
this bug was introduced with recent clock_event modifications:
--- ksrc/nucleus/timer.c (Revision 2766)
+++ ksrc/nucleus/timer.c (Arbeitskopie)
@@ -245,7 +245,7 @@ void xntimer_tick_aperiodic(void)
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
doing a potential context switch. Was this checked to be save
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie.
doing a potential context switch. Was this checked to be save
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue could be
that we hold that lock while calling into xnpod_renice_root [1], ie
On Thu, 2007-07-19 at 19:18 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 17:35 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
And when looking at the holders of rpilock, I think one issue
Mathias,
Could you try applying the attached patch against v2.3.2, and run your
box using the failing configuration. This patch is a _preliminary_
attempt at fixing two major issues, it is not complete, and may not even
be fully correct since it does not address all the pending issues yet.
On Tue, 2007-07-17 at 21:30 +0200, Gilles Chanteperdrix wrote:
Hi,
when xnarch_program_next_timer_shot is passed a null delay and there is
no other timed event pending, the mvm terminates with the message:
nothing to schedule.
Actually, this is a purely event-driven engine, so if we
On Wed, 2007-07-18 at 10:03 +0200, Gilles Chanteperdrix wrote:
On 7/18/07, Philippe Gerum [EMAIL PROTECTED] wrote:
On Tue, 2007-07-17 at 21:30 +0200, Gilles Chanteperdrix wrote:
The attached patch fixes this, though I am not sure it is the best way
to fix it.
Looks good. The only
On Mon, 2007-07-09 at 16:45 +0200, Wolfgang Grandegger wrote:
Hello,
the attached patch changes:
2007-07-09 Wolfgang Grandegger [EMAIL PROTECTED]
* include/asm-generic/wrappers.h: add __deprecated for Linux 2.4.
Merged, thanks.
Wolfgang.
On Mon, 2007-07-09 at 16:50 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 16:45 +0200, Wolfgang Grandegger wrote:
Hello,
the attached patch changes:
2007-07-09 Wolfgang Grandegger [EMAIL PROTECTED]
* include/asm-generic/wrappers.h: add __deprecated
On Mon, 2007-07-09 at 17:02 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 16:50 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 16:45 +0200, Wolfgang Grandegger wrote:
Hello,
the attached patch changes:
2007-07-09 Wolfgang Grandegger
On Mon, 2007-07-09 at 17:14 +0200, Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 16:45 +0200, Wolfgang Grandegger wrote:
Hello,
the attached patch changes:
2007-07-09 Wolfgang Grandegger [EMAIL PROTECTED
On Mon, 2007-07-09 at 17:32 +0200, Wolfgang Grandegger wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 17:02 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 16:50 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 16:45 +0200, Wolfgang
Here is the latest maintenance release for the v2.3.x branch. Short
log follows:
[nucleus]
* Always defer release of TCB memory.
* Sanitize support for machine-dependent arithmetics.
* Fix root priority boosting with XENO_OPT_SCALABLE_SCHED.
* Fix
On Wed, 2007-07-04 at 10:37 +0200, Dmitry Adamushko wrote:
On 03/07/07, Jan Kiszka [EMAIL PROTECTED] wrote:
Modified version just went online, see
http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/fix-intr-locking-part-ii-v3.patch
Should be ok now, I think.
Please, add your
On Sat, 2007-06-30 at 09:48 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
Our development trunk now contains the necessary support for running
Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
the generic clock event device abstraction that comes with newest
On Sat, 2007-06-30 at 09:48 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
Our development trunk now contains the necessary support for running
Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
the generic clock event device abstraction that comes with newest
On Sat, 2007-06-30 at 09:48 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
Our development trunk now contains the necessary support for running
Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
the generic clock event device abstraction that comes with newest
On Sat, 2007-06-30 at 13:02 +0200, Philippe Gerum wrote:
On Sat, 2007-06-30 at 09:48 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
Our development trunk now contains the necessary support for running
Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
the generic
On Fri, 2007-06-29 at 17:29 +0200, Daniel Simon wrote:
On Fri, 29 Jun 2007 17:00:39 +0200
Jan Kiszka [EMAIL PROTECTED] wrote:
Exectime is only updated on task switches. So you are not obtaining the true
value when requesting your own data. Use the same formula for both cases.
yes, but
On Thu, 2007-06-28 at 19:06 +0200, Jan Kiszka wrote:
Hi,
here is an overview of my latest patch stack at
http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/
fix-timer-wrap-arounds-v2.patch
---
More or less academic fixes (hopefully without
On Tue, 2007-06-26 at 15:39 +0200, Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
IMO, the only advantage of having absolute timers is to be able to apply
the posix scheme. So, if I followed correctly your discussion, what we
need is:
- an XNTBISOL flag with a service xntbase_isol which
On Mon, 2007-06-25 at 08:12 +0200, Jan Kiszka wrote:
Ok, I think it's time to summarise some results of this thread:
- xntimers will be of three kinds: real-time absolute, monotonic
absolute, and monotonic relative ones (ie. all POSIX). I'm currently
in favour of passing this property
On Sun, 2007-06-24 at 10:43 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Sat, 2007-06-23 at 13:39 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Sat, 2007-06-23 at 10:08 +0200, Jan Kiszka wrote:
Hi,
[just to save this early-Saturday-morning insight]
I think the xntimer
On Sat, 2007-06-23 at 10:08 +0200, Jan Kiszka wrote:
Hi,
[just to save this early-Saturday-morning insight]
I think the xntimer interface is not yet ready to represent all required
scenarios. What kind of timers are there? Let's start with POSIX:
1. Realtime timers- use realtime
On Sat, 2007-06-23 at 13:39 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Sat, 2007-06-23 at 10:08 +0200, Jan Kiszka wrote:
Hi,
[just to save this early-Saturday-morning insight]
I think the xntimer interface is not yet ready to represent all required
scenarios. What kind
On Thu, 2007-06-21 at 09:58 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Wed, 2007-06-20 at 19:08 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-06-18 at 10:27 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
...
The answer I found is to synchronise all time bases
On Thu, 2007-06-21 at 11:06 +0200, Philippe Gerum wrote:
users is too vague a term. If we are talking about application
developers, they should feel deep in their guts that using something
within the xnarch layer is terminally wrong, so the point is moot
anyway.
Who I'm talking about
On Thu, 2007-06-21 at 11:21 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-06-21 at 09:58 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
If you think of it, decoupling only requires to keep a constant epoch
(at least one the nucleus does not update) somewhere within
On Thu, 2007-06-21 at 13:20 +0200, Wolfgang Grandegger wrote:
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
can we just switch over to pci_register_driver in order to avoid
deprecated (and soon removed) pci_module_init? Or do we also need some
wrapper for older 2.4 kernels (latest 2.4 is
On Thu, 2007-06-21 at 13:05 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Well, and I wonder what this xnarch_memory_barrier() at each handler
entry is for. Seems to be there for ages, don't see why right now.
AFAICT, this probably dates back to Xenomai 1.x, when we used to have a
threaded
On Mon, 2007-06-18 at 10:27 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
...
The answer I found is to synchronise all time bases as good as possible.
That means if one base changes its wall clock offset, all others need to
be adjusted as well. At this chance, we would also implement
On Mon, 2007-06-18 at 10:03 +0200, Benjamin ZORES wrote:
Philippe Gerum wrote:
FWIW, I've almost finished an I-pipe port over 2.6.21 also using the
arch/powerpc tree. It relies on the genirq layer which makes things way
more comfortable, and which does not require to redefine particular ack
On Tue, 2007-06-12 at 19:59 +0200, Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
On Tue, 2007-06-12 at 08:42 +0200, M. Koehrer wrote:
Hi everybody,
I want to know why the --enable-smp option for configure of Xenomai is
used when
On Fri, 2007-06-08 at 16:07 +0200, BOUIN Alexandre wrote:
We (Adeneo) are working on a ARM AT91 RTAI. We
encountered some difficulties such tsc one : in
periodic mode, we reload our timer automatically in
order to avoid
On Mon, 2007-05-28 at 13:31 +0200, Jan Kiszka wrote:
Instead of posting yet another stream of individual patches from my
queue, I decided to put them all into a series and upload them. See
http://www.rts.uni-hannover.de/rtaddon/patches
for my latest I-pipe, Xenomai, and LTTng
On Thu, 2007-05-31 at 22:39 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-05-28 at 13:31 +0200, Jan Kiszka wrote:
Instead of posting yet another stream of individual patches from my
queue, I decided to put them all into a series and upload them. See
http://www.rts.uni
On Thu, 2007-05-31 at 22:39 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-05-28 at 13:31 +0200, Jan Kiszka wrote:
Instead of posting yet another stream of individual patches from my
queue, I decided to put them all into a series and upload them. See
http://www.rts.uni
On Fri, 2007-05-25 at 17:32 +0200, Jan Kiszka wrote:
Daniel Schnell wrote:
Well, that may be related to the bug I am seeing when I am ending
cyclictest with Ctrl-C, Recursive kernel Ooops and this is on plain 2.3.1
2.3.1 is definitely affected by this bug as well, as it also gained the
On Fri, 2007-05-25 at 15:55 +0200, Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
People, we have some new troubles:
I'm reproducibly getting recursive faults on termination of cyclictest
via ^C. It's all standard here: ipipe 1.8-02, Xenomai trunk #2469, no
weird
On Thu, 2007-05-24 at 11:43 +0200, Jan Kiszka wrote:
You don't want to run rpi_pop() after the bulk of xnpod_delete_thread()
Not after, I meant before. But then...
has run for the same thread, and you don't want a preemption to occur
anytime between the thread deletion and the update of
On Mon, 2007-05-21 at 16:43 +0200, Jan Kiszka wrote:
Hi Philippe,
Jan Kiszka wrote:
Just ran into this with CONFIG_IPIPE_DEBUG_CONTEXT (maybe due to some
bug of my own):
Here is some code to trigger the issue reliably:
Ok, deletion over primary domain, that's why it triggers, since
On Mon, 2007-05-21 at 18:21 +0200, Jan Kiszka wrote:
This code has to work with an awful lot of runtime situations, including
those raised by ptracing/GDB, and thread signaling in general, so test
harnessing is key here.
Well, what about listing those scenarios and their requirements
On Sun, 2007-05-20 at 13:28 +0200, Jan Kiszka wrote:
The timer IRQ currently goes through a dedicated trampoline
(xnintr_clock_handler), the generic xnintr_irq_handler which handles it
via a special nkclock xnintr_t object, then xnpod_announce_tick, until
it finally ends in
On Wed, 2007-05-16 at 20:07 +0200, Fillod Stephane wrote:
Philippe Gerum wrote:
The other issue is an old bug of mine for this port, specifically we
need to call irq_enter()/irq_exit() for virtual interrupts too;
otherwise, softirqs triggered by virtual ones might be delayed until
the
next
On Mon, 2007-05-14 at 09:50 +0200, Benjamin Zores wrote:
Hello,
A few time ago, I've sent a first draft of a patch that aimed at porting
Adeos Ipipe from PPC to PowerPC kernel architecture.
While being ported, the patch had problems running on due to some
incompabilities with the IRQ
On Mon, 2007-05-14 at 13:12 +0200, Benjamin Zores wrote:
Philippe Gerum wrote:
FWIW, I've almost finished an I-pipe port over 2.6.21 also using the
arch/powerpc tree. It relies on the genirq layer which makes things way
more comfortable, and which does not require to redefine particular ack
On Wed, 2007-05-09 at 09:07 +0200, Markus Osterried wrote:
Hello Gerum,
sorry for not knowing the details. But there is another question.
Is it okay to move the pointer to the arguments to the newly created task?
Isn't it possible that the task which created the new task is rescheduled?
The
problem though.
Markus
Philippe Gerum
On Tue, 2007-05-08 at 16:07 +0200, Markus Osterried wrote:
Hello Phillipe,
in __t_start() in /ksrc/skins/psos+/syscall.c the pointer to the
(user-space) tasks argument is directly used for the (kernel-space)
t_start() call.
u_long *argp;
argp = (u_long *)__xn_reg_arg4(regs);
return
On Thu, 2007-04-26 at 20:39 +0200, Jan Kiszka wrote:
5. Extract minimal, dependency-free linux/ipipe_base.h from main
ipipe.h
6. Optimise __ipipe_stall_root, __ipipe_test_root, and
__ipipe_test_and_stall_root for execution on UP (only i386 and
x86_64 so far). This should
On Thu, 2007-04-26 at 20:39 +0200, Jan Kiszka wrote:
5. Extract minimal, dependency-free linux/ipipe_base.h from main
ipipe.h
6. Optimise __ipipe_stall_root, __ipipe_test_root, and
__ipipe_test_and_stall_root for execution on UP (only i386 and
x86_64 so far). This should
On Wed, 2007-05-02 at 11:15 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-04-26 at 20:39 +0200, Jan Kiszka wrote:
5. Extract minimal, dependency-free linux/ipipe_base.h from main
ipipe.h
6. Optimise __ipipe_stall_root, __ipipe_test_root
On Thu, 2007-04-26 at 20:39 +0200, Jan Kiszka wrote:
Hi,
before ipipe-git gets busy again with work on 2.6.21, I'd like to flush
my patch queue. Here is an overview:
1. Build fix for the tracer over x86_64
2. Fix for Linux IRQ state during x86_64 boot
3. [JANITOR] Fix whitespace
direction.
+ * include/nucleus/system.h: Remove unused (and bogus) ffnz wrapper.
+
Merged, thanks.
2007-04-19 Philippe Gerum [EMAIL PROTECTED]
* ksrc/skins/vrtx/module.c, ksrc/nucleus/pipe.c,
Index: xenomai/include/nucleus/system.h
/ChangeLog
+++ xenomai/ChangeLog
@@ -5,6 +5,8 @@
* include/nucleus/system.h: Remove unused (and bogus) ffnz wrapper.
+ * include/asm-sim/system.h: Fix ffnz for 64-bit hosts.
+
2007-04-19 Philippe Gerum [EMAIL PROTECTED]
* ksrc/skins/vrtx/module.c, ksrc/nucleus/pipe.c
On Mon, 2007-04-23 at 14:48 +0200, Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
On Mon, 2007-04-23 at 11:35 +0200, Jan Kiszka wrote:
BTW, with latest SVN trunk and scalable sched, the oopses are gone
but
latency still
On Thu, 2007-04-19 at 18:09 +0200, Krause, Karl-Heinz wrote:
Yes, it contains the full AD RT Kernel.
There seems to be lot of work there. I had a look at this patch, and
basically, it looks like an effort to create an integrated POSIX
co-kernel that does not look like a co-kernel anymore, while
On Wed, 2007-04-18 at 20:13 +0200, Jan Kiszka wrote:
Hi Philippe,
here is an explanation of the scalable scheduler issue I face on x86_64
under different gcc compilers:
unsigned long x = 0;
int n = 32;
x |= 1 n;
The last instruction translates to:
On Wed, 2007-04-18 at 21:59 +0200, Gilles Chanteperdrix wrote:
Richard Cochran wrote:
Here is the corrected patch, based on Gilles' comments.
I hope sending this as an attachment is ok. I am a former Mutt user,
now forced to use **tl**k, and I can never tell when this program
On Tue, 2007-04-10 at 12:53 +0200, Sebastian Smolorz wrote:
Hello Philippe,
on page 21 of Native-API-Tour-rev-C.pdf one gets the impression that
rt_intr_wait() returns 0 on success. However, it returns a positive value in
this case (as the API description states it right).
Ok, will fix.
On Sat, 2007-04-07 at 12:50 +0200, Jan Kiszka wrote:
Not beautiful, but required.
Thanks. r2363 uses a slightly different approach in order to reduce the
#ifdef noise in the same move.
For a bean-counting approach, we could also make xeno_resource_holder
elements conditional.
--
On Tue, 2007-04-03 at 17:36 +0200, Philippe Gerum wrote:
On Mon, 2007-04-02 at 08:56 +0200, Sebastian Smolorz wrote:
Hi,
is there a problem with the Xenomai website or did I try to access it in
the
middle of an update cycle of mediawiki?
We have a recurring problem since
On Wed, 2007-04-04 at 23:34 +0100, Paul wrote:
Hi Philippe
Just tried to compile from r2361 in trunk, but `make dist` is failing due to
include/native/ppd.h not present - Perusing the change logs, I see ppd.h was
included in several native sources in r2361.. Should the reference be to
On Mon, 2007-04-02 at 08:56 +0200, Sebastian Smolorz wrote:
Hi,
is there a problem with the Xenomai website or did I try to access it in the
middle of an update cycle of mediawiki?
We have a recurring problem since yesterday likely due to an Apache
configuration change. This issue is
On Mon, 2007-03-05 at 13:44 +0100, Stephan Zimmermann wrote:
Jan Kiszka schrieb:
That happens when you overload your box with the test so that Linux does
not totally starve, just a bit too much so that it thinks it ran into a
soft-lockup. I've seen this here as well.
OK, you are right.
601 - 700 of 1458 matches
Mail list logo
