On Thu, May 12, 2011 at 02:03:34AM +0200, Gilles Chanteperdrix wrote:
the issue on ixp looks like the last one to be fixed on arm. If you have
time, could you try the following program? It makes a very basic test,
but not having a big-endian ixp at end, I am wondering about very basic
On 04/14/2011 06:42 PM, Richard Cochran wrote:
On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
To help debugging this, please run the kernel which crashes with I-pipe
enabled, without Xenomai, and the attached test, in order to see if the
tsc behaves correctly.
Getting
Gilles Chanteperdrix wrote:
Richard Cochran wrote:
On Sun, Apr 24, 2011 at 10:15:00PM +0200, Gilles Chanteperdrix wrote:
some temporary results on the benchmark here:
http://www.xenomai.org/~gch/latency-at91sam9263.png
The worst case latency seems not to vary much over time, it looks like
On Sun, Apr 24, 2011 at 10:15:00PM +0200, Gilles Chanteperdrix wrote:
some temporary results on the benchmark here:
http://www.xenomai.org/~gch/latency-at91sam9263.png
The worst case latency seems not to vary much over time, it looks like
it is decreasing a bit, but the differences may
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Richard Cochran wrote:
On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
To help debugging this, please run the kernel which crashes with I-pipe
enabled, without Xenomai, and the attached test, in order to see if the
On Fri, Apr 22, 2011 at 07:55:35AM +0200, Gilles Chanteperdrix wrote:
I also had a look at the culprit patch, reducing it to the bare minimum
(no useless whitespace changes and no function moves), and it boils down
to only two differences:
1- the fact that we use the generic clocksource
Richard Cochran wrote:
On Fri, Apr 22, 2011 at 07:55:35AM +0200, Gilles Chanteperdrix wrote:
I also had a look at the culprit patch, reducing it to the bare minimum
(no useless whitespace changes and no function moves), and it boils down
to only two differences:
1- the fact that we use the
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Richard Cochran wrote:
On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
To help debugging this, please run the kernel which crashes with I-pipe
enabled, without Xenomai, and the attached test, in order to see if the
Gilles Chanteperdrix wrote:
Richard Cochran wrote:
On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
To help debugging this, please run the kernel which crashes with I-pipe
enabled, without Xenomai, and the attached test, in order to see if the
tsc behaves correctly.
Richard Cochran wrote:
On Tue, Apr 12, 2011 at 09:17:43AM +0200, Gilles Chanteperdrix wrote:
Not only that. The aim of the test is to trigger the worst case path. I
suspect you can not trigger it with a 10 minutes tests. As you probably
remember, I was once running Xenomai on IXP465, and the
On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
To help debugging this, please run the kernel which crashes with I-pipe
enabled, without Xenomai, and the attached test, in order to see if the
tsc behaves correctly.
Getting back to this, I did try the test program with
On Tue, Apr 12, 2011 at 09:17:43AM +0200, Gilles Chanteperdrix wrote:
Not only that. The aim of the test is to trigger the worst case path. I
suspect you can not trigger it with a 10 minutes tests. As you probably
remember, I was once running Xenomai on IXP465, and the latency with
Xenomai 2.4
Richard Cochran wrote:
On Mon, Apr 11, 2011 at 11:26:33PM +0200, Gilles Chanteperdrix wrote:
Wait a minute. You are comparing results obtained after 2 or 3, or 10
minutes of runtime? I am not sure such results are meaningful. I do my
benchmarks with the noltp_hell test:
On Tue, Apr 12, 2011 at 09:17:43AM +0200, Gilles Chanteperdrix wrote:
What compiler are you using by the way?
I compiled this one myself using crosstool-ng. At the time I had first
tried gcc 4.3, but you advised me that it would not work for xenomai.
Target: armeb-unknown-linux-gnueabi
Richard Cochran wrote:
On Tue, Apr 12, 2011 at 09:17:43AM +0200, Gilles Chanteperdrix wrote:
What compiler are you using by the way?
I compiled this one myself using crosstool-ng. At the time I had first
tried gcc 4.3, but you advised me that it would not work for xenomai.
All codesourcery
Richard Cochran wrote:
On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
Also, about the performances, Xenomai 2.4 did not have the Xenomai
preemptible context switches. Maybe with FCSE, it results in reduced
latencies to disable this option in Xenomai 2.5.
So, are you
On Sun, Apr 10, 2011 at 11:34:14AM +0200, Gilles Chanteperdrix wrote:
Richard Cochran wrote:
I will try xenomai 2.5 with ipipe 2.6.35 next...
I meant to say, Xenomai 2.4 with ipipe 2.6.35, but this does not work
because the kernel definitions have changed:
include/asm-generic/xenomai/hal.h:
On Sat, Apr 09, 2011 at 09:50:16PM +0200, Gilles Chanteperdrix wrote:
Just to have an idea where the issue come from, could you try reverting
all the changes which were made on the tsc and timer? i.e. revert to the
original ipipe_mach_get_tsc and ipipe_mach_set_dec?
The exact commit
Richard Cochran wrote:
On Sat, Apr 09, 2011 at 09:50:16PM +0200, Gilles Chanteperdrix wrote:
Just to have an idea where the issue come from, could you try reverting
all the changes which were made on the tsc and timer? i.e. revert to the
original ipipe_mach_get_tsc and ipipe_mach_set_dec?
On Sun, Apr 10, 2011 at 01:22:08PM +0200, Gilles Chanteperdrix wrote:
Also, about the performances, Xenomai 2.4 did not have the Xenomai
preemptible context switches. Maybe with FCSE, it results in reduced
latencies to disable this option in Xenomai 2.5.
So, are you saying that
After fixing the ipipe big endian issue, I have run into some more
problems on my arm ixp425. Ipipe kernel 2.6.31 with xenomai 2.5.6
boots and runs fine. Ipipe kernel .33 and .35 both boot, but freeze
when xenomai is enabled.
I tried building xenomai as modules, and I found that loading
On Sat, Apr 09, 2011 at 08:41:22PM +0200, Richard Cochran wrote:
I tried disabling various CONFIG options, and I found by accident that
enabling IPIPE_DEBUG allows the system to run just fine.
Update: It is not enough for me to enable IPIPE_DEBUG. The kernels
that boot have all of the
Richard Cochran wrote:
On Sat, Apr 09, 2011 at 08:41:22PM +0200, Richard Cochran wrote:
I tried disabling various CONFIG options, and I found by accident that
enabling IPIPE_DEBUG allows the system to run just fine.
Update: It is not enough for me to enable IPIPE_DEBUG. The kernels
that
Richard Cochran wrote:
cat /dev/mem /dev/null
Are you really doing this? This is not a good idea. Please do your tests
without this, this alone can cause the hardware to freeze. In fact, I
would recommend using the new xeno-test available in head.
--
Gilles Chanteperdrix wrote:
Richard Cochran wrote:
On Sat, Apr 09, 2011 at 08:41:22PM +0200, Richard Cochran wrote:
I tried disabling various CONFIG options, and I found by accident that
enabling IPIPE_DEBUG allows the system to run just fine.
Update: It is not enough for me to enable
On Sat, Apr 09, 2011 at 09:50:16PM +0200, Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Richard Cochran wrote:
Update: It is not enough for me to enable IPIPE_DEBUG. The kernels
that boot have all of the XENO_OPT_DEBUG options enabled.
Disabling XENO_OPT_DEBUG results in a
26 matches
Mail list logo
