* [Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
@ 2007-10-09 17:19 Gregory CLEMENT
2007-10-09 18:15 ` Jan Kiszka
0 siblings, 1 reply; 13+ messages in thread
From: Gregory CLEMENT @ 2007-10-09 17:19 UTC (permalink / raw)
To: xenomai
Here, they are the last latency we get on AT91SAM9261-EK. As just now
I haven't the board at home, I send the last result we stored. The
prority of dbgu should be set to 6 instead of 7, but I can't assure
it, for Xenomai.
first Xenomai:
#insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko
#cd /usr/xenomai/bin/
#./latency -t 2 -p 150 -h -H 500
---|--param|----range-|--samples
HSD| min| 3 - 4 | 6
HSD| min| 4 - 5 | 12
HSD| min| 5 - 6 | 5
HSD| min| 6 - 7 | 128
HSD| min| 7 - 8 | 405
HSD| min| 8 - 9 | 18
---|--param|----range-|--samples
HSD| avg| 3 - 4 | 6
HSD| avg| 4 - 5 | 12
HSD| avg| 5 - 6 | 5
HSD| avg| 6 - 7 | 1248
HSD| avg| 7 - 8 | 1159824
HSD| avg| 8 - 9 | 1188725
HSD| avg| 9 - 10 | 238045
HSD| avg| 10 - 11 | 78398
HSD| avg| 11 - 12 | 134973
HSD| avg| 12 - 13 | 132552
HSD| avg| 13 - 14 | 129661
HSD| avg| 14 - 15 | 137458
HSD| avg| 15 - 16 | 49208
HSD| avg| 16 - 17 | 4532
HSD| avg| 17 - 18 | 2793
HSD| avg| 18 - 19 | 2494
HSD| avg| 19 - 20 | 2489
HSD| avg| 20 - 21 | 2373
HSD| avg| 21 - 22 | 3677
HSD| avg| 22 - 23 | 15370
HSD| avg| 23 - 24 | 173411
HSD| avg| 24 - 25 | 181883
HSD| avg| 25 - 26 | 1509
HSD| avg| 26 - 27 | 5058
HSD| avg| 27 - 28 | 9483
HSD| avg| 28 - 29 | 19691
HSD| avg| 29 - 30 | 18397
HSD| avg| 30 - 31 | 24228
HSD| avg| 31 - 32 | 19539
HSD| avg| 32 - 33 | 20438
HSD| avg| 33 - 34 | 17420
HSD| avg| 34 - 35 | 19943
HSD| avg| 35 - 36 | 15057
HSD| avg| 36 - 37 | 12100
HSD| avg| 37 - 38 | 1873
HSD| avg| 38 - 39 | 417
HSD| avg| 39 - 40 | 347
HSD| avg| 40 - 41 | 282
HSD| avg| 41 - 42 | 177
HSD| avg| 42 - 43 | 106
HSD| avg| 43 - 44 | 108
HSD| avg| 44 - 45 | 94
HSD| avg| 45 - 46 | 138
HSD| avg| 46 - 47 | 114
HSD| avg| 47 - 48 | 109
HSD| avg| 48 - 49 | 50
HSD| avg| 49 - 50 | 35
HSD| avg| 50 - 51 | 40
HSD| avg| 51 - 52 | 32
HSD| avg| 52 - 53 | 23
HSD| avg| 53 - 54 | 21
HSD| avg| 54 - 55 | 13
HSD| avg| 55 - 56 | 12
HSD| avg| 56 - 57 | 13
HSD| avg| 57 - 58 | 15
HSD| avg| 58 - 59 | 24
HSD| avg| 59 - 60 | 13
HSD| avg| 60 - 61 | 22
HSD| avg| 61 - 62 | 29
HSD| avg| 62 - 63 | 13
HSD| avg| 63 - 64 | 7
HSD| avg| 64 - 65 | 8
HSD| avg| 65 - 66 | 13
HSD| avg| 66 - 67 | 8
HSD| avg| 67 - 68 | 7
HSD| avg| 68 - 69 | 5
HSD| avg| 69 - 70 | 8
HSD| avg| 70 - 71 | 4
HSD| avg| 71 - 72 | 9
HSD| avg| 72 - 73 | 8
HSD| avg| 73 - 74 | 13
HSD| avg| 74 - 75 | 9
HSD| avg| 75 - 76 | 6
HSD| avg| 76 - 77 | 4
HSD| avg| 77 - 78 | 5
HSD| avg| 78 - 79 | 11
HSD| avg| 79 - 80 | 1
HSD| avg| 80 - 81 | 2
HSD| avg| 81 - 82 | 1
HSD| avg| 82 - 83 | 4
HSD| avg| 83 - 84 | 4
HSD| avg| 84 - 85 | 6
HSD| avg| 85 - 86 | 5
HSD| avg| 86 - 87 | 1
HSD| avg| 87 - 88 | 3
HSD| avg| 88 - 89 | 2
HSD| avg| 89 - 90 | 2
HSD| avg| 90 - 91 | 1
HSD| avg| 92 - 93 | 2
HSD| avg| 93 - 94 | 1
HSD| avg| 94 - 95 | 1
HSD| avg| 95 - 96 | 1
HSD| avg| 96 - 97 | 1
HSD| avg| 99 -100 | 1
HSD| avg| 110 -111 | 1
---|--param|----range-|--samples
HSD| max| 25 - 26 | 2
HSD| max| 26 - 27 | 1
HSD| max| 27 - 28 | 1
HSD| max| 29 - 30 | 4
HSD| max| 30 - 31 | 4
HSD| max| 31 - 32 | 7
HSD| max| 32 - 33 | 18
HSD| max| 33 - 34 | 18
HSD| max| 34 - 35 | 36
HSD| max| 35 - 36 | 59
HSD| max| 36 - 37 | 72
HSD| max| 37 - 38 | 42
HSD| max| 38 - 39 | 40
HSD| max| 39 - 40 | 20
HSD| max| 40 - 41 | 26
HSD| max| 41 - 42 | 27
HSD| max| 42 - 43 | 25
HSD| max| 43 - 44 | 18
HSD| max| 44 - 45 | 16
HSD| max| 45 - 46 | 8
HSD| max| 46 - 47 | 3
HSD| max| 47 - 48 | 3
HSD| max| 48 - 49 | 8
HSD| max| 49 - 50 | 2
HSD| max| 50 - 51 | 5
HSD| max| 51 - 52 | 4
HSD| max| 52 - 53 | 3
HSD| max| 53 - 54 | 2
HSD| max| 54 - 55 | 2
HSD| max| 55 - 56 | 2
HSD| max| 56 - 57 | 3
HSD| max| 57 - 58 | 4
HSD| max| 58 - 59 | 7
HSD| max| 59 - 60 | 4
HSD| max| 60 - 61 | 1
HSD| max| 61 - 62 | 4
HSD| max| 62 - 63 | 4
HSD| max| 69 - 70 | 2
HSD| max| 70 - 71 | 1
HSD| max| 71 - 72 | 3
HSD| max| 72 - 73 | 3
HSD| max| 73 - 74 | 3
HSD| max| 74 - 75 | 5
HSD| max| 75 - 76 | 4
HSD| max| 76 - 77 | 1
HSD| max| 77 - 78 | 2
HSD| max| 78 - 79 | 7
HSD| max| 80 - 81 | 2
HSD| max| 81 - 82 | 1
HSD| max| 82 - 83 | 4
HSD| max| 83 - 84 | 4
HSD| max| 84 - 85 | 6
HSD| max| 85 - 86 | 5
HSD| max| 86 - 87 | 1
HSD| max| 87 - 88 | 3
HSD| max| 88 - 89 | 2
HSD| max| 89 - 90 | 2
HSD| max| 90 - 91 | 1
HSD| max| 92 - 93 | 2
HSD| max| 93 - 94 | 1
HSD| max| 94 - 95 | 1
HSD| max| 95 - 96 | 1
HSD| max| 96 - 97 | 1
HSD| max| 99 -100 | 1
HSH|--param|--samples-|--average--|---stddev--
HSS| min| 574| 6.686| 0.740
HSS| avg| 3826285| 11.213| 6.706
HSS| max| 574| 44.190| 15.169
---|------------|------------|------------|--------|-------------------------
RTS| 3.480| 11.779| 99.163| 0| 14:23:01/14:23:01
It was run under calibrator load during more than 14 hours.
Now RTAI:
Oneshot timer with 500µs period, LATENCY =6000ns and SETUPTIME 1500
duration : 17h
1970/01/1 22:34:51
RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
RTD| 3221| 2577| 4997| 26095| 53801| 0
RTD| 3221| 2577| 5163| 25451| 53801| 0
RTD| 3221| 2577| 5159| 25128| 53801| 0
RTD| 3221| 2577| 4799| 23518| 53801| 0
RTD| 3221| 2577| 4828| 25128| 53801| 0
RTD| 3221| 2577| 5089| 23518| 53801| 0
RTD| 3221| 2577| 4580| 23840| 53801| 0
RTD| 3221| 2577| 4924| 25128| 53801| 0
RTD| 3221| 2577| 4740| 24806| 53801| 0
RTD| 3221| 2577| 4251| 25128| 53801| 0
counts | latency
144 2
15830672 3
31593380 4
15873143 5
9913892 6
5682938 7
3193742 8
2095821 9
2173270 10
2856232 11
3693369 12
3430282 13
3359902 14
2784427 15
809859 16
322901 17
224317 18
208420 19
411250 20
4054145 21
8386174 22
514707 23
261560 24
223286 25
187926 26
171329 27
233480 28
116408 29
47277 30
812908 31
2751429 32
38513 33
5668 34
2386 35
2249 36
1555 37
1130 38
416 39
217 40
148 41
134 42
183 43
118 44
167 45
227 46
151 47
95 48
26 49
8 50
6 51
7 52
6 53
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
France
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-09 17:19 [Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK Gregory CLEMENT
@ 2007-10-09 18:15 ` Jan Kiszka
[not found] ` <305035a40710091207j4038c62s5fb81903ce843910@domain.hid>
2007-10-09 19:56 ` [Xenomai-core] " Gilles Chanteperdrix
0 siblings, 2 replies; 13+ messages in thread
From: Jan Kiszka @ 2007-10-09 18:15 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: xenomai
Gregory CLEMENT wrote:
> Here, they are the last latency we get on AT91SAM9261-EK. As just now
> I haven't the board at home, I send the last result we stored. The
> prority of dbgu should be set to 6 instead of 7, but I can't assure
> it, for Xenomai.
Hmm, hardware interrupt priorities must not impact the worst-case
latency if I-pipe acks and mask them appropriately (the worst case is
when multiple interrupts happen in a row, not at the same time). But
this statement is not based on knowledge about potential pitfalls of
this arch. Are there specialities that require this tweaking?
> first Xenomai:
>
> #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko
> #cd /usr/xenomai/bin/
Which versions were you using for both tests? Do you still have the
involved .configs?
> #./latency -t 2 -p 150 -h -H 500
...
> ---|------------|------------|------------|--------|-------------------------
> RTS| 3.480| 11.779| 99.163| 0| 14:23:01/14:23:01
>
> It was run under calibrator load during more than 14 hours.
>
> Now RTAI:
>
> Oneshot timer with 500µs period, LATENCY =6000ns and SETUPTIME 1500
> duration : 17h
>
> 1970/01/1 22:34:51
> RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
> RTD| 3221| 2577| 4997| 26095| 53801| 0
> RTD| 3221| 2577| 5163| 25451| 53801| 0
> RTD| 3221| 2577| 5159| 25128| 53801| 0
> RTD| 3221| 2577| 4799| 23518| 53801| 0
> RTD| 3221| 2577| 4828| 25128| 53801| 0
> RTD| 3221| 2577| 5089| 23518| 53801| 0
> RTD| 3221| 2577| 4580| 23840| 53801| 0
> RTD| 3221| 2577| 4924| 25128| 53801| 0
> RTD| 3221| 2577| 4740| 24806| 53801| 0
> RTD| 3221| 2577| 4251| 25128| 53801| 0
Again, what would simplify the discussion enormously is a function
back-trace of the measured maximum latencies, just like "latency -f"
generates. The numbers will become worse, for sure, but we would gain a
very good overview about what is executed and what delayed which kernel.
If you see a chance to perform such a test and you need some hints on
the tracer setup (or did you use it before?), please let us know!
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
[not found] ` <305035a40710091207j4038c62s5fb81903ce843910@domain.hid>
@ 2007-10-09 19:07 ` Gregory CLEMENT
2007-10-09 19:45 ` Jan Kiszka
2007-10-09 20:02 ` Jan Kiszka
0 siblings, 2 replies; 13+ messages in thread
From: Gregory CLEMENT @ 2007-10-09 19:07 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 4139 bytes --]
---------- Forwarded message ----------
From: Gregory CLEMENT <gclement00@domain.hid>
Date: 9 oct. 2007 21:07
Subject: Re: [Xenomai-core] RTAI and Xenomai latency in kernel mode on
AT91SAM9261-EK
To: Jan Kiszka <jan.kiszka@domain.hid>
2007/10/9, Jan Kiszka <jan.kiszka@domain.hid>:
> Gregory CLEMENT wrote:
> > Here, they are the last latency we get on AT91SAM9261-EK. As just now
> > I haven't the board at home, I send the last result we stored. The
> > prority of dbgu should be set to 6 instead of 7, but I can't assure
> > it, for Xenomai.
>
> Hmm, hardware interrupt priorities must not impact the worst-case
> latency if I-pipe acks and mask them appropriately (the worst case is
> when multiple interrupts happen in a row, not at the same time). But
> this statement is not based on knowledge about potential pitfalls of
> this arch. Are there specialities that require this tweaking?
Indeed there was little impact on Xenomai, but a big impact in RTAI. I
believe that in RTAI (or at least in our RTAI port), there is longer
critical section than in Xenomai. We observe big latency when
calibrator was writing a lot of "\r" on serial line, that was causing
a lot of interrupts. I think that during a critical section (IT
disabled), we get an timer interrupt and a serial interrupt. As serial
interrupt has bigger priority it is treated first and as during an
interrupt serial driver can send or receive 256 character, it can add
a big delay.
>
> > first Xenomai:
> >
> > #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko
> > #cd /usr/xenomai/bin/
>
> Which versions were you using for both tests? Do you still have the
> involved .configs?
Both version are 2.6.20.13
I join the config files.
>
> > #./latency -t 2 -p 150 -h -H 500
> ...
> > ---|------------|------------|------------|--------|-------------------------
> > RTS| 3.480| 11.779| 99.163| 0| 14:23:01/14:23:01
> >
> > It was run under calibrator load during more than 14 hours.
> >
> > Now RTAI:
> >
> > Oneshot timer with 500µs period, LATENCY =6000ns and SETUPTIME 1500
> > duration : 17h
> >
> > 1970/01/1 22:34:51
> > RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
> > RTD| 3221| 2577| 4997| 26095| 53801| 0
> > RTD| 3221| 2577| 5163| 25451| 53801| 0
> > RTD| 3221| 2577| 5159| 25128| 53801| 0
> > RTD| 3221| 2577| 4799| 23518| 53801| 0
> > RTD| 3221| 2577| 4828| 25128| 53801| 0
> > RTD| 3221| 2577| 5089| 23518| 53801| 0
> > RTD| 3221| 2577| 4580| 23840| 53801| 0
> > RTD| 3221| 2577| 4924| 25128| 53801| 0
> > RTD| 3221| 2577| 4740| 24806| 53801| 0
> > RTD| 3221| 2577| 4251| 25128| 53801| 0
>
> Again, what would simplify the discussion enormously is a function
> back-trace of the measured maximum latencies, just like "latency -f"
> generates. The numbers will become worse, for sure, but we would gain a
> very good overview about what is executed and what delayed which kernel.
> If you see a chance to perform such a test and you need some hints on
> the tracer setup (or did you use it before?), please let us know!
OK for try it, at least for Xenomai as the function exists, but I
can't do it tonight and not this week in fact.
> Jan
>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
>
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
France
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
--
Gregory CLEMENT
Adeneo
Adetel Group
2, chemin du Ruisseau
69134 ECULLY - FRANCE
France
Tél. : +33 (0)4 72 18 08 40 - Fax : +33 (0)4 72 18 08 41
www.adetelgroup.com
[-- Attachment #2: config-RTAI --]
[-- Type: application/octet-stream, Size: 16265 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20.13
# Fri Aug 24 14:58:00 2007
#
CONFIG_ARM=y
# CONFIG_GENERIC_TIME is not set
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS 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_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
#
# System Type
#
# 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_AT91=y
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CO285 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_OMAP is not set
#
# Atmel AT91 System-on-Chip
#
# CONFIG_ARCH_AT91RM9200 is not set
# CONFIG_ARCH_AT91SAM9260 is not set
CONFIG_ARCH_AT91SAM9261=y
#
# AT91SAM9261 Board Type
#
CONFIG_MACH_AT91SAM9261EK=y
#
# Adeos I-pipe Options
#
CONFIG_IPIPE_AT91_TC=0
CONFIG_IPIPE_AT91_MCK=99328000
#
# AT91 Board Options
#
# CONFIG_MTD_AT91_DATAFLASH_CARD is not set
# CONFIG_MTD_NAND_AT91_BUSWIDTH_16 is not set
#
# AT91 Feature Selections
#
# CONFIG_AT91_PROGRAMMABLE_CLOCKS is not set
#
# Processor Type
#
CONFIG_CPU_32=y
CONFIG_CPU_ARM926T=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5TJ=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_COPY_V4WB=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_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
# CONFIG_CPU_CACHE_ROUND_ROBIN is not set
#
# Bus support
#
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# Kernel Features
#
CONFIG_IPIPE=y
# CONFIG_NO_IDLE_HZ is not set
CONFIG_HZ=100
# CONFIG_AEABI is not set
# CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4096
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_LEDS is not set
CONFIG_ALIGNMENT_TRAP=y
#
# Boot options
#
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE=""
# CONFIG_XIP_KERNEL is not set
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_VFP is not set
#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
# CONFIG_ARTHUR is not set
#
# Power management options
#
# CONFIG_PM is not set
# CONFIG_APM is not set
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE 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_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_FW_LOADER is not set
# CONFIG_SYS_HYPERVISOR is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=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
#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE 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_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# 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
#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_AT91=y
# CONFIG_MTD_NAND_NANDSIM is not set
#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
#
# Block devices
#
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_NETLINK is not set
#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
# CONFIG_ATA is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# I2O device support
#
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_SMC91X is not set
CONFIG_DM9000=y
#
# Ethernet (1000 Mbit)
#
#
# Ethernet (10000 Mbit)
#
#
# Token Ring devices
#
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_ATMEL=y
CONFIG_SERIAL_ATMEL_CONSOLE=y
# CONFIG_SERIAL_ATMEL_TTYAT is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
#
# TPM devices
#
#
# I2C support
#
# CONFIG_I2C is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Misc devices
#
#
# LED devices
#
# CONFIG_NEW_LEDS is not set
#
# LED drivers
#
#
# LED Triggers
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB is not set
#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# HID Devices
#
# CONFIG_HID is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# Real Time Clock
#
CONFIG_RTC_LIB=y
#
# 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_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_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS 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_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
#
# Miscellaneous filesystems
#
# CONFIG_HFSPLUS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_MUST_CHECK is not set
# CONFIG_MAGIC_SYSRQ 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_LOG_BUF_SHIFT=14
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_FRAME_POINTER=y
# CONFIG_DEBUG_USER is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_IOMAP_COPY=y
[-- Attachment #3: config-Xenomai --]
[-- Type: application/octet-stream, Size: 18318 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20.13
# Mon Jun 11 09:45:19 2007
#
CONFIG_ARM=y
# CONFIG_GENERIC_TIME is not set
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS 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_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_ISHIELD is not set
CONFIG_XENO_OPT_PRIOCPL=y
CONFIG_XENO_OPT_SECURITY_ACCESS=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=128
CONFIG_XENO_OPT_STATS=y
# CONFIG_XENO_OPT_DEBUG is not set
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
#
# Shared interrupts
#
# CONFIG_XENO_OPT_SHIRQ_LEVEL is not set
# CONFIG_XENO_OPT_SHIRQ_EDGE is not set
#
# Machine
#
# CONFIG_XENO_HW_FPU is not set
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
CONFIG_XENO_OPT_NATIVE_REGISTRY=y
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_OPT_DEBUG_NATIVE=y
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_SKIN_RTAI is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
#
# Drivers
#
#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set
#
# Testing drivers
#
# CONFIG_XENO_DRIVERS_TIMERBENCH is not set
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
# CONFIG_XENO_DRIVERS_SWITCHTEST is not set
#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set
#
# System Type
#
# 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_AT91=y
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CO285 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_OMAP is not set
#
# Atmel AT91 System-on-Chip
#
# CONFIG_ARCH_AT91RM9200 is not set
# CONFIG_ARCH_AT91SAM9260 is not set
CONFIG_ARCH_AT91SAM9261=y
#
# AT91SAM9261 Board Type
#
CONFIG_MACH_AT91SAM9261EK=y
#
# Adeos I-pipe Options
#
CONFIG_IPIPE_AT91_TC=0
CONFIG_IPIPE_AT91_MCK=99328000
#
# AT91 Board Options
#
# CONFIG_MTD_AT91_DATAFLASH_CARD is not set
CONFIG_MTD_NAND_AT91_BUSWIDTH_16=y
#
# AT91 Feature Selections
#
# CONFIG_AT91_PROGRAMMABLE_CLOCKS is not set
#
# Processor Type
#
CONFIG_CPU_32=y
CONFIG_CPU_ARM926T=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5TJ=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_COPY_V4WB=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_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
# CONFIG_CPU_CACHE_ROUND_ROBIN is not set
#
# Bus support
#
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# Kernel Features
#
CONFIG_IPIPE=y
# CONFIG_NO_IDLE_HZ is not set
CONFIG_HZ=100
# CONFIG_AEABI is not set
# CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4096
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_LEDS is not set
CONFIG_ALIGNMENT_TRAP=y
#
# Boot options
#
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE=""
# CONFIG_XIP_KERNEL is not set
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_VFP is not set
#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
# CONFIG_ARTHUR is not set
#
# Power management options
#
# CONFIG_PM is not set
# CONFIG_APM is not set
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE 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_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
# CONFIG_FW_LOADER is not set
# CONFIG_SYS_HYPERVISOR is not set
#
# Connector - unified userspace <-> kernelspace linker
#
# CONFIG_CONNECTOR is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=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
#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE 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_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# 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
#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_AT91=y
# CONFIG_MTD_NAND_NANDSIM is not set
#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
#
# Block devices
#
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
# CONFIG_SCSI_NETLINK is not set
#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
# CONFIG_ATA is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# I2O device support
#
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_SMC91X is not set
CONFIG_DM9000=y
#
# Ethernet (1000 Mbit)
#
#
# Ethernet (10000 Mbit)
#
#
# Token Ring devices
#
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_ATMEL=y
CONFIG_SERIAL_ATMEL_CONSOLE=y
# CONFIG_SERIAL_ATMEL_TTYAT is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
#
# TPM devices
#
#
# I2C support
#
# CONFIG_I2C is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Misc devices
#
#
# LED devices
#
# CONFIG_NEW_LEDS is not set
#
# LED drivers
#
#
# LED Triggers
#
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
#
# Graphics support
#
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB is not set
#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# HID Devices
#
# CONFIG_HID is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# Real Time Clock
#
CONFIG_RTC_LIB=y
#
# 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_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_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS 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_SYSFS=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
#
# Miscellaneous filesystems
#
# CONFIG_HFSPLUS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_MUST_CHECK is not set
# CONFIG_MAGIC_SYSRQ 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_LOG_BUF_SHIFT=14
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_FRAME_POINTER=y
# CONFIG_DEBUG_USER is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_IOMAP_COPY=y
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-09 19:07 ` [Xenomai-core] Fwd: " Gregory CLEMENT
@ 2007-10-09 19:45 ` Jan Kiszka
2007-10-09 21:58 ` Gilles Chanteperdrix
2007-10-09 20:02 ` Jan Kiszka
1 sibling, 1 reply; 13+ messages in thread
From: Jan Kiszka @ 2007-10-09 19:45 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 5141 bytes --]
Gregory CLEMENT wrote:
> ---------- Forwarded message ----------
> From: Gregory CLEMENT <gclement00@domain.hid>
> Date: 9 oct. 2007 21:07
> Subject: Re: [Xenomai-core] RTAI and Xenomai latency in kernel mode on
> AT91SAM9261-EK
> To: Jan Kiszka <jan.kiszka@domain.hid>
>
>
> 2007/10/9, Jan Kiszka <jan.kiszka@domain.hid>:
>> Gregory CLEMENT wrote:
>>> Here, they are the last latency we get on AT91SAM9261-EK. As just now
>>> I haven't the board at home, I send the last result we stored. The
>>> prority of dbgu should be set to 6 instead of 7, but I can't assure
>>> it, for Xenomai.
>> Hmm, hardware interrupt priorities must not impact the worst-case
>> latency if I-pipe acks and mask them appropriately (the worst case is
>> when multiple interrupts happen in a row, not at the same time). But
>> this statement is not based on knowledge about potential pitfalls of
>> this arch. Are there specialities that require this tweaking?
>
> Indeed there was little impact on Xenomai, but a big impact in RTAI. I
> believe that in RTAI (or at least in our RTAI port), there is longer
> critical section than in Xenomai. We observe big latency when
> calibrator was writing a lot of "\r" on serial line, that was causing
> a lot of interrupts. I think that during a critical section (IT
> disabled), we get an timer interrupt and a serial interrupt. As serial
> interrupt has bigger priority it is treated first and as during an
> interrupt serial driver can send or receive 256 character, it can add
> a big delay.
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 rather has to log,
acknowledge, and possibly mask that line quickly so that RT IRQs can be
delivered again.
We just revealed a similar problem over i386 about fasteoi-type IRQs.
What type of IRQs are involved here? Maybe it's the same bug.
>>> first Xenomai:
>>>
>>> #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko
>>> #cd /usr/xenomai/bin/
>> Which versions were you using for both tests? Do you still have the
>> involved .configs?
>
> Both version are 2.6.20.13
> I join the config files.
Hmm, I wonder why we have this difference in the configs:
# diff -u config-RTAI config-Xenomai
[...]
@@ -147,7 +243,7 @@
# AT91 Board Options
#
# CONFIG_MTD_AT91_DATAFLASH_CARD is not set
-# CONFIG_MTD_NAND_AT91_BUSWIDTH_16 is not set
+CONFIG_MTD_NAND_AT91_BUSWIDTH_16=y
#
# AT91 Feature Selections
Can accessing the flash delay interrupts significantly, and may this
switch here have impact on the delay? Sorry for potential stupid
questions, I'm not familiar with this arch yet.
>>> #./latency -t 2 -p 150 -h -H 500
>> ...
>>> ---|------------|------------|------------|--------|-------------------------
>>> RTS| 3.480| 11.779| 99.163| 0| 14:23:01/14:23:01
>>>
>>> It was run under calibrator load during more than 14 hours.
>>>
>>> Now RTAI:
>>>
>>> Oneshot timer with 500µs period, LATENCY =6000ns and SETUPTIME 1500
>>> duration : 17h
>>>
>>> 1970/01/1 22:34:51
>>> RTH| lat min| ovl min| lat avg| lat max| ovl max| overruns
>>> RTD| 3221| 2577| 4997| 26095| 53801| 0
>>> RTD| 3221| 2577| 5163| 25451| 53801| 0
>>> RTD| 3221| 2577| 5159| 25128| 53801| 0
>>> RTD| 3221| 2577| 4799| 23518| 53801| 0
>>> RTD| 3221| 2577| 4828| 25128| 53801| 0
>>> RTD| 3221| 2577| 5089| 23518| 53801| 0
>>> RTD| 3221| 2577| 4580| 23840| 53801| 0
>>> RTD| 3221| 2577| 4924| 25128| 53801| 0
>>> RTD| 3221| 2577| 4740| 24806| 53801| 0
>>> RTD| 3221| 2577| 4251| 25128| 53801| 0
>> Again, what would simplify the discussion enormously is a function
>> back-trace of the measured maximum latencies, just like "latency -f"
>> generates. The numbers will become worse, for sure, but we would gain a
>> very good overview about what is executed and what delayed which kernel.
>> If you see a chance to perform such a test and you need some hints on
>> the tracer setup (or did you use it before?), please let us know!
>
> OK for try it, at least for Xenomai as the function exists, but I
> can't do it tonight and not this week in fact.
Thanks advance! BTW, you don't need to apply black magic in order to
instrument RTAI: As you measure in the kernel anyway, you just need to
add an ipipe_trace_freeze(<measured_latency>) at the point where a new
maximum latency is detected in RTAI's benchmark module. In theory, the
tracer should also work over RTAI out-of-the-box (but I'm not aware of
anyone actually using it there). More info on the tracer can be found in
the Xenomai wiki, BTW.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-09 18:15 ` Jan Kiszka
[not found] ` <305035a40710091207j4038c62s5fb81903ce843910@domain.hid>
@ 2007-10-09 19:56 ` Gilles Chanteperdrix
1 sibling, 0 replies; 13+ messages in thread
From: Gilles Chanteperdrix @ 2007-10-09 19:56 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
Jan Kiszka wrote:
> Gregory CLEMENT wrote:
> > Here, they are the last latency we get on AT91SAM9261-EK. As just now
> > I haven't the board at home, I send the last result we stored. The
> > prority of dbgu should be set to 6 instead of 7, but I can't assure
> > it, for Xenomai.
>
> Hmm, hardware interrupt priorities must not impact the worst-case
> latency if I-pipe acks and mask them appropriately (the worst case is
> when multiple interrupts happen in a row, not at the same time). But
> this statement is not based on knowledge about potential pitfalls of
> this arch. Are there specialities that require this tweaking?
During the port to AT91RM9200, I observed that under ping flood, the
ethernet driver interrupt was delaying the timer interrupt for unbounded
period of times, this because it had a higher priority. Changing the
interrupt priorities solved the issue. That said, I understand what you
mean, the interrupt should be masked when acked and should no longer
bother us until the I-pipe gives control to Linux to handle it.
>
> > first Xenomai:
> >
> > #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko
> > #cd /usr/xenomai/bin/
>
> Which versions were you using for both tests? Do you still have the
> involved .configs?
>
> > #./latency -t 2 -p 150 -h -H 500
Why not -p 500 ? Since RTAI was tested with a 500 us period, the same
period should be use for Xenomai. I do not think this will change
anything, but who knows.
--
Gilles Chanteperdrix.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-09 19:07 ` [Xenomai-core] Fwd: " Gregory CLEMENT
2007-10-09 19:45 ` Jan Kiszka
@ 2007-10-09 20:02 ` Jan Kiszka
1 sibling, 0 replies; 13+ messages in thread
From: Jan Kiszka @ 2007-10-09 20:02 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
Gregory CLEMENT wrote:
>>> first Xenomai:
>>>
>>> #insmod /lib/modules/2.6.20.13/kernel/drivers/xenomai/testing/xeno_timerbench.ko
>>> #cd /usr/xenomai/bin/
>> Which versions were you using for both tests? Do you still have the
>> involved .configs?
>
> Both version are 2.6.20.13
> I join the config files.
BTW, the attached Xenomai config is obviously not the one that was used
for the test:
#
# Testing drivers
#
# CONFIG_XENO_DRIVERS_TIMERBENCH is not set
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-09 19:45 ` Jan Kiszka
@ 2007-10-09 21:58 ` Gilles Chanteperdrix
2007-10-10 6:12 ` Jan Kiszka
0 siblings, 1 reply; 13+ messages in thread
From: Gilles Chanteperdrix @ 2007-10-09 21:58 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
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 rather has to log,
> acknowledge, and possibly mask that line quickly so that RT IRQs can be
> delivered again.
Thinking a bit more about my ethernet vs timer issue. If, when an
ethernet interrupt is pending, adeos is not aware that there is also a
timer interrupt pending, it will call the ethernet interrupt handler
immediately then unmask the interrupt. So, Adeos will never have a
chance to handle the timer interrupt before another ethernet interrupt
is handled. Ergo, giving the timer interrupt the highest priority is
what must be done.
--
Gilles Chanteperdrix.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-09 21:58 ` Gilles Chanteperdrix
@ 2007-10-10 6:12 ` Jan Kiszka
2007-10-10 8:45 ` Philippe Gerum
0 siblings, 1 reply; 13+ messages in thread
From: Jan Kiszka @ 2007-10-10 6:12 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
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 rather has to log,
> > acknowledge, and possibly mask that line quickly so that RT IRQs can be
> > delivered again.
>
> Thinking a bit more about my ethernet vs timer issue. If, when an
> ethernet interrupt is pending, adeos is not aware that there is also a
> timer interrupt pending, it will call the ethernet interrupt handler
> immediately then unmask the interrupt. So, Adeos will never have a
> chance to handle the timer interrupt before another ethernet interrupt
> is handled. Ergo, giving the timer interrupt the highest priority is
> what must be done.
No. Adeos will first start to dispatch the Ethernet IRQ. It will
ack&mask it and then re-enable the IRQ delivery before calling into the
handler. At this point the hardware can report the timer IRQ, and Adeos
will immediately start to deliver that one instead.
With IRQ hardware priorities, you only optimise the case when both
interrupts are pending in the hardware at the same time. The worst-case
remains that the Ethernet IRQ comes first, Adeos starts to handle it,
and _then_ the timer IRQ arrives. This is something the hardware can in
no way avoid (without looking into the future...).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-10 6:12 ` Jan Kiszka
@ 2007-10-10 8:45 ` Philippe Gerum
2007-10-10 8:54 ` Gilles Chanteperdrix
0 siblings, 1 reply; 13+ messages in thread
From: Philippe Gerum @ 2007-10-10 8:45 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
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 rather has to log,
> > > acknowledge, and possibly mask that line quickly so that RT IRQs can be
> > > delivered again.
> >
> > Thinking a bit more about my ethernet vs timer issue. If, when an
> > ethernet interrupt is pending, adeos is not aware that there is also a
> > timer interrupt pending, it will call the ethernet interrupt handler
> > immediately then unmask the interrupt. So, Adeos will never have a
> > chance to handle the timer interrupt before another ethernet interrupt
> > is handled. Ergo, giving the timer interrupt the highest priority is
> > what must be done.
>
> No. Adeos will first start to dispatch the Ethernet IRQ. It will
> ack&mask it and then re-enable the IRQ delivery before calling into the
> handler.
Only if the ethernet interrupt is not a real-time event.
> At this point the hardware can report the timer IRQ, and Adeos
> will immediately start to deliver that one instead.
>
> With IRQ hardware priorities, you only optimise the case when both
> interrupts are pending in the hardware at the same time. The worst-case
> remains that the Ethernet IRQ comes first, Adeos starts to handle it,
> and _then_ the timer IRQ arrives. This is something the hardware can in
> no way avoid (without looking into the future...).
>
When the processor has a notion of internal priority level which it does
inherit from the level of the event it currently processes, the above
assumption is wrong. In such a case, the next interrupt to be serviced
would be equivalent to pending_IRQ_mask & CPU_interrupt_mask &
processor_level, i.e. multiple high priority interrupts would be
processed before a low priority one is eventually triggered. So in that
case, Gilles's assertion does make a lot of sense.
> Jan
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-10 8:45 ` Philippe Gerum
@ 2007-10-10 8:54 ` Gilles Chanteperdrix
2007-10-10 9:28 ` Philippe Gerum
0 siblings, 1 reply; 13+ messages in thread
From: Gilles Chanteperdrix @ 2007-10-10 8:54 UTC (permalink / raw)
To: rpm; +Cc: Jan Kiszka, xenomai
On 10/10/07, Philippe Gerum <rpm@xenomai.org> wrote:
> 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 rather has to log,
> > > > acknowledge, and possibly mask that line quickly so that RT IRQs can be
> > > > delivered again.
> > >
> > > Thinking a bit more about my ethernet vs timer issue. If, when an
> > > ethernet interrupt is pending, adeos is not aware that there is also a
> > > timer interrupt pending, it will call the ethernet interrupt handler
> > > immediately then unmask the interrupt. So, Adeos will never have a
> > > chance to handle the timer interrupt before another ethernet interrupt
> > > is handled. Ergo, giving the timer interrupt the highest priority is
> > > what must be done.
> >
> > No. Adeos will first start to dispatch the Ethernet IRQ. It will
> > ack&mask it and then re-enable the IRQ delivery before calling into the
> > handler.
>
> Only if the ethernet interrupt is not a real-time event.
>
> > At this point the hardware can report the timer IRQ, and Adeos
> > will immediately start to deliver that one instead.
> >
> > With IRQ hardware priorities, you only optimise the case when both
> > interrupts are pending in the hardware at the same time. The worst-case
> > remains that the Ethernet IRQ comes first, Adeos starts to handle it,
> > and _then_ the timer IRQ arrives. This is something the hardware can in
> > no way avoid (without looking into the future...).
> >
>
> When the processor has a notion of internal priority level which it does
> inherit from the level of the event it currently processes, the above
> assumption is wrong. In such a case, the next interrupt to be serviced
> would be equivalent to pending_IRQ_mask & CPU_interrupt_mask &
> processor_level, i.e. multiple high priority interrupts would be
> processed before a low priority one is eventually triggered. So in that
> case, Gilles's assertion does make a lot of sense.
The AT91 interrupts need an EOI, I wonder if we are not simply doing
the EOI too late. That is, the EOI should be done when the interrupt
has been acked, before it is handled, so that other interrupts can be
delivered.
--
Gilles Chanteperdrix
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-10 8:54 ` Gilles Chanteperdrix
@ 2007-10-10 9:28 ` Philippe Gerum
2007-10-10 9:36 ` Gilles Chanteperdrix
0 siblings, 1 reply; 13+ messages in thread
From: Philippe Gerum @ 2007-10-10 9:28 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Jan Kiszka, xenomai
On Wed, 2007-10-10 at 10:54 +0200, Gilles Chanteperdrix wrote:
> On 10/10/07, Philippe Gerum <rpm@xenomai.org> wrote:
> > 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 rather has to log,
> > > > > acknowledge, and possibly mask that line quickly so that RT IRQs can be
> > > > > delivered again.
> > > >
> > > > Thinking a bit more about my ethernet vs timer issue. If, when an
> > > > ethernet interrupt is pending, adeos is not aware that there is also a
> > > > timer interrupt pending, it will call the ethernet interrupt handler
> > > > immediately then unmask the interrupt. So, Adeos will never have a
> > > > chance to handle the timer interrupt before another ethernet interrupt
> > > > is handled. Ergo, giving the timer interrupt the highest priority is
> > > > what must be done.
> > >
> > > No. Adeos will first start to dispatch the Ethernet IRQ. It will
> > > ack&mask it and then re-enable the IRQ delivery before calling into the
> > > handler.
> >
> > Only if the ethernet interrupt is not a real-time event.
> >
> > > At this point the hardware can report the timer IRQ, and Adeos
> > > will immediately start to deliver that one instead.
> > >
> > > With IRQ hardware priorities, you only optimise the case when both
> > > interrupts are pending in the hardware at the same time. The worst-case
> > > remains that the Ethernet IRQ comes first, Adeos starts to handle it,
> > > and _then_ the timer IRQ arrives. This is something the hardware can in
> > > no way avoid (without looking into the future...).
> > >
> >
> > When the processor has a notion of internal priority level which it does
> > inherit from the level of the event it currently processes, the above
> > assumption is wrong. In such a case, the next interrupt to be serviced
> > would be equivalent to pending_IRQ_mask & CPU_interrupt_mask &
> > processor_level, i.e. multiple high priority interrupts would be
> > processed before a low priority one is eventually triggered. So in that
> > case, Gilles's assertion does make a lot of sense.
>
> The AT91 interrupts need an EOI, I wonder if we are not simply doing
> the EOI too late. That is, the EOI should be done when the interrupt
> has been acked, before it is handled, so that other interrupts can be
> delivered.
>
The EOI would lower the priority barrier for interrupts, so this makes
sense.
Looking at the I-pipe code for AT91RM9200 for instance, I only see the
AIC being asked to mask the IRQ source as a result of the fast I-pipe
acknowledge being called, nothing more. If the AIC needs explicit EOI to
lower the priority level which is not covered by the previous action,
then it's indeed missing.
The latest fix regarding the fasteoi interrupt flow would not have any
impact, since AFAICS, we are solely dealing with level interrupts here.
--
Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-10 9:28 ` Philippe Gerum
@ 2007-10-10 9:36 ` Gilles Chanteperdrix
2007-10-10 9:54 ` Philippe Gerum
0 siblings, 1 reply; 13+ messages in thread
From: Gilles Chanteperdrix @ 2007-10-10 9:36 UTC (permalink / raw)
To: rpm; +Cc: Jan Kiszka, xenomai
On 10/10/07, Philippe Gerum <rpm@xenomai.org> wrote:
> On Wed, 2007-10-10 at 10:54 +0200, Gilles Chanteperdrix wrote:
> > On 10/10/07, Philippe Gerum <rpm@xenomai.org> wrote:
> > > 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 rather has to log,
> > > > > > acknowledge, and possibly mask that line quickly so that RT IRQs can be
> > > > > > delivered again.
> > > > >
> > > > > Thinking a bit more about my ethernet vs timer issue. If, when an
> > > > > ethernet interrupt is pending, adeos is not aware that there is also a
> > > > > timer interrupt pending, it will call the ethernet interrupt handler
> > > > > immediately then unmask the interrupt. So, Adeos will never have a
> > > > > chance to handle the timer interrupt before another ethernet interrupt
> > > > > is handled. Ergo, giving the timer interrupt the highest priority is
> > > > > what must be done.
> > > >
> > > > No. Adeos will first start to dispatch the Ethernet IRQ. It will
> > > > ack&mask it and then re-enable the IRQ delivery before calling into the
> > > > handler.
> > >
> > > Only if the ethernet interrupt is not a real-time event.
> > >
> > > > At this point the hardware can report the timer IRQ, and Adeos
> > > > will immediately start to deliver that one instead.
> > > >
> > > > With IRQ hardware priorities, you only optimise the case when both
> > > > interrupts are pending in the hardware at the same time. The worst-case
> > > > remains that the Ethernet IRQ comes first, Adeos starts to handle it,
> > > > and _then_ the timer IRQ arrives. This is something the hardware can in
> > > > no way avoid (without looking into the future...).
> > > >
> > >
> > > When the processor has a notion of internal priority level which it does
> > > inherit from the level of the event it currently processes, the above
> > > assumption is wrong. In such a case, the next interrupt to be serviced
> > > would be equivalent to pending_IRQ_mask & CPU_interrupt_mask &
> > > processor_level, i.e. multiple high priority interrupts would be
> > > processed before a low priority one is eventually triggered. So in that
> > > case, Gilles's assertion does make a lot of sense.
> >
> > The AT91 interrupts need an EOI, I wonder if we are not simply doing
> > the EOI too late. That is, the EOI should be done when the interrupt
> > has been acked, before it is handled, so that other interrupts can be
> > delivered.
> >
>
> The EOI would lower the priority barrier for interrupts, so this makes
> sense.
>
> Looking at the I-pipe code for AT91RM9200 for instance, I only see the
> AIC being asked to mask the IRQ source as a result of the fast I-pipe
> acknowledge being called, nothing more. If the AIC needs explicit EOI to
> lower the priority level which is not covered by the previous action,
> then it's indeed missing.
>
> The latest fix regarding the fasteoi interrupt flow would not have any
> impact, since AFAICS, we are solely dealing with level interrupts here.
The EOI is done by the irq_finish macro, which is called after ipipe_handle_irq.
--
Gilles Chanteperdrix
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-core] Fwd: RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK
2007-10-10 9:36 ` Gilles Chanteperdrix
@ 2007-10-10 9:54 ` Philippe Gerum
0 siblings, 0 replies; 13+ messages in thread
From: Philippe Gerum @ 2007-10-10 9:54 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Jan Kiszka, xenomai
On Wed, 2007-10-10 at 11:36 +0200, Gilles Chanteperdrix wrote:
> On 10/10/07, Philippe Gerum <rpm@xenomai.org> wrote:
> > On Wed, 2007-10-10 at 10:54 +0200, Gilles Chanteperdrix wrote:
> > > On 10/10/07, Philippe Gerum <rpm@xenomai.org> wrote:
> > > > 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 rather has to log,
> > > > > > > acknowledge, and possibly mask that line quickly so that RT IRQs can be
> > > > > > > delivered again.
> > > > > >
> > > > > > Thinking a bit more about my ethernet vs timer issue. If, when an
> > > > > > ethernet interrupt is pending, adeos is not aware that there is also a
> > > > > > timer interrupt pending, it will call the ethernet interrupt handler
> > > > > > immediately then unmask the interrupt. So, Adeos will never have a
> > > > > > chance to handle the timer interrupt before another ethernet interrupt
> > > > > > is handled. Ergo, giving the timer interrupt the highest priority is
> > > > > > what must be done.
> > > > >
> > > > > No. Adeos will first start to dispatch the Ethernet IRQ. It will
> > > > > ack&mask it and then re-enable the IRQ delivery before calling into the
> > > > > handler.
> > > >
> > > > Only if the ethernet interrupt is not a real-time event.
> > > >
> > > > > At this point the hardware can report the timer IRQ, and Adeos
> > > > > will immediately start to deliver that one instead.
> > > > >
> > > > > With IRQ hardware priorities, you only optimise the case when both
> > > > > interrupts are pending in the hardware at the same time. The worst-case
> > > > > remains that the Ethernet IRQ comes first, Adeos starts to handle it,
> > > > > and _then_ the timer IRQ arrives. This is something the hardware can in
> > > > > no way avoid (without looking into the future...).
> > > > >
> > > >
> > > > When the processor has a notion of internal priority level which it does
> > > > inherit from the level of the event it currently processes, the above
> > > > assumption is wrong. In such a case, the next interrupt to be serviced
> > > > would be equivalent to pending_IRQ_mask & CPU_interrupt_mask &
> > > > processor_level, i.e. multiple high priority interrupts would be
> > > > processed before a low priority one is eventually triggered. So in that
> > > > case, Gilles's assertion does make a lot of sense.
> > >
> > > The AT91 interrupts need an EOI, I wonder if we are not simply doing
> > > the EOI too late. That is, the EOI should be done when the interrupt
> > > has been acked, before it is handled, so that other interrupts can be
> > > delivered.
> > >
> >
> > The EOI would lower the priority barrier for interrupts, so this makes
> > sense.
> >
> > Looking at the I-pipe code for AT91RM9200 for instance, I only see the
> > AIC being asked to mask the IRQ source as a result of the fast I-pipe
> > acknowledge being called, nothing more. If the AIC needs explicit EOI to
> > lower the priority level which is not covered by the previous action,
> > then it's indeed missing.
> >
> > The latest fix regarding the fasteoi interrupt flow would not have any
> > impact, since AFAICS, we are solely dealing with level interrupts here.
>
> The EOI is done by the irq_finish macro, which is called after ipipe_handle_irq.
>
So you are definitely right. irq_finish must be done before the
interrupt is pipelined, right after it has been masked in the fast ack
handler.
--
Philippe.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-10-10 9:54 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-09 17:19 [Xenomai-core] RTAI and Xenomai latency in kernel mode on AT91SAM9261-EK Gregory CLEMENT
2007-10-09 18:15 ` Jan Kiszka
[not found] ` <305035a40710091207j4038c62s5fb81903ce843910@domain.hid>
2007-10-09 19:07 ` [Xenomai-core] Fwd: " Gregory CLEMENT
2007-10-09 19:45 ` Jan Kiszka
2007-10-09 21:58 ` Gilles Chanteperdrix
2007-10-10 6:12 ` Jan Kiszka
2007-10-10 8:45 ` Philippe Gerum
2007-10-10 8:54 ` Gilles Chanteperdrix
2007-10-10 9:28 ` Philippe Gerum
2007-10-10 9:36 ` Gilles Chanteperdrix
2007-10-10 9:54 ` Philippe Gerum
2007-10-09 20:02 ` Jan Kiszka
2007-10-09 19:56 ` [Xenomai-core] " Gilles Chanteperdrix
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.