[Xenomai-core] arm ixp: more trouble with recent xenomai

[Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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
xeno_nucleus is okay, but the system freezes immediately on loading
xeno_native or xeno_posix.

I tried disabling various CONFIG options, and I found by accident that
enabling IPIPE_DEBUG allows the system to run just fine.

Any hints on where to go from here?

BTW, I also started to compare latency results from various
combinations of ipipe/xenomai. The results a summarized in the table
below.

For the tests, I cleared /proc/xenomai/latency to zero and ran two
instances of "busy.sh", each one in its own xterm, via ssh. Toward the
end of each run, I stopped the scripts at let the system idle for
about ten seconds, in order to get a reading of the minimum latency,
too.

Thanks in advance,
Richard

* latency

  |--------+---------+-------+---------+---------+---------+----------|
  | Kernel | Xeno    | IPIPE |         |         |         |          |
  | Vers   | Vers    | DEBUG | lat min | lat avg | lat max | duration |
  |--------+---------+-------+---------+---------+---------+----------|
  | v30    | v2.4.10 | no    |   8.430 |  17.310 |  63.510 | 00:02:35 |
  | v31    | v2.5.6  | no    |   7.215 |  34.020 |  85.350 | 00:02:58 |
  | v33    | v2.5.6  | yes   |  17.250 |  55.815 | 127.516 | 00:02:00 |
  | v35    | v2.5.6  | yes   |   7.140 |  34.200 |  84.180 | 00:02:17 |
  |--------+---------+-------+---------+---------+---------+----------|

* busy.sh

#!/bin/sh
while [ 1 ] ; do
	find /
	cat /dev/mem > /dev/null
	hackbench -g 1 -T 4 -s 1000 -l 1000
	calibrator 400 1M /tmp/out
done

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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 XENO_OPT_DEBUG options enabled.

Disabling XENO_OPT_DEBUG results in a kernel that freezes. I will try
to find out which of these options makes a difference.

Thanks,

Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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 boot have all of the XENO_OPT_DEBUG options enabled.
> 
> Disabling XENO_OPT_DEBUG results in a kernel that freezes. I will try
> to find out which of these options makes a difference.

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?

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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 IPIPE_DEBUG. The kernels
>> that boot have all of the XENO_OPT_DEBUG options enabled.
>>
>> Disabling XENO_OPT_DEBUG results in a kernel that freezes. I will try
>> to find out which of these options makes a difference.
> 
> 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 to revert is this one:
http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=cbd591ed5797f105ff45e04cca3bc939388624ea;hp=a2761e92ecd573bc3a3b068d4ebb7cc06313213c

Also please try disabling the FCSE code. This one changed too...

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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 kernel that freezes. I will try
> >> to find out which of these options makes a difference.

Okay, I confused myself on this one:

I don't need XENO_OPT_DEBUG to boot, just IPIPE_DEBUG.

> > 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 to revert is this one:
> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=cbd591ed5797f105ff45e04cca3bc939388624ea;hp=a2761e92ecd573bc3a3b068d4ebb7cc06313213c

Will do.

> Also please try disabling the FCSE code. This one changed too...

With IPIPE_DEBUG=n and FCSE=n it also boots.

But I really need FCSE guaranteed!

Thanks,
Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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 to revert is this one:
> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=cbd591ed5797f105ff45e04cca3bc939388624ea;hp=a2761e92ecd573bc3a3b068d4ebb7cc06313213c

Okay, with cbd591ed57 reverted, it works fine even without IPIPE_DEBUG.

The performance is still about 20 usec worse than xenomai 2.4 with ipipe 2.6.30.

  |------------+------+---------+-------+---------+---------+---------+----------|
  | Kernel     |      | Xeno    | IPIPE |         |         |         |          |
  | Vers       | FCSE | Vers    | DEBUG | lat min | lat avg | lat max | duration |
  |------------+------+---------+-------+---------+---------+---------+----------|
  | v30        | yes  | v2.4.10 | no    |   8.430 |  17.310 |  63.510 | 00:02:35 |
  | v31        | yes  | v2.5.6  | no    |   7.215 |  34.020 |  85.350 | 00:02:58 |
  | v33        | yes  | v2.5.6  | yes   |  17.250 |  55.815 | 127.516 | 00:02:00 |
  | v35        | yes  | v2.5.6  | yes   |   7.140 |  34.200 |  84.180 | 00:02:17 |
  | v35-revert | yes  | v2.5.6  | no    |   7.350 |  29.430 |  85.185 | 00:05:50 |
  | v35        | no   | v2.5.6  | no    |   6.960 | 109.500 | 214.156 | 00:09:41 |
  |------------+------+---------+-------+---------+---------+---------+----------|

I will try xenomai 2.5 with ipipe 2.6.35 next...

Thanks,
Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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?
>>>
>> The exact commit to revert is this one:
>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=cbd591ed5797f105ff45e04cca3bc939388624ea;hp=a2761e92ecd573bc3a3b068d4ebb7cc06313213c
> 
> Okay, with cbd591ed57 reverted, it works fine even without IPIPE_DEBUG.
> 
> The performance is still about 20 usec worse than xenomai 2.4 with ipipe 2.6.30.
> 
>   |------------+------+---------+-------+---------+---------+---------+----------|
>   | Kernel     |      | Xeno    | IPIPE |         |         |         |          |
>   | Vers       | FCSE | Vers    | DEBUG | lat min | lat avg | lat max | duration |
>   |------------+------+---------+-------+---------+---------+---------+----------|
>   | v30        | yes  | v2.4.10 | no    |   8.430 |  17.310 |  63.510 | 00:02:35 |
>   | v31        | yes  | v2.5.6  | no    |   7.215 |  34.020 |  85.350 | 00:02:58 |
>   | v33        | yes  | v2.5.6  | yes   |  17.250 |  55.815 | 127.516 | 00:02:00 |
>   | v35        | yes  | v2.5.6  | yes   |   7.140 |  34.200 |  84.180 | 00:02:17 |
>   | v35-revert | yes  | v2.5.6  | no    |   7.350 |  29.430 |  85.185 | 00:05:50 |
>   | v35        | no   | v2.5.6  | no    |   6.960 | 109.500 | 214.156 | 00:09:41 |
>   |------------+------+---------+-------+---------+---------+---------+----------|
> 
> I will try xenomai 2.5 with ipipe 2.6.35 next...

Ok, please try Xenomai 2.5.6 with I-pipe for 2.6.30, in order to know if
the difference comes from the I-pipe of from Xenomai. You can also play
with the various I-pipe versions, going back in the releases.

Note that with FCSEv4, you probably want "preemptible cache flushes"
with FCSE guaranteed. And of course, please do not enable FCSE_DEBUG for
performances testing.

You can also try and enable the I-pipe tracer. But I am not sure it
works on all versions.

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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: In function 'rthal_get_cpufreq':
 include/asm-generic/xenomai/hal.h:168: error: 'struct ipipe_sysinfo' has no member named 'cpufreq'
 include/asm-generic/xenomai/hal.h: In function 'rthal_get_timerfreq':
 include/asm-generic/xenomai/hal.h:175: error: 'struct ipipe_sysinfo' has no member named 'archdep'

But I think its not worth the effort to try that combination.

> Ok, please try Xenomai 2.5.6 with I-pipe for 2.6.30, in order to know if
> the difference comes from the I-pipe of from Xenomai.

So here is what I measured. Despite all the performance enhancements
added in Xenomai 2.5, it seems that 2.4 still performs better on my
platform. The difference isn't huge, but it is visible.

  |------------+------+------------+-------+---------+---------+---------+----------|
  | Kernel     |      | Xeno       | IPIPE |         |         |         |          |
  | Vers       | FCSE | Vers       | DEBUG | lat min | lat avg | lat max | duration |
  |------------+------+------------+-------+---------+---------+---------+----------|
  | v30        | yes  | v2.4.10    | no    |   8.430 |  17.310 |  63.510 | 00:02:35 |
  | v30        | yes  | v2.5.6 [1] | no    |   7.260 |  32.745 |  80.775 | 00:03:09 |
  | v30        | yes  | v2.5.6 [2] | no    |   7.140 |  34.950 |  78.375 | 00:03:21 |
  |------------+------+------------+-------+---------+---------+---------+----------|
  | v31        | yes  | v2.5.6     | no    |   7.215 |  34.020 |  85.350 | 00:02:58 |
  | v33        | yes  | v2.5.6     | yes   |  17.250 |  55.815 | 127.516 | 00:02:00 |
  | v35        | yes  | v2.5.6     | yes   |   7.140 |  34.200 |  84.180 | 00:02:17 |
  | v35-revert | yes  | v2.5.6     | no    |   7.350 |  29.430 |  85.185 | 00:05:50 |
  | v35        | no   | v2.5.6     | no    |   6.960 | 109.500 | 214.156 | 00:09:41 |
  |------------+------+------------+-------+---------+---------+---------+----------|

  [1] CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=y
  [2] CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=n

Gilles, I will try your tsc test program later this week...

Thanks,
Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

Richard Cochran wrote:
> 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: In function 'rthal_get_cpufreq':
>  include/asm-generic/xenomai/hal.h:168: error: 'struct ipipe_sysinfo' has no member named 'cpufreq'
>  include/asm-generic/xenomai/hal.h: In function 'rthal_get_timerfreq':
>  include/asm-generic/xenomai/hal.h:175: error: 'struct ipipe_sysinfo' has no member named 'archdep'
> 
> But I think its not worth the effort to try that combination.
> 
>> Ok, please try Xenomai 2.5.6 with I-pipe for 2.6.30, in order to know if
>> the difference comes from the I-pipe of from Xenomai.
> 
> So here is what I measured. Despite all the performance enhancements
> added in Xenomai 2.5, it seems that 2.4 still performs better on my
> platform. The difference isn't huge, but it is visible.
> 
>   |------------+------+------------+-------+---------+---------+---------+----------|
>   | Kernel     |      | Xeno       | IPIPE |         |         |         |          |
>   | Vers       | FCSE | Vers       | DEBUG | lat min | lat avg | lat max | duration |
>   |------------+------+------------+-------+---------+---------+---------+----------|
>   | v30        | yes  | v2.4.10    | no    |   8.430 |  17.310 |  63.510 | 00:02:35 |
>   | v30        | yes  | v2.5.6 [1] | no    |   7.260 |  32.745 |  80.775 | 00:03:09 |
>   | v30        | yes  | v2.5.6 [2] | no    |   7.140 |  34.950 |  78.375 | 00:03:21 |
>   |------------+------+------------+-------+---------+---------+---------+----------|
>   | v31        | yes  | v2.5.6     | no    |   7.215 |  34.020 |  85.350 | 00:02:58 |
>   | v33        | yes  | v2.5.6     | yes   |  17.250 |  55.815 | 127.516 | 00:02:00 |
>   | v35        | yes  | v2.5.6     | yes   |   7.140 |  34.200 |  84.180 | 00:02:17 |
>   | v35-revert | yes  | v2.5.6     | no    |   7.350 |  29.430 |  85.185 | 00:05:50 |
>   | v35        | no   | v2.5.6     | no    |   6.960 | 109.500 | 214.156 | 00:09:41 |
>   |------------+------+------------+-------+---------+---------+---------+----------|
> 
>   [1] CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=y
>   [2] CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=n

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:
http://git.xenomai.org/?p=mkrootfs.git;a=blob_plain;f=tests/noltp_hell;hb=HEAD

During four hours. It requires running
netcat "board" 5566 > /dev/null

After the board netcat is started.

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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:
> http://git.xenomai.org/?p=mkrootfs.git;a=blob_plain;f=tests/noltp_hell;hb=HEAD

Of course, the longer the test, the more confidence you have.

But, when tracking down kernel freezes and toggling two component
versions and a half dozen CONFIG options, sometimes you do short tests
just to "sample" the combination.

I will follow these up with overnight tests, but I think the trend is
already becoming clear...

Thanks,

Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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:
>> http://git.xenomai.org/?p=mkrootfs.git;a=blob_plain;f=tests/noltp_hell;hb=HEAD
> 
> Of course, the longer the test, the more confidence you have.

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 and FCSE was around 150us. So, I suspect the test you show
us are not really meaningful. Improving the worst case latency sometimes
results in a higher average latency.

Each release of the I-pipe patch is tested with the boards at my
disposal, and the latency on the oldest board I have, a csb637, has been
the same for a long time. But I can test again a 2.4.10 to confirm this.

In any case, if you want to investigate the difference, the best tool is
the I-pipe tracer. As I said, I am not sure it worked with all versions,
but I can help get it working.

> 
> But, when tracking down kernel freezes and toggling two component
> versions and a half dozen CONFIG options, sometimes you do short tests
> just to "sample" the combination.

Exactly, and IMO, we should not get sidetracked in premature statements
and conclusions about performance of the system when we are tracking a
stability issue. Let us solve the stability issue first, then we will
look into any potential performance issue, and we will do it with a
proper load of the system, and with a four hours test.

What compiler are you using by the way?

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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

Configured with:
/home/cochran/abul-gnueabi/targets/src/gcc-4.2.4/configure
--build=i486-build_pc-linux-gnu --host=i486-build_pc-linux-gnu
--target=armeb-unknown-linux-gnueabi
--prefix=/home/cochran/x-tools/armeb-unknown-linux-gnueabi
--with-sysroot=/home/cochran/x-tools/armeb-unknown-linux-gnueabi/armeb-unknown-linux-gnueabi//sys-root
--enable-languages=c,c++ --disable-multilib --with-arch=armv5te
--with-cpu=xscale --with-tune=xscale --with-float=soft
--with-gmp=/home/cochran/x-tools/armeb-unknown-linux-gnueabi
--with-mpfr=/home/cochran/x-tools/armeb-unknown-linux-gnueabi
--disable-sjlj-exceptions --enable-__cxa_atexit
--with-local-prefix=/home/cochran/x-tools/armeb-unknown-linux-gnueabi/armeb-unknown-linux-gnueabi//sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace

Thread model: posix
gcc version 4.2.4

Thanks,

Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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 version work with 2.5.6, including the latest one which
is based on gcc 4.5. Ah, but they do not support big endian. I was just
asking to know if you were not using something like gcc 3.x. gcc 4.2 is
OK, though it has some bug with stack unwinding which we do not care about.

-- 
					    Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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 and FCSE was around 150us.

But that was FCSE best effort, no?

Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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 latency with
>> Xenomai 2.4 and FCSE was around 150us.
> 
> But that was FCSE best effort, no?

Guaranteed, but with all the load in the noltp_hell script (that is
nework load, I/O load, hackbench, etc...).

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

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?
>>>
>> The exact commit to revert is this one:
>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=cbd591ed5797f105ff45e04cca3bc939388624ea;hp=a2761e92ecd573bc3a3b068d4ebb7cc06313213c
> 
> Okay, with cbd591ed57 reverted, it works fine even without IPIPE_DEBUG.

Sorry for the multiple answers to each mail...

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.

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.

-- 
                                                                Gilles.

[-- Attachment #2: test_tsc.c --]
[-- Type: text/x-csrc, Size: 2775 bytes --]

#include <stdio.h>
#if 0
#include <native/timer.h>

#define rdtsc() rt_timer_tsc()
#define init_tsc() do {			\
	} while(0)
#elif 1
#include <stdlib.h>

#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
/* Change this according to the real tsc type */
#define XNARCH_ARM_TSC_TYPE __XN_TSC_TYPE_FREERUNNING

#include <asm/xenomai/syscall.h>

struct __xn_tscinfo __xn_tscinfo = {
	.type = XNARCH_ARM_TSC_TYPE,
	/* Change according to real tsc */
	.u = {
		.fr = {
			.counter = 0,
			.mask = 0xffffffff,
			.tsc = (unsigned long long *)(0xffff0fa0 - 0x80),
		},
	},
};

#define rdtsc() __xn_rdtsc()
static void init_tsc(void)
{
	unsigned long phys_addr;
	unsigned page_size;
	void *addr;
	int fd;

	fd = open("/dev/mem", O_RDONLY | O_SYNC);
	if (fd == -1) {
		perror("Xenomai init: open(/dev/mem)");
		exit(EXIT_FAILURE);
	}

	page_size = sysconf(_SC_PAGESIZE);

	/* Counter physical address, depends on hardware */
	phys_addr = 0xC8005000UL;
	addr = mmap(NULL, page_size, PROT_READ, MAP_SHARED,
		    fd, phys_addr & ~(page_size - 1));
	if (addr == MAP_FAILED) {
		perror("Xenomai init: mmap(/dev/mem)");
		exit(EXIT_FAILURE);
	}

	__xn_tscinfo.u.fr.counter =
		((volatile unsigned *)
		 ((char *) addr + (phys_addr & (page_size - 1))));
}

#else
/* The newest version */
#include <stdlib.h>

#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

static unsigned long cntr_addr;

static unsigned long long (*rdtsc_inner)(unsigned long) =
	(void *)(0xffff0fa0 - 0x5c);
#define rdtsc() (*rdtsc_inner)(cntr_addr)
static void init_tsc(void)
{
	unsigned long phys_addr;
	unsigned page_size;
	void *addr;
	int fd;

	fd = open("/dev/mem", O_RDONLY | O_SYNC);
	if (fd == -1) {
		perror("Xenomai init: open(/dev/mem)");
		exit(EXIT_FAILURE);
	}

	page_size = sysconf(_SC_PAGESIZE);

	/* Counter physical address, depends on hardware */
	phys_addr = 0xC8005000UL;
	addr = mmap(NULL, page_size, PROT_READ, MAP_SHARED,
		    fd, phys_addr & ~(page_size - 1));
	if (addr == MAP_FAILED) {
		perror("Xenomai init: mmap(/dev/mem)");
		exit(EXIT_FAILURE);
	}

	cntr_addr =
		(unsigned long)
		 ((char *) addr + (phys_addr & (page_size - 1)));
}
#endif

int main(void)
{
	unsigned long long runtime, jump, tsc1, tsc2;

	init_tsc();

	runtime = tsc2 = rdtsc();
	for(;;) {
		tsc1 = rdtsc();
		if (tsc1 <= tsc2)
			break;
		tsc2 = rdtsc();
		if (tsc2 <= tsc1)
			goto err2;
	}

	runtime = tsc2 - runtime;
	jump = tsc2 - tsc1;
	goto display;
  err2:
	runtime = tsc1 - runtime;
	jump = tsc1 - tsc2;

  display:
	fprintf(stderr, "tsc not monotonic after %Lu.%09Lu ticks, ",
		runtime / 1000000000ULL, runtime % 1000000000ULL);
	fprintf(stderr, "jumped back %Lu tick\n", jump);

	return 1;

}

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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 XENO_HW_UNLOCKED_SWITCH=n might improve
latency?

The help for this option says...

    This option reduces interrupt latency when costly cache and
    TLB flushes are required to switch context, and may improve
    concurrency on some SMP/multi-core systems as well.

    You definitely want to enable that option on embedded ARM
    platforms.

so I am confused.

Thanks,

Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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 saying that XENO_HW_UNLOCKED_SWITCH=n might improve
> latency?
> 
> The help for this option says...
> 
>     This option reduces interrupt latency when costly cache and
>     TLB flushes are required to switch context, and may improve
>     concurrency on some SMP/multi-core systems as well.
> 
>     You definitely want to enable that option on embedded ARM
>     platforms.
> 
> so I am confused.

Is is a trade-off.

With this option enabled a context switch may be interrupted, this
improves interrupt latency, but at the expense of scheduling latency.

It makes a lot of sense without FCSE, when each context switch implies a
200us cache flush. A bit less with FCSE in guaranteed mode.


-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

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 ipipe 2.6.35 but
without xenomai. It seems to run fine. But I only ran it for a few
minutes.  The exact version was ipipe-2.6.35.9-arm-1.18-01 plus endian
fix, and I attached the config.

I enabled the *third* #if-elif-else case thinking it to be the correct
one to test. (see below)

> #include <stdio.h>
> #if 0
> #include <native/timer.h>
> 
> #define rdtsc() rt_timer_tsc()
> #define init_tsc() do {			\
> 	} while(0)
> #elif 1

