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 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 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 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 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 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 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 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 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 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 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 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 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
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
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]
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
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:
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-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 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
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
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
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
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 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
.
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 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
On Thu, 2007-08-30 at 09:11 +0200, Jan Kiszka wrote:
This introduces a round-up-variant of xntbase_ns2ticks. It is uninlined
for the non-trivial case due to its text size. Its only user will be
RTDM for now, but maybe the POSIX skin can use it as well.
Philippe, if you accept this one, I'll
On Thu, 2007-08-30 at 08:27 +0200, Jan Kiszka wrote:
I noticed some warning during a 2.4 build of trunk which may point out
unexpected side effects:
Merged, thanks.
In file included from pod.c:45:
/usr/src/linux-2.4.35.1/include/asm/xenomai/bits/pod.h:32:1: warning:
xnarch_tsc_to_ns
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
Here is the third candidate release for the v2.4.x branch. Most of the
work since -rc2 was aimed at optimizing the interrupt pipeline, and
first and foremost at reducing its cache footprints, initially for the
powerpc and x86 ports. Other archs will be upgraded next. The powerpc
arch also gains a
On Sun, 2007-09-16 at 19:49 +0200, Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Please try this patch against v2.3.x. A double free issue on a task TCB
already scheduled for memory release was causing all sorts of troubles,
basically trashing the system heap afterwards
On Mon, 2007-09-24 at 10:40 +0200, Benjamin ZORES wrote:
Hello Philippe (or any that can provide me with some infos),
I've seen you've commited a patch for Adeos on upcoming 2.6.23
based on DENX tree.
Can you tell me what are the main differences between the Adeos 1.7
and 2.0 series from
On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote:
...
And a third
one only gives me Detected illicit call from domain Xenomai before the
box reboots. :(
Grmff... Do you run with your
On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote:
...
And a third
one only gives me Detected illicit call from domain Xenomai before the
box reboots. :(
Grmff... Do you run with your
On Sun, 2007-09-30 at 17:31 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Sun, 2007-09-30 at 13:42 +0200, Jan Kiszka wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
On Sun, 2007-09-30 at 12:22 +0200, Jan Kiszka wrote:
...
And a third
one only gives me Detected illicit call from
On Thu, 2007-10-04 at 11:14 +0200, Jan Kiszka wrote:
Hi all,
after a really long search I'm now quite sure to have found the reason
for the lockups I'm seeing over 2.6.22-i386. I'm yet struggling to
understand why this issue is not visible over 2.6.19 and .20 for me, but
maybe it is just
On Thu, 2007-10-04 at 11:34 +0200, Philippe Gerum wrote:
Well, this trace also reveals a second bug that can cause nasty priority
inversion: a high-prio domains executes when a fasteoi-IRQ arrives for a
low-prio domain. This will now block all IRQs until the low-prio domain
was able
On Thu, 2007-10-04 at 14:42 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-10-04 at 11:34 +0200, Philippe Gerum wrote:
Well, this trace also reveals a second bug that can cause nasty priority
inversion: a high-prio domains executes when a fasteoi-IRQ arrives for a
low-prio
On Thu, 2007-10-04 at 16:06 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-10-04 at 14:42 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-10-04 at 11:34 +0200, Philippe Gerum wrote:
Well, this trace also reveals a second bug that can cause nasty priority
On Sun, 2007-10-07 at 18:40 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Sun, 2007-10-07 at 17:27 +0200, Jan Kiszka wrote:
This patch fixes another bug of I-pipe for 2.6.22:
Due to the introduction of a pgd page cache (quicklist) into that
kernel, __ipipe_pin_range_globally
On Sun, 2007-10-07 at 18:51 +0200, Philippe Gerum wrote:
On Sun, 2007-10-07 at 18:40 +0200, Jan Kiszka wrote:
I still have a problem with UP here, but this one is due to a
Xenomai
bug -- host timer is no more forwarded when the nucleus timer
starts.
Does disabling NOHZ HIRES get
On Mon, 2007-10-08 at 10:45 +0200, Gilles Chanteperdrix wrote:
Ooops. By reading all my mails, I would have avoided reinventing
this
wheel on my own. Your patch is almost what I posted yesterday to fix
the
vmalloc issue.
Looks like we no longer need the last hunk of it on recent
On Wed, 2007-10-10 at 08:12 +0200, Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Again, the priority should not be the issue. The issue is likely that a
pending or just being handled non-RT IRQ can stall some RT IRQ at
hardware level. That must not happen. I-pipe
On Wed, 2007-10-10 at 11:36 +0200, Gilles Chanteperdrix wrote:
On 10/10/07, Philippe Gerum [EMAIL PROTECTED] wrote:
On Wed, 2007-10-10 at 10:54 +0200, Gilles Chanteperdrix wrote:
On 10/10/07, Philippe Gerum [EMAIL PROTECTED] wrote:
On Wed, 2007-10-10 at 08:12 +0200, Jan Kiszka wrote
On Thu, 2007-10-11 at 18:35 +0200, ROSSIER Daniel wrote:
Hi everyone,
I'm taking over the original thread from Patrick concerning the port of
Xenomai on Xscale with Linux 2.6.20. Briefly summarized, the boot
process actually freezes after a while right after the nucleus has been
started.
On Thu, 2007-10-11 at 22:47 +0200, Jan Kiszka wrote:
This patch for SVN trunk fixes most of the current bugs around hardware
timer takeover and release from/to Linux. Tested and found working here
(including SMP):
- 2.6.22, APIC, highres=off, nohz=off
- 2.6.22, APIC, highres=on, nohz=on
-
On Fri, 2007-10-12 at 11:47 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2007-10-11 at 22:47 +0200, Jan Kiszka wrote:
This patch for SVN trunk fixes most of the current bugs around hardware
timer takeover and release from/to Linux. Tested and found working here
(including SMP
On Fri, 2007-10-12 at 15:19 +0200, Stelian Pop wrote:
On Fri, Oct 12, 2007 at 01:15:31PM +0200, Jan Kiszka wrote:
[EMAIL PROTECTED] cat /proc/ipipe/trace/max
/frozen holds the result. Also, a bit more post_trace_points may help to
see what goes on after that function is called.
Ah,
Hi Wolfgang,
On Thu, 2007-10-11 at 11:28 +0200, Wolfgang Grandegger wrote:
Hello,
attached is a patch for arch/powerpc for the DENX GIT tree
linux-2.6-denx version 2.6.23. It should replace the patch
adeos-ipipe-2.6.23-rc5-powerpc-DENX-2.0-01.patch. It just needed
adaption for the
On Fri, 2007-10-12 at 23:51 +0200, Stelian Pop wrote:
On Fri, Oct 12, 2007 at 10:22:45PM +0200, Stelian Pop wrote:
Or even go crazy and activate SMP again ?
Would have been too easy:
# modprobe xeno_native
Xenomai: native skin init failed, code -19.
The I-pipe likely told Xenomai
On Sat, 2007-10-13 at 18:12 +0200, Stelian Pop wrote:
On Sat, Oct 13, 2007 at 04:42:27PM +0200, Jan Kiszka wrote:
Where do you get ENODEV? On nucleus startup? Please provide
/proc/timer_list output of the working and non-working setups.
It turns out that I had the Linux NMI watchdog
Here is the fourth candidate release for the v2.4.x branch. With the
v2.3.x maintenance cycle soon coming to an end after nearly a year since
it has started, v2.4 is going to be our next stable branch for quite
some time, so I would suggest that you make sure it can run your
favourite board(s)
Our Blackfin port has just been upgraded to the latest 2.6.23. The other
good news is that we have now rebased this work over mainline kernels.
The I-pipe patch below is an all-in-one, supporting the bf533, bf537 and
bf561 dual core boards. Any Xenomai version from 2.3.2 and on can be
used
On Wed, 2007-10-17 at 18:40 +0200, Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
On 10/16/07, Jan Kiszka [EMAIL PROTECTED] wrote:
Hi,
aft
Any concerns about the (yet untested) attached patch?
Well... Thanks for working in my stead. I had a look a the posix
situation but could not
On Thu, 2007-10-18 at 22:46 +0200, Jan Kiszka wrote:
Hi Philippe,
what's the point about
if (xnsched_resched_p())
xnpod_schedule();
at the beginning of do_hisyscall_event() [1]? Could you provide a
comment for the background of this hunk? Or can we even remove it?
Jan Kiszka wrote:
Philippe Gerum wrote:
Our Blackfin port has just been upgraded to the latest 2.6.23. The other
good news is that we have now rebased this work over mainline kernels.
The I-pipe patch below is an all-in-one, supporting the bf533, bf537 and
bf561 dual core boards. Any Xenomai
Fillod Stephane wrote:
Hi,
As Philippe has been suggesting it, I've been testing v2.4-rc4 on x86
(not favourite board though :) with the RTAI skin (not my favourite skin
too).
Anyway, a legacy RTAI application which was fine with v2.3.2/2.6.20, is
now
freezing the box randomly in the
Fillod Stephane wrote:
Hi Gilles,
Thanks for the quick reply.
Gilles Chanteperdrix wrote:
A case of freeze is a system call called in a loop which fails without
its return value being checked.
I forget to say that the RTAI application is running in kernel land,
because
no port of the
Jeroen Van den Keybus wrote:
On my Linux 2.6.23 with latest I-pipe patch (1.10-10), interrupts are
dispatched twice if they are of the fasteoi type.
I have the impression that the I-pipe does the eoi() acknowledgement (in
kernel/irq/chip.c: __ipipe_ack_fasteoi_irq) without first masking off
Jeroen Van den Keybus wrote:
On my Linux 2.6.23 with latest I-pipe patch (1.10-10), interrupts are
dispatched twice if they are of the fasteoi type.
I have the impression that the I-pipe does the eoi() acknowledgement (in
kernel/irq/chip.c: __ipipe_ack_fasteoi_irq) without first masking off
Gilles Chanteperdrix wrote:
On 10/24/07, Philippe Gerum [EMAIL PROTECTED] wrote:
ROSSIER Daniel wrote:
Hi all,
I've found a bug in arch/arm/xenomai/switch.S which solved the problem
below. It actually comes from the iWMMXT (Intel Wireless MMX) coprocessor
which is an extension of the ARM
Steven A. Falco wrote:
I have built a 2.6.23-rc7 kernel (from Denx git) with Xenomai 2.4-rc3.
Architecture is powerpc, processor is a 405GP.
I had to make some additions to arch/powerpc/kernel/head_40x.S, and I
can submit a patch if someone tells me where to post it.
Here would be nice,
-powerpc-DENX-2.0-02.patch
You would still need the quick fix for the UIC on top of that one, though.
Steve
Philippe Gerum wrote:
Steven A. Falco wrote:
I have built a 2.6.23-rc7 kernel (from Denx git) with Xenomai 2.4-rc3.
Architecture is powerpc, processor is a 405GP.
I had
Steven A. Falco wrote:
I applied the uic patch:
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index eeb38e2..5a38086 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -48,7 +48,7 @@ struct uic {
int index;
int dcrbase;
-
Jan Kiszka wrote:
Philippe Gerum wrote:
Steven A. Falco wrote:
I applied the uic patch:
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index eeb38e2..5a38086 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -48,7 +48,7 @@ struct uic {
int
Steven A. Falco wrote:
I needed the following patch to fix a forward reference (caught by gcc
4.1.1). I posted this as part of an earlier discussion, but I then realized
that it might be overlooked, so I'm reposting it as a new thread:
Thanks. This one was caught a few days back and only
Philippe Gerum wrote:
Steven A. Falco wrote:
I needed the following patch to fix a forward reference (caught by gcc
4.1.1). I posted this as part of an earlier discussion, but I then realized
that it might be overlooked, so I'm reposting it as a new thread:
Thanks. This one was caught
Steven A. Falco wrote:
Thank you very much. I hate to make extra work for you - is there a git
repository for adeos-ipipe that I should be pulling from?
git://www.denx.de/git/ipipe-2.6
Steve
Philippe Gerum wrote:
Philippe Gerum wrote:
Steven A. Falco wrote:
I needed
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Steven A. Falco wrote:
I applied the uic patch:
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index eeb38e2..5a38086 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
801 - 900 of 1458 matches
Mail list logo
