Wolfgang Grandegger wrote:
Hello,
recent versions of Xenomai include the header file linux/uaccess.h in
xenomai/include/asm-generic/syscall.h which does not exist under Linux
2.4. asm/uaccess should be used instead. Any clever idea how to fix it
(without using #ifdefs)?
Actually, we should
Fillod Stephane wrote:
Philippe Gerum wrote:
Fillod Stephane wrote:
Attached is an obvious patch (to me). Part of it is across I-Pipe.
Is there a reason why the counter was declared signed?
Well, because the number of faults was not expected to increase
indefinitely... Is it the PF count we
Here is the first maintenance release for the v2.4.x branch. Short
log follows:
[nucleus]
* Close SMP race window in message pipe's read-side.
* Prevent the task startup completion code to hold the nucleus
lock.
[psos]
* Fix t_mode().
Jan Kiszka wrote:
Index: xenomai/scripts/prepare-kernel.sh
===
--- xenomai/scripts/prepare-kernel.sh (Revision 3329)
+++ xenomai/scripts/prepare-kernel.sh (Arbeitskopie)
@@ -428,9 +428,9 @@
patch_append init/Kconfig
Jan Kiszka wrote:
Index: xenomai/scripts/prepare-kernel.sh
===
--- xenomai/scripts/prepare-kernel.sh (Revision 3329)
+++ xenomai/scripts/prepare-kernel.sh (Arbeitskopie)
@@ -428,9 +428,9 @@
patch_append init/Kconfig
Fillod Stephane wrote:
Dear Xeonmai/I-Pipe maintainers,
Attached is an obvious patch (to me). Part of it is across I-Pipe.
Is there a reason why the counter was declared signed?
Well, because the number of faults was not expected to increase
indefinitely... Is it the PF count we are
Jan Kiszka wrote:
As LOCAL_TIMER_VECTOR != RTHAL_APIC_TIMER_VECTOR (Philippe, what was the
motivation for this?),
In some cases, it's much saner to have two separate timer hw interrupt
sources, so that we may trigger a timer tick targeted at the Linux
kernel only from whatever domain, while
Niklaus Giger wrote:
Hi
Thanks everybody for helping to clean up the errors! I have a lot more
successful build now than three days ago.
As soon as I have some more time to spend on the buildbot. I will try
to cleanup the remaining failures which are probably more problems with
the
Paul wrote:
Hi Niklaus
On Sunday 23 December 2007 16:47, Niklaus Giger wrote:
/home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c: In
function 'lbmStartIO':
/home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2165:
error: too many arguments to function
Jan Kiszka wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe,
you recently said there is a bug in the x86_64 support when syscall
tracing is enabled. Now I think I stepped on it as well: In order to
validate my APIC
Niklaus Giger wrote:
In
http://ngiger.dyndns.org/buildbot/builders/tqm_f/builds/1/steps/mk_kernel/logs/stdio
you find the following errors:
In file included from
/home/buildbot/slave/tqm_f/linux/include/linux/unistd.h:9, from
init/do_mounts.c:5:
Wolfgang Grandegger wrote:
Wolfgang Grandegger wrote:
Thomas Wiedemann wrote:
Hi,
we had a problem compiling the CAN-Driver for the last release candidate
when
shared interrupts had been enabled, because of the re-named option
CONFIG_XENO_OPT_SHIRQ_LEVEL.. After a quick look, version
Here is the latest release from the v2.3.x branch. Short log follows:
[nucleus]
* Fix broken select() on a message pipe.
* Fix computation of overhead due to heap meta-data.
* Properly recycle empty bucketed pages to the free list.
* Sanitize heap size
Here is Xenomai v2.4.0. We are damn late on this one, so I'm going to
enter terse mode to save time: in short, this stable milestone aims at
more flexibility, increased portability, and lesser latency. This
serves the ultimate goal of making Xenomai the platform of choice for
migrating
Paul wrote:
Attached, trivial patch for native rt_mutex_acquire function documentation.
The reference to deprecated (and undocumented) rt_mutex_lock()
rt_mutex_release() is a little confusing.
Also updated the code snippets to match.
Merged, thanks.
--
Philippe.
Peter Schueller wrote:
Hi!
I am currently trying to port IPIPE to a new architecture and have the
following symptoms with my
first testcase:
- I am using a 2.6.23 Kernel and mainly looked at blackfin and i386 when
porting.
- I create a domain with priority IPIPE_ROOT_PRIO+100 in a
Here is the seventh candidate release for the v2.4.x branch. This
should be the last one before 2.4.0.
[nucleus]
* Clear wchan when failing to suspend a thread due to
preposterous timeout value.
* Report configured timer and clock device.
* Recycle
Jan Kiszka wrote:
OK, attached is an attempt to follow your arguments, while also keeping
topics separate which have different backgrounds (ie. clarify the
messages). As we go for reporting user faults now, lets include those
(unlikely and really buggy) cases over user mode as well.
I guess
Leopold Palomo-Avellaneda wrote:
A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
Here is the sixth candidate release for the v2.4.x branch.
[]
[i386, x86_64 = x86]
* Merge i386 and x86_64 arch-dep support as x86.
* Update Adeos/i386 support for 2.6.20, 2.6.22
Paul wrote:
On Wednesday 14 November 2007 09:56, Leopold Palomo-Avellaneda wrote:
A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
Here is the sixth candidate release for the v2.4.x branch.
[]
[i386, x86_64 = x86]
* Merge i386 and x86_64 arch-dep support as x86
Paul wrote:
On Wednesday 14 November 2007 09:56, Leopold Palomo-Avellaneda wrote:
A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
Here is the sixth candidate release for the v2.4.x branch.
[]
[i386, x86_64 = x86]
* Merge i386 and x86_64 arch-dep support as x86
Leopold Palomo-Avellaneda wrote:
A Dimecres 14 Novembre 2007, Philippe Gerum va escriure:
Leopold Palomo-Avellaneda wrote:
A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
Here is the sixth candidate release for the v2.4.x branch.
[]
[i386, x86_64 = x86]
* Merge i386
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Well, this is practically your original version. I still don't see why
we want debug code in production setups (WARN_ON, e.g., doesn't work
this way either),
Do you actually leave
Gilles Chanteperdrix wrote:
On Nov 13, 2007 3:17 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Hi,
I am chasing a slab corruption bug which happens on a Xenomai+RTnet
enabled box under heavy non real-time network load (which passes
through rtnet and rtmac_vnic to Linux
Here is the sixth candidate release for the v2.4.x branch.
[nucleus]
* LTT support overhaul.
* Fix select() breakage with message pipes.
* Return EOF condition to the real-time side when the Linux
peer closes the message pipe.
[i386, x86_64 =
Gilles Chanteperdrix wrote:
On Nov 13, 2007 6:10 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Nov 13, 2007 3:17 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Hi,
I am chasing a slab corruption bug which happens on a Xenomai+RTnet
enabled
Gilles Chanteperdrix wrote:
On Nov 13, 2007 6:44 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Nov 13, 2007 6:10 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Nov 13, 2007 3:17 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
On Nov 13, 2007 6:10 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Nov 13, 2007 3:17 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Hi,
I am chasing a slab corruption bug which happens
Philippe Gerum wrote:
Steven A. Falco wrote:
Solved. As you pointed out, Xenomai inverts the returned value from
request_region. So, that was a bug in my application.
However, turns out that instead of request_region, I have to use
request_mem_region. This is because the I/O region only
Jan Kiszka wrote:
Philippe,
you recently said there is a bug in the x86_64 support when syscall
tracing is enabled. Now I think I stepped on it as well: In order to
validate my APIC frequency patches for that arch, I wanted to use LTTng
there. But as soon as I start the trace, the latency
Steven A. Falco wrote:
Solved. As you pointed out, Xenomai inverts the returned value from
request_region. So, that was a bug in my application.
However, turns out that instead of request_region, I have to use
request_mem_region. This is because the I/O region only goes up to
2^32, but
Philippe Gerum wrote:
Steven A. Falco wrote:
The rt_misc_get_io_region() has the start argument as an unsigned
long. On the PPC440, we have a 36-bit address space, where the I/O
registers are generally above the 4GB area. For example, the UART is at
address 0x1ef600300.
The Linux
Jan Kiszka wrote:
Well, this is practically your original version. I still don't see why
we want debug code in production setups (WARN_ON, e.g., doesn't work
this way either),
Do you actually leave CONFIG_IPIPE_DEBUG on in production setups?
and I still don't understand why you want to
sema4s, mutexes,
queues, and so on, but not I/O regions. Consider this as an illustration
of our absolute laziness, since we do have the proper infrastructure to
handle I/O regions in the auto-cleanup process too.
Steve
Philippe Gerum wrote:
Philippe Gerum wrote:
Steven A. Falco wrote
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Well, this is practically your original version. I still don't see why
we want debug code in production setups (WARN_ON, e.g., doesn't work
this way either),
Do you actually leave CONFIG_IPIPE_DEBUG on in production setups
Jan Kiszka wrote:
Markus Osterried wrote:
Sorry for being intrusive.
I've already done a quick and dirty bug fix, so final bug fix is not
urgent.
Just wanted to know about time schedule.
At least 2.4 is near, but I guess another 2.3 release will follow as
well (due to recently accumulated
Jan Kiszka wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
This patch addresses the recently discovered issue that I-pipe actually
need to deal with faults over non-root domain in which the current
domain shows no interest in. Such faults could
Steven A. Falco wrote:
The rt_misc_get_io_region() has the start argument as an unsigned
long. On the PPC440, we have a 36-bit address space, where the I/O
registers are generally above the 4GB area. For example, the UART is at
address 0x1ef600300.
The Linux request_region call has
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
...
Xenomai is loaded at this time but not yet used. Linux runs in tickless
highres mode and obviously had programmed the host timer to fire here.
But instead of one timer IRQ (233) + its handling, we see
Jan Kiszka wrote:
Jan Kiszka wrote:
...
Xenomai is loaded at this time but not yet used. Linux runs in tickless
highres mode and obviously had programmed the host timer to fire here.
But instead of one timer IRQ (233) + its handling, we see an additional
early shot (about 3 µs too early here
Jan Kiszka wrote:
sysinfo.tmfreq was meant to be such value.
Well, then it is totally mis-initialised on x86 so far, same on powerpc.
In fact, there it is the _clock_ frequency, not the timer frequency. So
what is meant by this? One comment actually call it Timebase frequency
(powerpc).
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
[Let's discuss this without bothering users :)]
Philippe Gerum wrote:
Author: rpm
Date: Sun Nov 4 18:18:39 2007
New Revision: 3147
URL: http://svn.gna.org/viewcvs/xenomai?rev=3147view=rev
Log:
Make
Jan Kiszka wrote:
Jan Kiszka wrote:
This patch addresses the recently discovered issue that I-pipe actually
need to deal with faults over non-root domain in which the current
domain shows no interest in. Such faults could be triggered inside
copy_*_user, thus can cleanly be handled by Linux -
Jan Kiszka wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
[Let's discuss this without bothering users :)]
Philippe Gerum wrote:
Author: rpm
Date: Sun Nov 4 18:18:39 2007
New Revision: 3147
URL: http://svn.gna.org/viewcvs/xenomai?rev
Jeroen Van den Keybus wrote:
arch_setup_msi_irq() creates an IRQ on-the-fly from the current
descriptor which is being converted to an MSI interrupt using
pci_msi_enable(). From that point, the I-pipe might have an obsolete
view of the interrupt map. I suspect an I-pipe issue
Jeroen Van den Keybus wrote:
We have a driver that operates on a PCIe card. The card has IRQ17. If we
use it like that (IO-APIC-fasteoi), interrupt registration using
rtdm_irq_request works correctly. (We also use rtdm_irq_enable
afterwards, but it seems that the request already enables the
Jeroen Van den Keybus wrote:
Now looking into xnintr_attach().
In xnintr_attach(), the crash occurs in xnarch_set_irq_affinity(). If
the call is removed, the driver works as expected (gaining another 3
usec of latency). Now investigating ipipe_set_irq_affinity.
Giammarco Zacheo wrote:
Does anybody ever tried to port Xenomai on a Efika board?
http://www.genesippc.com/efika.php
It is a freescale powerpc based board, with some patches to make linux
work on it. I have read some emails on the net talking about RTAI, so
what about Xenomai?
Xenomai
Fillod Stephane wrote:
Philippe Gerum wrote:
[...]
This rounding was missing too. We need the previous one for kernel
local
heaps, and the one below to meet the stricter PAGE_SIZE constraint for
shareable heaps.
--- ksrc/nucleus/heap.c (revision 3095)
+++ ksrc/nucleus/heap.c
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
On the other
hand, there is still the broken blackfin arch...
And the x86_64 too - just enable AUDIT_SYSCALL. And we need the ARM
upgrade too.
Can't follow you regarding CONFIG_AUDIT_SYSCALL. What else is required
beyond simply
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
the i386/x86_64 merge which just happened upstream, without having to
fiddle at the same time with the slew of other core changes which
Jan Kiszka wrote:
Philippe Gerum wrote:
The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
the i386/x86_64 merge which just happened upstream, without having to
fiddle at the same time with the slew of other core changes which will
hit the street before 2.6.24 is released
Fillod Stephane wrote:
Philippe Gerum wrote:
Fillod Stephane wrote:
For the legacy RTAI application to load, the attached patch was
necessary.
The patch against ksrc/skins/rtai/shm.c is somewhat defeating the
purpose
of a lower XNCORE_PAGE_SIZE, so a better fix might be expected.
This one
Here is the fifth candidate release for the v2.4.x branch.
[nucleus]
* Enforce CPU affinity unconditionally.
* Allow for daisy chains of periodic tick handlers.
* Fix rounding and minimum value of mappable heap size.
[blackfin]
* Upgrade Adeos
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
Steven A. Falco wrote:
I am testing kernel 2.6.23 ARCH=powerpc with Xenomai 2.4-rc4. The
clocktest and cyclictest work perfectly with the uic/spinlock patches.
However, the irqloop test fails with the Oops shown below.
Please try the patch below. It looks like the chip descriptor does not
Philippe Gerum wrote:
The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
the i386/x86_64 merge which just happened upstream, without having to
fiddle at the same time with the slew of other core changes which will
hit the street before 2.6.24 is released. You need
The I-pipe/i386 has been ported to 2.6.24-rc1, so that we could swallow
the i386/x86_64 merge which just happened upstream, without having to
fiddle at the same time with the slew of other core changes which will
hit the street before 2.6.24 is released. You need the latest trunk/ to
configure
If you happen to use Xenomai on fairly old x86 hardware with the IO-APIC
support enabled, you may want to upgrade your I-pipe version to one of
those listed below.
Symptom: random lockup, more likely under high interrupt load
Cause: mishandling of some hardware erratum affecting some IO-APIC
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
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
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
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
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?
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
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)
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
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 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 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 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 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 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-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 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-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
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 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
501 - 600 of 1458 matches
Mail list logo