Changed to 0...

> #else
> /* The newest version */

... to use this one.

> #endif

So, assuming I got that right, then the new tsc code passes the test.
Next I'll try to get some better information about the freeze. Any
other ideas?

Thanks,
Richard

[-- Attachment #2: Config --]
[-- Type: text/plain, Size: 28100 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.35.9
# Wed Apr 13 20:48:58 2011
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
# CONFIG_ARCH_USES_GETTIMEOFFSET is not set
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TREE_PREEMPT_RCU is not set
# CONFIG_TINY_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_LZO is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
# CONFIG_KALLSYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_SHMEM is not set
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y

#
# GCOV-based kernel profiling
#
# CONFIG_SLOW_WORK is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_BLOCK=y
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
# CONFIG_INLINE_SPIN_TRYLOCK is not set
# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK is not set
# CONFIG_INLINE_SPIN_LOCK_BH is not set
# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
CONFIG_INLINE_SPIN_UNLOCK=y
# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_READ_TRYLOCK is not set
# CONFIG_INLINE_READ_LOCK is not set
# CONFIG_INLINE_READ_LOCK_BH is not set
# CONFIG_INLINE_READ_LOCK_IRQ is not set
# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
CONFIG_INLINE_READ_UNLOCK=y
# CONFIG_INLINE_READ_UNLOCK_BH is not set
CONFIG_INLINE_READ_UNLOCK_IRQ=y
# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
# CONFIG_INLINE_WRITE_TRYLOCK is not set
# CONFIG_INLINE_WRITE_LOCK is not set
# CONFIG_INLINE_WRITE_LOCK_BH is not set
# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
CONFIG_INLINE_WRITE_UNLOCK=y
# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
# CONFIG_MUTEX_SPIN_ON_OWNER is not set

#
# Real-time sub-system
#
# CONFIG_XENOMAI is not set
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
# CONFIG_FREEZER is not set

#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCMRING is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_STMP3XXX is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
CONFIG_ARCH_IXP4XX=y
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_LOKI is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_NUC93X is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P6440 is not set
# CONFIG_ARCH_S5P6442 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_PLAT_SPEAR is not set
CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y

#
# Intel IXP4xx Implementation Options
#

#
# IXP4xx Platforms
#
CONFIG_MACH_DEVIXP=y
# CONFIG_MACH_MICCPT is not set
CONFIG_MACH_MIC256=y
# CONFIG_MACH_NSLU2 is not set
# CONFIG_MACH_AVILA is not set
# CONFIG_ARCH_ADI_COYOTE is not set
# CONFIG_MACH_GATEWAY7001 is not set
# CONFIG_MACH_WG302V2 is not set
# CONFIG_ARCH_IXDP425 is not set
# CONFIG_MACH_IXDPG425 is not set
# CONFIG_MACH_IXDP465 is not set
# CONFIG_MACH_GORAMO_MLR is not set
# CONFIG_MACH_KIXRP435 is not set
# CONFIG_ARCH_PRPMC1100 is not set
# CONFIG_MACH_NAS100D is not set
# CONFIG_MACH_DSMG600 is not set
# CONFIG_MACH_FSG is not set
# CONFIG_MACH_GTWX5715 is not set

#
# IXP4xx Options
#
# CONFIG_IXP4XX_INDIRECT_PCI is not set
CONFIG_IXP4XX_QMGR=y
CONFIG_IXP4XX_NPE=y
CONFIG_IPIPE_ARM_KUSER_TSC=y

#
# Processor Type
#
CONFIG_CPU_XSCALE=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5T=y
CONFIG_CPU_PABRT_LEGACY=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
# CONFIG_ARM_THUMB is not set
CONFIG_CPU_BIG_ENDIAN=y
# CONFIG_CPU_ENDIAN_BE8 is not set
CONFIG_CPU_ENDIAN_BE32=y
# CONFIG_CPU_DCACHE_DISABLE is not set
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_FCSE=y
CONFIG_ARM_FCSE_GUARANTEED=y
# CONFIG_ARM_FCSE_BEST_EFFORT is not set
CONFIG_ARM_FCSE_PREEMPT_FLUSH=y
# CONFIG_ARM_FCSE_MESSAGES is not set
# CONFIG_ARM_FCSE_DEBUG is not set
# CONFIG_IWMMXT is not set
CONFIG_XSCALE_PMU=y
CONFIG_CPU_HAS_PMU=y
CONFIG_DMABOUNCE=y

#
# Bus support
#
CONFIG_PCI=y
CONFIG_PCI_SYSCALL=y
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCI_STUB is not set
# CONFIG_PCI_IOV is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_TICK_ONESHOT=y
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_IPIPE=y
CONFIG_IPIPE_DOMAINS=4
# CONFIG_IPIPE_DELAYED_ATOMICSW is not set
# CONFIG_IPIPE_UNMASKED_CONTEXT_SWITCH is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
# CONFIG_HIGHMEM is not set
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set

#
# Boot options
#
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="root=/dev/mtdblock2 rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 init=/etc/preinit"
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set

#
# CPU Power Management
#
# CONFIG_CPU_IDLE is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Power management options
#
# CONFIG_PM is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_PIMSM_V1 is not set
# CONFIG_IP_PIMSM_V2 is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
# CONFIG_BRIDGE_NETFILTER is not set

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
CONFIG_STP=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_IGMP_SNOOPING=y
# CONFIG_NET_DSA is not set
CONFIG_VLAN_8021Q=y
# CONFIG_VLAN_8021Q_GVRP is not set
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#

#
# Some wireless drivers require a rate control algorithm
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_REDBOOT_PARTS=y
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
CONFIG_MTD_REDBOOT_PARTS_READONLY=y
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_HAVE_MTD_OTP=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_OTP=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_ARM_INTEGRATOR is not set
CONFIG_MTD_IXP4XX=y
# CONFIG_MTD_PCI is not set
# CONFIG_MTD_GPIO_ADDR is not set
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set

#
# UBI - Unsorted block images
#
# CONFIG_MTD_UBI is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set

#
# DRBD disabled because PROC_FS, INET or CONNECTOR not selected
#
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# You can enable one or both FireWire driver stacks.
#

#
# The newer stack is recommended.
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
CONFIG_LXT_PHY=y
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
CONFIG_NATIONAL_PHY=m
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_IXP4XX_ETH=y
# CONFIG_AX88796 is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_SMC91X is not set
# CONFIG_DM9000 is not set
# CONFIG_ETHOC is not set
# CONFIG_SMC911X is not set
# CONFIG_SMSC911X is not set
# CONFIG_DNET is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_NET_PCI is not set
# CONFIG_B44 is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_ATL2 is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
CONFIG_WLAN=y
# CONFIG_ATMEL is not set
# CONFIG_PRISM54 is not set
# CONFIG_HOSTAP is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

#
# Input device support
#
# CONFIG_INPUT is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
# CONFIG_VT is not set
# CONFIG_DEVKMEM is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_PCI is not set
CONFIG_SERIAL_8250_NR_UARTS=2
CONFIG_SERIAL_8250_RUNTIME_UARTS=2
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_UNIX98_PTYS is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_IXP4XX=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
# CONFIG_RAMOOPS is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_IOP3XX is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set

#
# PPS support
#
# CONFIG_PPS is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
CONFIG_IXP4XX_WATCHDOG=y
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_ALIM7101_WDT is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_MFD_SUPPORT=y
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TPS6507X is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TC35892 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_LPC_SCH is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
# CONFIG_SOUND is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_GPIO_PLATFORM=y
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
CONFIG_LEDS_TRIGGERS=y

#
# LED Triggers
#
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_DEBUG=y

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
# CONFIG_EXT3_FS is not set
# CONFIG_EXT4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
# CONFIG_PROC_PAGE_MONITOR is not set
CONFIG_SYSFS=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
# CONFIG_JFFS2_CMODE_FAVOURLZO is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_NLS is not set
# CONFIG_DLM is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_IPIPE_DEBUG is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
# CONFIG_OC_ETM is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_DEFAULT_SECURITY_SELINUX is not set
# CONFIG_DEFAULT_SECURITY_SMACK is not set
# CONFIG_DEFAULT_SECURITY_TOMOYO is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
# CONFIG_CRYPTO is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_LAST_BIT=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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 back to this, I did try the test program with ipipe 2.6.35 but
> without xenomai. It seems to run fine. But I only ran it for a few
> minutes.  The exact version was ipipe-2.6.35.9-arm-1.18-01 plus endian
> fix, and I attached the config.
> 
> I enabled the *third* #if-elif-else case thinking it to be the correct
> one to test. (see below)
> (...)

Yes, that was the correct thing to do. I assumed that when you enabled
Xenomai, the system was running, and that it frozen when you started a
Xenomai application. Which is not your case at all.
>
> So, assuming I got that right, then the new tsc code passes the test.
> Next I'll try to get some better information about the freeze. Any
> other ideas?

We have only one commit to inspect, that should not be so hard. Next
thing to try is to see what changed in the other parts of this commit.
We should look at the interrupt handler, ipipe_mach_set_dec,
ipipe_mach_release_timer to see what change had such an effect. I will
try to reorder the functions to have a more readable diff. You can also
check if we pass the rthal_calibrate_timer function.

Regards.

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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.
>> Getting back to this, I did try the test program with ipipe 2.6.35 but
>> without xenomai. It seems to run fine. But I only ran it for a few
>> minutes.  The exact version was ipipe-2.6.35.9-arm-1.18-01 plus endian
>> fix, and I attached the config.
>>
>> I enabled the *third* #if-elif-else case thinking it to be the correct
>> one to test. (see below)
>> (...)
> 
> Yes, that was the correct thing to do. I assumed that when you enabled
> Xenomai, the system was running, and that it frozen when you started a
> Xenomai application. Which is not your case at all.
>> So, assuming I got that right, then the new tsc code passes the test.
>> Next I'll try to get some better information about the freeze. Any
>> other ideas?
> 
> We have only one commit to inspect, that should not be so hard. Next
> thing to try is to see what changed in the other parts of this commit.
> We should look at the interrupt handler, ipipe_mach_set_dec,
> ipipe_mach_release_timer to see what change had such an effect. I will
> try to reorder the functions to have a more readable diff. You can also
> check if we pass the rthal_calibrate_timer function.

Hi Richard,

I am currently running some benchmarks on an AT91SAM9263 board, to see
whether we have some performance regression.

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 created by
ipipe_tsc_register, which probably has a shift of 25 or 26 bits instead
of the 20 bits shift of the original clocksource, and returns a 64 bits
value instead of 32 bits.
2- the fact that the tsc update is done with hardware irqs off in the
original patch.

I do not think 1 causes any problem, since the tsc test works (though,
you should run the test at least the time necessary for the counter to
wrap, a few times, the wrap time should be around one minute at 60 MHz).

For 2, here is a patch you could try:
diff --git a/arch/arm/kernel/ipipe_tsc.c b/arch/arm/kernel/ipipe_tsc.c
index a9de4f9..9fdda34 100644
--- a/arch/arm/kernel/ipipe_tsc.c
+++ b/arch/arm/kernel/ipipe_tsc.c
@@ -99,6 +99,9 @@ void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo
*info)

 void __ipipe_tsc_update(void)
 {
+	unsigned long flags;
+
+	local_irq_save_hw(flags);
 	if (tsc_info.type == IPIPE_TSC_TYPE_DECREMENTER) {
 		unsigned cnt = *(unsigned *)tsc_info.counter_vaddr;
 		int offset = ipipe_tsc_value->last_cnt - cnt;
@@ -106,8 +109,10 @@ void __ipipe_tsc_update(void)
 			offset += 0x10000;
 		ipipe_tsc_value->last_tsc += offset + 1;
 		ipipe_tsc_value->last_cnt = cnt - 1;
+		local_irq_restore_hw(flags);
 		return;
 	}
 	ipipe_tsc_value->last_tsc = __ipipe_tsc_get() - 1;
+	local_irq_restore_hw(flags);
 }
 EXPORT_SYMBOL(__ipipe_tsc_get);

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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
>>>> tsc behaves correctly.
>>> Getting back to this, I did try the test program with ipipe 2.6.35 but
>>> without xenomai. It seems to run fine. But I only ran it for a few
>>> minutes.  The exact version was ipipe-2.6.35.9-arm-1.18-01 plus endian
>>> fix, and I attached the config.
>>>
>>> I enabled the *third* #if-elif-else case thinking it to be the correct
>>> one to test. (see below)
>>> (...)
>> Yes, that was the correct thing to do. I assumed that when you enabled
>> Xenomai, the system was running, and that it frozen when you started a
>> Xenomai application. Which is not your case at all.
>>> So, assuming I got that right, then the new tsc code passes the test.
>>> Next I'll try to get some better information about the freeze. Any
>>> other ideas?
>> We have only one commit to inspect, that should not be so hard. Next
>> thing to try is to see what changed in the other parts of this commit.
>> We should look at the interrupt handler, ipipe_mach_set_dec,
>> ipipe_mach_release_timer to see what change had such an effect. I will
>> try to reorder the functions to have a more readable diff. You can also
>> check if we pass the rthal_calibrate_timer function.
> 
> Hi Richard,
> 
> I am currently running some benchmarks on an AT91SAM9263 board, to see
> whether we have some performance regression.

The FCSE support in the I-pipe patch for Linux 2.6.30 needs this
additional patch:
http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=50e97478bd64cc28937179989d17ebc1930829b4

Otherwise you get segmentation faults when exceeding the 95 processes limit.

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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 created by
> ipipe_tsc_register, which probably has a shift of 25 or 26 bits instead
> of the 20 bits shift of the original clocksource, and returns a 64 bits
> value instead of 32 bits.
> 2- the fact that the tsc update is done with hardware irqs off in the
> original patch.

Thanks for looking into this for me. I tried the patch, but the
result is the same as before:

- Kernel freezes immediately if xenomai is not a module.

- If xenomai is a module, the nucleus loads, but the first skin module
  freezes the machine.

I will take a closer look next week to see if I can find out at least
where the freeze happens.

Thanks,

Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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 "generic" clocksource created by
>> ipipe_tsc_register, which probably has a shift of 25 or 26 bits instead
>> of the 20 bits shift of the original clocksource, and returns a 64 bits
>> value instead of 32 bits.
>> 2- the fact that the tsc update is done with hardware irqs off in the
>> original patch.
> 
> Thanks for looking into this for me. I tried the patch, but the
> result is the same as before:
> 
> - Kernel freezes immediately if xenomai is not a module.
> 
> - If xenomai is a module, the nucleus loads, but the first skin module
>   freezes the machine.
> 
> I will take a closer look next week to see if I can find out at least
> where the freeze happens.

Ok. It means that rthal_calibrate_timer works, the system freezes when
Xenomai steals the timer. However, since the ipipe_mach_set_dec,
ipipe_mach_release_timer code did not change, it does not really make
sense. But in order to trace the issue, you should probably trace the
calls to ipipe_mach_set_dec/ipipe_mach_acktimer to see which one is the
last before the freeze.

On my side, I have run benches on at91sam9263, but am not done yet,
though yet I have not found a lot of differences in latencies between
2.4.10 and 2.5.6.

Which version of the I-pipe patch were you running with 2.4.10?

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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
>>>> tsc behaves correctly.
>>> Getting back to this, I did try the test program with ipipe 2.6.35 but
>>> without xenomai. It seems to run fine. But I only ran it for a few
>>> minutes.  The exact version was ipipe-2.6.35.9-arm-1.18-01 plus endian
>>> fix, and I attached the config.
>>>
>>> I enabled the *third* #if-elif-else case thinking it to be the correct
>>> one to test. (see below)
>>> (...)
>> Yes, that was the correct thing to do. I assumed that when you enabled
>> Xenomai, the system was running, and that it frozen when you started a
>> Xenomai application. Which is not your case at all.
>>> So, assuming I got that right, then the new tsc code passes the test.
>>> Next I'll try to get some better information about the freeze. Any
>>> other ideas?
>> We have only one commit to inspect, that should not be so hard. Next
>> thing to try is to see what changed in the other parts of this commit.
>> We should look at the interrupt handler, ipipe_mach_set_dec,
>> ipipe_mach_release_timer to see what change had such an effect. I will
>> try to reorder the functions to have a more readable diff. You can also
>> check if we pass the rthal_calibrate_timer function.
> 
> Hi Richard,
> 
> I am currently running some benchmarks on an AT91SAM9263 board, to see
> whether we have some performance regression.

Hi Richard,

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 well be in the
measurement noise. Unlocked context switch actually improves the latency.

I will update the png as I get new results.

Regards.

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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 well be in the
> measurement noise. Unlocked context switch actually improves the latency.
> 
> I will update the png as I get new results.

Gilles,

That is a very interesting graph. It might be nice to have a
"performance benchmarks" page on the wiki, including that figure, plus
the description of the test setup. I can contribute IXP and some
PowerPC results.

Regarding the measured performance, the graphs are shaped like the
letter, H (or like a Bactrian camel, with two humps).

I appears to me that the peaks of the 2.4.10 lines (red, green) are
standing clearly to the left of the 2.5.6 lines (blue, purple), by
about 10 microseconds. I would say that 2.4.10 outperforms 2.5.6, on
average.

The absolute worst case appears to be about the same, or perhaps
slightly improved in 2.5.6.

So the differences are not huge, but still I think 2.4.10 is looking
better.

Thanks,

Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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
>> it is decreasing a bit, but the differences may well be in the
>> measurement noise. Unlocked context switch actually improves the latency.
>>
>> I will update the png as I get new results.
> 
> Gilles,
> 
> That is a very interesting graph. It might be nice to have a
> "performance benchmarks" page on the wiki, including that figure, plus
> the description of the test setup. I can contribute IXP and some
> PowerPC results.

Yes, we should set this up. The xeno-test currently in the head branch
is made to help doing this.

> 
> Regarding the measured performance, the graphs are shaped like the
> letter, H (or like a Bactrian camel, with two humps).
> 
> I appears to me that the peaks of the 2.4.10 lines (red, green) are
> standing clearly to the left of the 2.5.6 lines (blue, purple), by
> about 10 microseconds. I would say that 2.4.10 outperforms 2.5.6, on
> average.

I added the average latencies (except for 2.4.10 with the I-pipe 1.14-04
patch). The peak corresponds roughly to the average "lat max" column in
latency results.

Both the I-pipe version and Xenomai version seem to contribute to the
increased average latency.

The unlocked context switch also improves the worst-case at the expense
of the average.

But there is hope, 2.6.33-1.18-03 introduces pic muting and re-enables
irq in the middle of gpio demuxing, which seems to improve the average
latency.

> 
> The absolute worst case appears to be about the same, or perhaps
> slightly improved in 2.5.6.
> 
> So the differences are not huge, but still I think 2.4.10 is looking
> better.

it is true that 2.4.10 had better average latencies, but the worst case
latencies seem to be improving, and I am afraid this is what we are
aiming at...

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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
>>> it is decreasing a bit, but the differences may well be in the
>>> measurement noise. Unlocked context switch actually improves the latency.
>>>
>>> I will update the png as I get new results.
>> Gilles,
>>
>> That is a very interesting graph. It might be nice to have a
>> "performance benchmarks" page on the wiki, including that figure, plus
>> the description of the test setup. I can contribute IXP and some
>> PowerPC results.
> 
> Yes, we should set this up. The xeno-test currently in the head branch
> is made to help doing this.
> 
>> Regarding the measured performance, the graphs are shaped like the
>> letter, H (or like a Bactrian camel, with two humps).
>>
>> I appears to me that the peaks of the 2.4.10 lines (red, green) are
>> standing clearly to the left of the 2.5.6 lines (blue, purple), by
>> about 10 microseconds. I would say that 2.4.10 outperforms 2.5.6, on
>> average.
> 
> I added the average latencies (except for 2.4.10 with the I-pipe 1.14-04
> patch). The peak corresponds roughly to the average "lat max" column in
> latency results.
> 
> Both the I-pipe version and Xenomai version seem to contribute to the
> increased average latency.
> 
> The unlocked context switch also improves the worst-case at the expense
> of the average.
> 
> But there is hope, 2.6.33-1.18-03 introduces pic muting and re-enables
> irq in the middle of gpio demuxing, which seems to improve the average
> latency.

Hi Richard,

I jumped to conclusions too quickly. I am not sure the results I obtain
really are meaningful. I am probably not doing it enough rigorously.

Regards.

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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 back to this, I did try the test program with ipipe 2.6.35 but
> without xenomai. It seems to run fine. But I only ran it for a few
> minutes.  The exact version was ipipe-2.6.35.9-arm-1.18-01 plus endian
> fix, and I attached the config.

Hi Richard,

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
assumptions...:

#include <stdio.h>

__attribute__((naked)) unsigned long long f(unsigned long long *x)
{
	asm("ldrd r0, [r0]\n\t"
	    "mov pc, lr");
}

__attribute__((naked)) unsigned long long g(unsigned long long *x)
{
	asm("ldm r0, {r0, r1}\n\t"
	    "mov pc, lr");
}

int main(void)
{
	unsigned long long x = 0xffffffffULL;

	printf("f: %Lx\n", f(&x));
	printf("g: %Lx\n", g(&x));
	return 0;
}

If you do not have time, do you agree for a revert of the KUSER_TSC code
to the one we had before, and which is working for you?

Regards.

-- 
                                                                Gilles.

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Richard Cochran]

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
> assumptions...:

~> armeb-unknown-linux-gnueabi-gcc -Wall arm.c
arm.c: In function 'f':
arm.c:7: warning: control reaches end of non-void function
arm.c: In function 'g':
arm.c:13: warning: control reaches end of non-void function

and then

# ./a.out 
f: ffffffff
g: ffffffff

> If you do not have time, do you agree for a revert of the KUSER_TSC code
> to the one we had before, and which is working for you?

I sorry about not getting back about this. I have had crunch trying to
meet a deadline, but now that is over. Tomorrow I'm on the road, but
next week looks good for IXP testing.

And thanks, thanks, for all your good work,

Richard

Re: [Xenomai-core] arm ixp: more trouble with recent xenomai

[Gilles Chanteperdrix]

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.