[Xenomai-help] Adeos/Xenomai Arm Port

[Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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

Hi!

I've tried to implement Adeos 1.5 and Xenomai 2.2.3 on a
Netsilicon-Platform (ns9750-evalboard with Arm926EJ).

The Timer is implemented (with a manual __ipipe_trigger_irq if
reload<3). The Interrupt-Demuxer is deactivated.

The System boots with Adeos & Xenomai. Time is running normally. Things
look generally very good, but there are some Problems:


1. Latencies are very high.

dd if=/dev/zero of=/dev/null &
./latency -p 10000 -T 20

RTS|      92.592|      95.486|     125.506|       0|
00:00:20/00:00:20

I know, it's a common problem with Xenomai/ARM. Is it true, that it has
something to do with a slow processor-cache-flush? Does anybody know
more about that?


2. I've to use very high Periods on Latency-Tests.

With load i've to use > 500 us
Without load i've to use > 1000 us (!?!)

If I run ./latency -p 1000 without any load I get latencies between 40
and 70 us, but the Process is killed after a few seconds. 
 - sometimes simply the message "Killed" is printed. 
	In this case the system is running, but if i try to start another
latency-Process the system crashes (most of time: "Unable to handle
kernel paging request at virtual address xxxxxxxx".)
 - sometimes the system simply stands still (linux-timerisr /
linux-timer_tick is'nt called anymore)
	jtag-debugger gdb-output:

	Program received signal SIGSTOP, Stopped (signal).
	0x0000ba40 in ?? ()
	(gdb) stepi
	0x0000ba40 in ?? ()
	Infinite loop detected

The same happens if I run ./latency -p 500 with load.



3. in-kernel periodic task & in-kernel timer benchmark 

-sh-3.00# ./latency -t 2 -T 10
== Sampling period: 100 us
== Test mode: in-kernel timer handler
== All results in microseconds
latency: failed to start in-kernel timer benchmark, code -25
---|------------|------------|------------|--------|-------------------------
RTS|-1093001.752|       0.001|      93.252|   93340|
00:00:10/00:00:10

-sh-3.00# ./latency -t 1 -T 10
== Sampling period: 100 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to start in-kernel timer benchmark, code -25
---|------------|------------|------------|--------|-------------------------
RTS|-1097339.416|       0.001|      93.252|   93340|
00:00:10/00:00:10

What does "latency: failed to start in-kernel timer benchmark, code -25"
mean? Are the results valid?


4. switchtest & switchbench

-sh-3.00# ./switchtest       
== Testing FPU check routines...
== FPU check routines: unimplemented, skipping FPU switches tests.
== Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7
rtuo-8
RTT|  00:00:01
RTH|ctx switches|-------total
RTD|         450|         450
RTD|         450|         900
RTD|         459|        1359
RTD|         450|        1809
RTD|         459|        2268
RTD|         459|        2727
RTD|         450|        3177
switchtest seems to run normally, but what does the output mean?


The problems with switchbench are similar to the Problems discussed in
#2. 
-sh-3.00# ./switchbench -n 100 -p 10000
== Sampling period: 10000 us
== Do not interrupt this program
RTH|     lat min|     lat avg|     lat max|        lost
RTD|       86443|       90060|      101634|           0
-sh-3.00# ./switchbench -n 100 -p 1000 
== Sampling period: 1000 us
== Do not interrupt this program
RTH|     lat min|     lat avg|     lat max|        lost
RTD|       77039|       81741|       98741|           0
-sh-3.00# ./switchbench -n 100 -p 100 
== Sampling period: 100 us
== Do not interrupt this program
[  122.670000] Unable to handle kernel paging request at virtual address
e2822059
[  122.670000] pgd = c3b60000
[  122.670000] [e2822059] *pgd=00000000
[  122.670000] Internal error: Oops: 805 [#1]
[  122.670000] Modules linked in:
[  122.670000] CPU: 0
[  122.670000] pc : [<c0150930>]    lr : [<c015080c>]    Not tainted
[  122.670000] sp : c39d0014  ip : c3b54044  fp : c39d0040
[  122.670000] r10: c02d43e4  r9 : 00800000  r8 : c0322b2c
[  122.670000] r7 : c032212c  r6 : 00000000  r5 : c01194e0  r4 :
00000000
[  122.670000] r3 : 00000000  r2 : e282200c  r1 : c3b54000  r0 :
c3b54000
[  122.670000] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  Segment user
[  122.670000] Control: 5317F  Table: 03B60000  DAC: 00000015
[  122.670000] Process worker (pid: 131, stack limit = 0xc39ce194)
[  122.670000] Stack: (0xc39d0014 to 0xc39d0000)
[  122.670000] Backtrace: 
[  122.670000] Function entered at [<c01502e8>] from [<c014d25c>]
[  122.670000] Function entered at [<c014d1c4>] from [<c014d2a4>]
[  122.670000]  r7 = 00000000  r6 = C02D2680  r5 = C02D2880  r4 =
C02D2688
[  122.670000] Function entered at [<c014d288>] from [<c014a350>]
[  122.670000] Function entered at [<c014a1e8>] from [<c014a7a4>]
[  122.670000] Function entered at [<c014a700>] from [<c0126000>]
[  122.670000]  r7 = C02D2680  r6 = C02D2880  r5 = 00000010  r4 =
C02D2680
[  122.670000] Function entered at [<c0125e64>] from [<c01260a8>]
[  122.670000] Function entered at [<c0126010>] from [<c011f824>]
[  122.670000] Code: e3c3303f e593300c e5932004 e3a03001 (e5c2304d) 



5. cyclictest

Here some test-cases:

-sh-3.00# ./cyclictest -l 100
0.03 0.01 0.00 1/21 53          

T: 0 (   53) P: 0 I:    1000 C:     100 Min:-1087273 Act:-1087273 Max:
-989708
-sh-3.00# ./cyclictest -l 1000
0.02 0.01 0.00 2/22 56          

T: 0 (   56) P: 0 I:    1000 C:    1000 Min:-1973899 Act:-1973899 Max:
-989170
-sh-3.00# ./cyclictest -l 10000
0.01 0.01 0.00 1/21 59          

T: 0 (   59) P: 0 I:    1000 C:   10000 Min:-10848662 Act:-10848662 Max:
-992290
-sh-3.00# ./cyclictest -l 100000
0.01 0.00 0.00 2/22 62          

T: 0 (   62) P: 0 I:    1000 C:  100000 Min:-99563368 Act:-99563368 Max:
-989732
-sh-3.00# ./cyclictest -l 1000000
0.98 0.22 0.07 3/22 65          

T: 0 (   65) P: 0 I:    1000 C: 1000000 Min:-986731091 Act:-986731091
Max: -989084

cyclic-Test runs, but while it is running, timer_tick is never called.




I think that all above problems depends on the same root. I tried to
find that root, but currently without success. 


Thanks in advance
	Manfred Schlaegl

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Jan Kiszka]

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

Schlägl Manfred jun. wrote:
> Hi!
> 
> I've tried to implement Adeos 1.5 and Xenomai 2.2.3 on a
> Netsilicon-Platform (ns9750-evalboard with Arm926EJ).
> 
> The Timer is implemented (with a manual __ipipe_trigger_irq if
> reload<3). The Interrupt-Demuxer is deactivated.
> 
> The System boots with Adeos & Xenomai. Time is running normally. Things

Cool. Contributing patches is always welcome. ;)

> look generally very good, but there are some Problems:
> 
> 
> 1. Latencies are very high.
> 
> dd if=/dev/zero of=/dev/null &
> ./latency -p 10000 -T 20
> 
> RTS|      92.592|      95.486|     125.506|       0|
> 00:00:20/00:00:20
> 
> I know, it's a common problem with Xenomai/ARM. Is it true, that it has
> something to do with a slow processor-cache-flush? Does anybody know
> more about that?
> 

AFAIK, this is a generic ARM problem. You have to flush caches on MMU
context switch, i.e. also when waking up this real-time user-space
benchmark task. That's due to the fact that ARM is caching virtual
address, so that the cache content become invalid on context switch.

> 
> 2. I've to use very high Periods on Latency-Tests.
> 
> With load i've to use > 500 us
> Without load i've to use > 1000 us (!?!)
> 
> If I run ./latency -p 1000 without any load I get latencies between 40
> and 70 us, but the Process is killed after a few seconds. 
>  - sometimes simply the message "Killed" is printed. 
> 	In this case the system is running, but if i try to start another
> latency-Process the system crashes (most of time: "Unable to handle
> kernel paging request at virtual address xxxxxxxx".)
>  - sometimes the system simply stands still (linux-timerisr /
> linux-timer_tick is'nt called anymore)
> 	jtag-debugger gdb-output:
> 
> 	Program received signal SIGSTOP, Stopped (signal).
> 	0x0000ba40 in ?? ()
> 	(gdb) stepi
> 	0x0000ba40 in ?? ()
> 	Infinite loop detected
> 
> The same happens if I run ./latency -p 500 with load.
> 

Sounds like some gremlin is still sleeping in the code. You will have to
trace down the oddities and understand what is leading to the oops or
lock-up.

> 
> 
> 3. in-kernel periodic task & in-kernel timer benchmark 
> 
> -sh-3.00# ./latency -t 2 -T 10
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> latency: failed to start in-kernel timer benchmark, code -25
> ---|------------|------------|------------|--------|-------------------------
> RTS|-1093001.752|       0.001|      93.252|   93340|
> 00:00:10/00:00:10
> 
> -sh-3.00# ./latency -t 1 -T 10
> == Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> latency: failed to start in-kernel timer benchmark, code -25
> ---|------------|------------|------------|--------|-------------------------
> RTS|-1097339.416|       0.001|      93.252|   93340|
> 00:00:10/00:00:10
> 
> What does "latency: failed to start in-kernel timer benchmark, code -25"
> mean? Are the results valid?

Nope, they aren't. Did you compile all the testing devices into the
kernel or did you load them all at once? I guess the latency test picks
the wrong device here. Try calling it with "-D1" as well. You can see
what devices are loaded under /proc/xenomai/rtdm/.

> 
> 
> 4. switchtest & switchbench
> 
> -sh-3.00# ./switchtest       
> == Testing FPU check routines...
> == FPU check routines: unimplemented, skipping FPU switches tests.
> == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7
> rtuo-8
> RTT|  00:00:01
> RTH|ctx switches|-------total
> RTD|         450|         450
> RTD|         450|         900
> RTD|         459|        1359
> RTD|         450|        1809
> RTD|         459|        2268
> RTD|         459|        2727
> RTD|         450|        3177
> switchtest seems to run normally, but what does the output mean?

As long as you see increasing numbers on the right and no oopses,
everything should be ok. (These numbers indicate the ammount of
successful context switches per cycle.)

> 
> 
> The problems with switchbench are similar to the Problems discussed in
> #2. 
> -sh-3.00# ./switchbench -n 100 -p 10000
> == Sampling period: 10000 us
> == Do not interrupt this program
> RTH|     lat min|     lat avg|     lat max|        lost
> RTD|       86443|       90060|      101634|           0
> -sh-3.00# ./switchbench -n 100 -p 1000 
> == Sampling period: 1000 us
> == Do not interrupt this program
> RTH|     lat min|     lat avg|     lat max|        lost
> RTD|       77039|       81741|       98741|           0
> -sh-3.00# ./switchbench -n 100 -p 100 
> == Sampling period: 100 us
> == Do not interrupt this program
> [  122.670000] Unable to handle kernel paging request at virtual address
> e2822059
> [  122.670000] pgd = c3b60000
> [  122.670000] [e2822059] *pgd=00000000
> [  122.670000] Internal error: Oops: 805 [#1]
> [  122.670000] Modules linked in:
> [  122.670000] CPU: 0
> [  122.670000] pc : [<c0150930>]    lr : [<c015080c>]    Not tainted
> [  122.670000] sp : c39d0014  ip : c3b54044  fp : c39d0040
> [  122.670000] r10: c02d43e4  r9 : 00800000  r8 : c0322b2c
> [  122.670000] r7 : c032212c  r6 : 00000000  r5 : c01194e0  r4 :
> 00000000
> [  122.670000] r3 : 00000000  r2 : e282200c  r1 : c3b54000  r0 :
> c3b54000
> [  122.670000] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  Segment user
> [  122.670000] Control: 5317F  Table: 03B60000  DAC: 00000015
> [  122.670000] Process worker (pid: 131, stack limit = 0xc39ce194)
> [  122.670000] Stack: (0xc39d0014 to 0xc39d0000)
> [  122.670000] Backtrace: 
> [  122.670000] Function entered at [<c01502e8>] from [<c014d25c>]
> [  122.670000] Function entered at [<c014d1c4>] from [<c014d2a4>]
> [  122.670000]  r7 = 00000000  r6 = C02D2680  r5 = C02D2880  r4 =
> C02D2688
> [  122.670000] Function entered at [<c014d288>] from [<c014a350>]
> [  122.670000] Function entered at [<c014a1e8>] from [<c014a7a4>]
> [  122.670000] Function entered at [<c014a700>] from [<c0126000>]
> [  122.670000]  r7 = C02D2680  r6 = C02D2880  r5 = 00000010  r4 =
> C02D2680
> [  122.670000] Function entered at [<c0125e64>] from [<c01260a8>]
> [  122.670000] Function entered at [<c0126010>] from [<c011f824>]
> [  122.670000] Code: e3c3303f e593300c e5932004 e3a03001 (e5c2304d) 
> 

Compiled without debug symbols? Might be helpful to turn them in in
kernel config.

> 
> 
> 5. cyclictest
> 
> Here some test-cases:
> 
> -sh-3.00# ./cyclictest -l 100
> 0.03 0.01 0.00 1/21 53          
> 
> T: 0 (   53) P: 0 I:    1000 C:     100 Min:-1087273 Act:-1087273 Max:
> -989708
> -sh-3.00# ./cyclictest -l 1000
> 0.02 0.01 0.00 2/22 56          
> 
> T: 0 (   56) P: 0 I:    1000 C:    1000 Min:-1973899 Act:-1973899 Max:
> -989170
> -sh-3.00# ./cyclictest -l 10000
> 0.01 0.01 0.00 1/21 59          
> 
> T: 0 (   59) P: 0 I:    1000 C:   10000 Min:-10848662 Act:-10848662 Max:
> -992290
> -sh-3.00# ./cyclictest -l 100000
> 0.01 0.00 0.00 2/22 62          
> 
> T: 0 (   62) P: 0 I:    1000 C:  100000 Min:-99563368 Act:-99563368 Max:
> -989732
> -sh-3.00# ./cyclictest -l 1000000
> 0.98 0.22 0.07 3/22 65          
> 
> T: 0 (   65) P: 0 I:    1000 C: 1000000 Min:-986731091 Act:-986731091
> Max: -989084
> 
> cyclic-Test runs, but while it is running, timer_tick is never called.
> 

This is totally broken. Do you run a manually compiled version of that
test? Check if it links against pthread_rt (the POSIX skin library).
Otherwise you benchmark vanilla Linux...

> 
> 
> 
> I think that all above problems depends on the same root. I tried to
> find that root, but currently without success. 
> 

Again: Pick some easy-to-reproduce oops and try to understand its
history. Also, posting your patches may trigger further review and input.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Gilles Chanteperdrix]

Schlägl Manfred jun. wrote:
> Hi!
> 
> I've tried to implement Adeos 1.5 and Xenomai 2.2.3 on a
> Netsilicon-Platform (ns9750-evalboard with Arm926EJ).
> 
> The Timer is implemented (with a manual __ipipe_trigger_irq if
> reload<3). The Interrupt-Demuxer is deactivated.
> 
> The System boots with Adeos & Xenomai. Time is running normally. Things
> look generally very good, but there are some Problems:
> 
> 
> 1. Latencies are very high.
> 
> dd if=/dev/zero of=/dev/null &
> ./latency -p 10000 -T 20
> 
> RTS|      92.592|      95.486|     125.506|       0|
> 00:00:20/00:00:20
> 
> I know, it's a common problem with Xenomai/ARM. Is it true, that it has
> something to do with a slow processor-cache-flush? Does anybody know
> more about that?

Welcome to the club.

See http://www.linuxdevices.com/articles/AT2598317046.html

According to this article, disabling MMU should improve the situation.
But the I-pipe patch has not yet been tested on ucLinux for ARM.

Also, if you want to measure the real effect of the cache on the
latency test, you should run the cache calibrator in an infinite loop:
http://monetdb.cwi.nl/Calibrator/
With this tool, I easily get a bit less than 200 us latency on an ARM
clocked at 600 MHz.

> 
> 
> 2. I've to use very high Periods on Latency-Tests.
> 
> With load i've to use > 500 us
> Without load i've to use > 1000 us (!?!)
> 
> If I run ./latency -p 1000 without any load I get latencies between 40
> and 70 us, but the Process is killed after a few seconds. 
>  - sometimes simply the message "Killed" is printed. 
> 	In this case the system is running, but if i try to start another
> latency-Process the system crashes (most of time: "Unable to handle
> kernel paging request at virtual address xxxxxxxx".)
>  - sometimes the system simply stands still (linux-timerisr /
> linux-timer_tick is'nt called anymore)
> 	jtag-debugger gdb-output:
> 
> 	Program received signal SIGSTOP, Stopped (signal).
> 	0x0000ba40 in ?? ()
> 	(gdb) stepi
> 	0x0000ba40 in ?? ()
> 	Infinite loop detected
> 
> The same happens if I run ./latency -p 500 with load.

I observed the same phenomenon, and thought that the sampling period was
simply too small to let the display task run. Your debugger trace seems
to prove me wrong. It would be interesting to know the reason why the
task receives this SIGSTOP.

> 
> 
> 
> 3. in-kernel periodic task & in-kernel timer benchmark 
> 
> -sh-3.00# ./latency -t 2 -T 10
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> latency: failed to start in-kernel timer benchmark, code -25
> ---|------------|------------|------------|--------|-------------------------
> RTS|-1093001.752|       0.001|      93.252|   93340|
> 00:00:10/00:00:10
> 
> -sh-3.00# ./latency -t 1 -T 10
> == Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> latency: failed to start in-kernel timer benchmark, code -25
> ---|------------|------------|------------|--------|-------------------------
> RTS|-1097339.416|       0.001|      93.252|   93340|
> 00:00:10/00:00:10
> 
> What does "latency: failed to start in-kernel timer benchmark, code -25"
> mean? Are the results valid?

-25 is -ENOTTY, it happens when you issue an unknown ioctl on an RTDM
device.

> 
> 
> 4. switchtest & switchbench
> 
> -sh-3.00# ./switchtest       
> == Testing FPU check routines...
> == FPU check routines: unimplemented, skipping FPU switches tests.
> == Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7
> rtuo-8
> RTT|  00:00:01
> RTH|ctx switches|-------total
> RTD|         450|         450
> RTD|         450|         900
> RTD|         459|        1359
> RTD|         450|        1809
> RTD|         459|        2268
> RTD|         459|        2727
> RTD|         450|        3177
> switchtest seems to run normally, but what does the output mean?
> 
> 
> The problems with switchbench are similar to the Problems discussed in
> #2. 
> -sh-3.00# ./switchbench -n 100 -p 10000
> == Sampling period: 10000 us
> == Do not interrupt this program
> RTH|     lat min|     lat avg|     lat max|        lost
> RTD|       86443|       90060|      101634|           0
> -sh-3.00# ./switchbench -n 100 -p 1000 
> == Sampling period: 1000 us
> == Do not interrupt this program
> RTH|     lat min|     lat avg|     lat max|        lost
> RTD|       77039|       81741|       98741|           0
> -sh-3.00# ./switchbench -n 100 -p 100 
> == Sampling period: 100 us
> == Do not interrupt this program
> [  122.670000] Unable to handle kernel paging request at virtual address
> e2822059
> [  122.670000] pgd = c3b60000
> [  122.670000] [e2822059] *pgd=00000000
> [  122.670000] Internal error: Oops: 805 [#1]
> [  122.670000] Modules linked in:
> [  122.670000] CPU: 0
> [  122.670000] pc : [<c0150930>]    lr : [<c015080c>]    Not tainted
> [  122.670000] sp : c39d0014  ip : c3b54044  fp : c39d0040
> [  122.670000] r10: c02d43e4  r9 : 00800000  r8 : c0322b2c
> [  122.670000] r7 : c032212c  r6 : 00000000  r5 : c01194e0  r4 :
> 00000000
> [  122.670000] r3 : 00000000  r2 : e282200c  r1 : c3b54000  r0 :
> c3b54000
> [  122.670000] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  Segment user
> [  122.670000] Control: 5317F  Table: 03B60000  DAC: 00000015
> [  122.670000] Process worker (pid: 131, stack limit = 0xc39ce194)
> [  122.670000] Stack: (0xc39d0014 to 0xc39d0000)
> [  122.670000] Backtrace: 
> [  122.670000] Function entered at [<c01502e8>] from [<c014d25c>]
> [  122.670000] Function entered at [<c014d1c4>] from [<c014d2a4>]
> [  122.670000]  r7 = 00000000  r6 = C02D2680  r5 = C02D2880  r4 =
> C02D2688
> [  122.670000] Function entered at [<c014d288>] from [<c014a350>]
> [  122.670000] Function entered at [<c014a1e8>] from [<c014a7a4>]
> [  122.670000] Function entered at [<c014a700>] from [<c0126000>]
> [  122.670000]  r7 = C02D2680  r6 = C02D2880  r5 = 00000010  r4 =
> C02D2680
> [  122.670000] Function entered at [<c0125e64>] from [<c01260a8>]
> [  122.670000] Function entered at [<c0126010>] from [<c011f824>]
> [  122.670000] Code: e3c3303f e593300c e5932004 e3a03001 (e5c2304d) 

ksymoops will help you there.

> 
> 
> 
> 5. cyclictest
> 
> Here some test-cases:
> 
> -sh-3.00# ./cyclictest -l 100
> 0.03 0.01 0.00 1/21 53          
> 
> T: 0 (   53) P: 0 I:    1000 C:     100 Min:-1087273 Act:-1087273 Max:
> -989708
> -sh-3.00# ./cyclictest -l 1000
> 0.02 0.01 0.00 2/22 56          
> 
> T: 0 (   56) P: 0 I:    1000 C:    1000 Min:-1973899 Act:-1973899 Max:
> -989170
> -sh-3.00# ./cyclictest -l 10000
> 0.01 0.01 0.00 1/21 59          
> 
> T: 0 (   59) P: 0 I:    1000 C:   10000 Min:-10848662 Act:-10848662 Max:
> -992290
> -sh-3.00# ./cyclictest -l 100000
> 0.01 0.00 0.00 2/22 62          
> 
> T: 0 (   62) P: 0 I:    1000 C:  100000 Min:-99563368 Act:-99563368 Max:
> -989732
> -sh-3.00# ./cyclictest -l 1000000
> 0.98 0.22 0.07 3/22 65          
> 
> T: 0 (   65) P: 0 I:    1000 C: 1000000 Min:-986731091 Act:-986731091
> Max: -989084
> 
> cyclic-Test runs, but while it is running, timer_tick is never called.
> 
> 
> 
> 
> I think that all above problems depends on the same root. I tried to
> find that root, but currently without success. 

I think that you have several problems:
1 and 2 exists on other ARM platforms;
3 is probably a simple problem of device index;
4 and 5 are really worrying, you should start running ksymoops on the 
oops and/or investigate the case where the timer stop.

-- 
                                                  Gilles Chanteperdrix

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Philippe Gerum]

On Mon, 2006-10-16 at 17:48 +0200, Schlägl Manfred jun. wrote:
> Hi!
> 
> I've tried to implement Adeos 1.5 and Xenomai 2.2.3 on a
> Netsilicon-Platform (ns9750-evalboard with Arm926EJ).
> 

Make sure to use 1.5-01.

[...]

> I know, it's a common problem with Xenomai/ARM. Is it true, that it has
> something to do with a slow processor-cache-flush? Does anybody know
> more about that?
> 

FWIW, we had the very same issue on an Integrator CP.

> 
> 2. I've to use very high Periods on Latency-Tests.
> 
> With load i've to use > 500 us
> Without load i've to use > 1000 us (!?!)
> 
> If I run ./latency -p 1000 without any load I get latencies between 40
> and 70 us, but the Process is killed after a few seconds. 
>  - sometimes simply the message "Killed" is printed.

Could you "strace" your process instead of running it over GDB? I'm not
yet sure that we are actually chasing a SIGSTOP.

[...]

> 3. in-kernel periodic task & in-kernel timer benchmark 
> 
> -sh-3.00# ./latency -t 2 -T 10
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> latency: failed to start in-kernel timer benchmark, code -25

Eh? That's weird. The fact that the RTDM benchmark device could be
opened, but that a wrong ioctl code seemed to flow to it might be the
sign of the worm, somewhere in the Adeos syscall propagation path. Btw,
are the RTDM-based benchmark drivers compiled statically into the
kernel?

Also, could you patch this in, and tell us if anything appears in the
kernel log during the fail attempt to start the test? TIA,

--- ksrc/drivers/testing/timerbench.c~	2006-07-18 15:19:02.000000000 +0200
+++ ksrc/drivers/testing/timerbench.c	2006-10-16 23:28:06.000000000 +0200
@@ -409,6 +409,7 @@
             break;
 
         default:
+	    printk("%s: bad ioctl code (0x%x)\n", __FUNCTION__, request);
             ret = -ENOTTY;
     }
 

[...]

> -sh-3.00# ./switchbench -n 100 -p 100 
> == Sampling period: 100 us
> == Do not interrupt this program
> [  122.670000] Unable to handle kernel paging request at virtual address
> e2822059
> [  122.670000] pgd = c3b60000
> [  122.670000] [e2822059] *pgd=00000000
> [  122.670000] Internal error: Oops: 805 [#1]
> [  122.670000] Modules linked in:
> [  122.670000] CPU: 0
> [  122.670000] pc : [<c0150930>]    lr : [<c015080c>]    Not tainted
> [  122.670000] sp : c39d0014  ip : c3b54044  fp : c39d0040
> [  122.670000] r10: c02d43e4  r9 : 00800000  r8 : c0322b2c
> [  122.670000] r7 : c032212c  r6 : 00000000  r5 : c01194e0  r4 :
> 00000000
> [  122.670000] r3 : 00000000  r2 : e282200c  r1 : c3b54000  r0 :
> c3b54000
> [  122.670000] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  Segment user
> [  122.670000] Control: 5317F  Table: 03B60000  DAC: 00000015
> [  122.670000] Process worker (pid: 131, stack limit = 0xc39ce194)
> [  122.670000] Stack: (0xc39d0014 to 0xc39d0000)
> [  122.670000] Backtrace: 
> [  122.670000] Function entered at [<c01502e8>] from [<c014d25c>]
> [  122.670000] Function entered at [<c014d1c4>] from [<c014d2a4>]
> [  122.670000]  r7 = 00000000  r6 = C02D2680  r5 = C02D2880  r4 =
> C02D2688
> [  122.670000] Function entered at [<c014d288>] from [<c014a350>]
> [  122.670000] Function entered at [<c014a1e8>] from [<c014a7a4>]
> [  122.670000] Function entered at [<c014a700>] from [<c0126000>]
> [  122.670000]  r7 = C02D2680  r6 = C02D2880  r5 = 00000010  r4 =
> C02D2680
> [  122.670000] Function entered at [<c0125e64>] from [<c01260a8>]
> [  122.670000] Function entered at [<c0126010>] from [<c011f824>]
> [  122.670000] Code: e3c3303f e593300c e5932004 e3a03001 (e5c2304d) 
> 

As mentioned already, it would be really nice to activate the debug
option and ask ksymoops to dump some symbolic backtrace about this
crash.

[...]

> 5. cyclictest
> 
> Here some test-cases:
> 
> -sh-3.00# ./cyclictest -l 100
> 0.03 0.01 0.00 1/21 53          

[...]

> cyclic-Test runs, but while it is running, timer_tick is never called.
> 

If you want to run this test by hand, try:
./cyclictest -n -t 1 -i 100
or just use the "run" script. The output you got is likely because the
default setup uses plain Linux signals for triggering the sampling
activity.

[...]

-- 
Philippe.

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Mon, 2006-10-16 at 17:48 +0200, Schlägl Manfred jun. wrote:
>>3. in-kernel periodic task & in-kernel timer benchmark 
>>
>>-sh-3.00# ./latency -t 2 -T 10
>>== Sampling period: 100 us
>>== Test mode: in-kernel timer handler
>>== All results in microseconds
>>latency: failed to start in-kernel timer benchmark, code -25
> 
> 
> Eh? That's weird. The fact that the RTDM benchmark device could be
> opened, but that a wrong ioctl code seemed to flow to it might be the
> sign of the worm, somewhere in the Adeos syscall propagation path. Btw,
> are the RTDM-based benchmark drivers compiled statically into the
> kernel?

All benchmark drivers (timerbench, switchtest and irqbench) use the
/dev/rttest%d devices, the device index is passed to latency
and irqbench using the -D option whereas switchtest uses the ioctl error
to find the correct device. So this error might simply be the sign that
Manfred did not pass the -D option to latency.

-- 
                                                  Gilles Chanteperdrix

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> All benchmark drivers (timerbench, switchtest and irqbench) use the
> /dev/rttest%d devices, the device index is passed to latency
> and irqbench using the -D option whereas switchtest uses the ioctl error
> to find the correct device. So this error might simply be the sign that
> Manfred did not pass the -D option to latency.

Or that Xenomai was compiled without the timerbench driver.

-- 
                                                  Gilles Chanteperdrix

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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

Here some test-cases:


-sh-3.00# cat /proc/xenomai/rtdm/rttest0/information 
driver:         xeno_timerbench
version:        0.2.0
peripheral:     Timer Latency Benchmark
provider:       Jan Kiszka
class:          6
sub-class:      0
flags:          NAMED_DEVICE  
lock count:     0
-sh-3.00# cat /proc/xenomai/rtdm/rttest1/information 
driver:         xeno_irqbench
version:        0.1.0
peripheral:     IRQ Latency Benchmark
provider:       Jan Kiszka
class:          6
sub-class:      1
flags:          NAMED_DEVICE  
lock count:     0
-sh-3.00# cat /proc/xenomai/rtdm/rttest2/information 
driver:         xeno_switchtest
version:        0.1.1
peripheral:     Context Switch Test
provider:       Gilles Chanteperdrix
class:          6
sub-class:      2
flags:          NAMED_DEVICE  
lock count:     0
-sh-3.00# cat /proc/xenomai/rtdm/named_devices       
Hash    Name                            /proc
D6      rttest0                         rttest0
D7      rttest1                         rttest1
D8      rttest2                         rttest2


-sh-3.00# ./latency -D0 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to start in-kernel timer benchmark, code -25
---|------------|------------|------------|--------|-------------------------
RTS|-1091011.128|       0.001|      93.252|   93340|
00:00:00/00:00:10

-sh-3.00# ./latency -D1 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to start in-kernel timer benchmark, code -25
---|------------|------------|------------|--------|-------------------------
RTS|-1098113.592|       0.001|      93.252|   93340|
00:00:-01/00:00:10

-sh-3.00# ./latency -D2 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to start in-kernel timer benchmark, code -25
---|------------|------------|------------|--------|-------------------------
RTS|-1093665.336|       0.001|      93.252|   93340|
00:00:00/00:00:10

-sh-3.00# ./latency -D3 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to open benchmark device, code -19
(modprobe xeno_timerbench?)
-sh-3.00# ./latency -D4 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to open benchmark device, code -19
(modprobe xeno_timerbench?)
-sh-3.00# ./latency -D4 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to open benchmark device, code -19
(modprobe xeno_timerbench?)
-sh-3.00# ./latency -D5 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to open benchmark device, code -19
(modprobe xeno_timerbench?)
-sh-3.00# ./latency -D6 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to open benchmark device, code -19
(modprobe xeno_timerbench?)
-sh-3.00# ./latency -D7 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to open benchmark device, code -19
(modprobe xeno_timerbench?)
-sh-3.00# ./latency -D8 -t 1 -T 10 -p 10000
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
latency: failed to open benchmark device, code -19
(modprobe xeno_timerbench?)



... no success




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Jan Kiszka]

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

Schlägl Manfred jun. wrote:
> Here some test-cases:
> 
> 
> -sh-3.00# cat /proc/xenomai/rtdm/rttest0/information 
> driver:         xeno_timerbench
> version:        0.2.0
> peripheral:     Timer Latency Benchmark
> provider:       Jan Kiszka
> class:          6
> sub-class:      0
> flags:          NAMED_DEVICE  
> lock count:     0

Then "-D0" is the correct device argument for latency, and that's
default anyway.

> -sh-3.00# cat /proc/xenomai/rtdm/rttest1/information 
> driver:         xeno_irqbench
> version:        0.1.0
> peripheral:     IRQ Latency Benchmark
> provider:       Jan Kiszka
> class:          6
> sub-class:      1
> flags:          NAMED_DEVICE  
> lock count:     0
> -sh-3.00# cat /proc/xenomai/rtdm/rttest2/information 
> driver:         xeno_switchtest
> version:        0.1.1
> peripheral:     Context Switch Test
> provider:       Gilles Chanteperdrix
> class:          6
> sub-class:      2
> flags:          NAMED_DEVICE  
> lock count:     0
> -sh-3.00# cat /proc/xenomai/rtdm/named_devices       
> Hash    Name                            /proc
> D6      rttest0                         rttest0
> D7      rttest1                         rttest1
> D8      rttest2                         rttest2
> 
> 
> -sh-3.00# ./latency -D0 -t 1 -T 10 -p 10000
> == Sampling period: 10000 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> latency: failed to start in-kernel timer benchmark, code -25

Ok, we must have some more complicated problem here. Please follow
Philippe's suggestion to instrument the involved code (e.g. the
timerbench driver) with printk to see what is called with which arguments.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Philippe Gerum]

On Tue, 2006-10-17 at 10:38 +0200, Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
> > All benchmark drivers (timerbench, switchtest and irqbench) use the
> > /dev/rttest%d devices, the device index is passed to latency
> > and irqbench using the -D option whereas switchtest uses the ioctl error
> > to find the correct device. So this error might simply be the sign that
> > Manfred did not pass the -D option to latency.
> 
> Or that Xenomai was compiled without the timerbench driver.

No, you would get -ENODEV, with a failure on the opening of the device.

> 
-- 
Philippe.

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Philippe Gerum]

On Tue, 2006-10-17 at 10:15 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Mon, 2006-10-16 at 17:48 +0200, Schlägl Manfred jun. wrote:
> >>3. in-kernel periodic task & in-kernel timer benchmark 
> >>
> >>-sh-3.00# ./latency -t 2 -T 10
> >>== Sampling period: 100 us
> >>== Test mode: in-kernel timer handler
> >>== All results in microseconds
> >>latency: failed to start in-kernel timer benchmark, code -25
> > 
> > 
> > Eh? That's weird. The fact that the RTDM benchmark device could be
> > opened, but that a wrong ioctl code seemed to flow to it might be the
> > sign of the worm, somewhere in the Adeos syscall propagation path. Btw,
> > are the RTDM-based benchmark drivers compiled statically into the
> > kernel?
> 
> All benchmark drivers (timerbench, switchtest and irqbench) use the
> /dev/rttest%d devices, the device index is passed to latency
> and irqbench using the -D option whereas switchtest uses the ioctl error
> to find the correct device. So this error might simply be the sign that
> Manfred did not pass the -D option to latency.

AFAICS, the failed operation did not happen on an attempt to open the
device, but later when submitting an ioctl() request to it, in order to
start the sampling. So this can't be a simple device index issue. IOW,
the rttestX device is available and ready to use; the problem lies
beyond that point.

-- 
Philippe.

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Gilles Chanteperdrix]

Philippe Gerum wrote:
>>All benchmark drivers (timerbench, switchtest and irqbench) use the
>>/dev/rttest%d devices, the device index is passed to latency
>>and irqbench using the -D option whereas switchtest uses the ioctl error
>>to find the correct device. So this error might simply be the sign that
>>Manfred did not pass the -D option to latency.
> 
> 
> AFAICS, the failed operation did not happen on an attempt to open the
> device, but later when submitting an ioctl() request to it, in order to
> start the sampling. So this can't be a simple device index issue. IOW,
> the rttestX device is available and ready to use; the problem lies
> beyond that point.

When using the wrong /dev/rttest device, open would not fail but ioctl
would fail. But I agree, Manfred is facing a different issue.

-- 
                                                  Gilles Chanteperdrix

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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

Hi again!

I've forgotten: I'm using ipipe-1.5-01 on 2.6.15.7 (builtin xenomai
(skins+drivers))

1. spin_debug messages
2. switchtest
3. switchbench
4. cyclictest
5. latency
6. cross-compiled xenomai


Next time i will send my patch too. (i've to clean it a little bit)

-------------

1. With enabled kernel-debugging (spin_debug), while loading xeno_native
(built-in and as module) I get:

[42949377.340000] BUG: spinlock already unlocked on CPU#0, swapper/0
[42949377.340000]  lock: c02dde74, .magic: dead4ead, .owner:
swapper/0, .owner_cpu: 0
[42949377.340000] [<c0125f3c>] (dump_stack+0x0/0x14) from [<c0216a30>]
(spin_bug+0x90/0xa8)
[42949377.340000] [<c02169a0>] (spin_bug+0x0/0xa8) from [<c0216cb4>]
(_raw_spin_unlock+0xa0/0xb8)
[42949377.340000]  r6 = 00000000  r5 = C031F1E4  r4 = C02DDE74 
[42949377.340000] [<c0216c14>] (_raw_spin_unlock+0x0/0xb8) from
[<c02b0ee4>] (_spin_unlock+0x10/0x14)
[42949377.340000]  r4 = 00000005 
[42949377.340000] [<c02b0ed4>] (_spin_unlock+0x0/0x14) from [<c0121e20>]
(asm_do_IRQ+0x11c/0x138)
[42949377.340000] [<c0121d04>] (asm_do_IRQ+0x0/0x138) from [<c01505e4>]
(__ipipe_sync_stage+0x1f4/0x208)
[42949377.340000] [<c01503f0>] (__ipipe_sync_stage+0x0/0x208) from
[<c0150810>] (ipipe_suspend_domain+0x7c/0xa8)
[42949377.340000] [<c0150794>] (ipipe_suspend_domain+0x0/0xa8) from
[<c01509f8>] (__ipipe_walk_pipeline+0x8c/0xc8)
[42949377.340000]  r8 = 00000001  r7 = C02E05D8  r6 = C02E05E0  r5 =
00000000
[42949377.340000]  r4 = C02E05E0 
[42949377.340000] [<c015096c>] (__ipipe_walk_pipeline+0x0/0xc8) from
[<c0127618>] (__ipipe_handle_irq+0x140/0x1cc)
[42949377.340000]  r7 = C0365BC0  r6 = 000000A0  r5 = 00000005  r4 =
C0367920
[42949377.340000] [<c01274d8>] (__ipipe_handle_irq+0x0/0x1cc) from
[<c01276d4>] (__ipipe_grab_irq+0x30/0xe8)
[42949377.340000] [<c01276a4>] (__ipipe_grab_irq+0x0/0xe8) from
[<c0120844>] (__irq_svc+0x24/0xd4)
[42949377.340000] [<c01226c4>] (default_idle+0x0/0x68) from [<c012276c>]
(cpu_idle+0x40/0x5c)
[42949377.340000] [<c012272c>] (cpu_idle+0x0/0x5c) from [<c0120024>]
(__init_end+0x24/0x2c)
[42949377.340000]  r6 = C02DDE6C  r5 = C032029C  r4 = C037E6D0 
[42949377.340000] [<c0120000>] (__init_end+0x0/0x2c) from [<c0108920>]
(start_kernel+0x120/0x16c)
[42949377.340000] [<c0108800>] (start_kernel+0x0/0x16c) from
[<00108094>] (0x108094)
[42949377.340000]  r4 = 00053175 

/*
 * do_IRQ handles all hardware IRQ's.  Decoded IRQs should not
 * come via this function.  Instead, they should provide their
 * own 'handler'
 */
asmlinkage void asm_do_IRQ(unsigned int irq, struct pt_regs *regs)
{
	struct irqdesc *desc = irq_desc + irq;

	/*
	 * Some hardware gives randomly wrong interrupts.  Rather
	 * than crashing, do something sensible.
	 */
	if (irq >= NR_IRQS)
		desc = &bad_irq_desc;

	irq_enter();
	spin_lock(&irq_controller_lock);

	desc_handle_irq(irq, desc, regs);// unlocks irq_controller_lock

	/*
	 * Now re-run any pending interrupts.
	 */
	if (!list_empty(&irq_pending))
		do_pending_irqs(regs);

	irq_finish(irq);

	spin_unlock(&irq_controller_lock);
	irq_exit();
}

Is this normal, or could this also depend on a "main-bug".



2. switchtest
is running normally

3. switchbench
switchtest works with periods of about 10000 us
-sh-3.00# ./run -- -p 10000         
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 10000 us
== Do not interrupt this program

RTH|     lat min|     lat avg|     lat max|        lost
RTD|       77039|       89337|      150824|           0

works, but

./run -- -n 100 -p 100 (switchbench)

Most of time the system simply stands still (no more timer-activity),
but here i've a kernel-fault with debug-symbols:

[   53.650000] Unable to handle kernel NULL pointer dereference at
virtual address 00000004
[   53.650000] pgd = c34c4000
[   53.650000] [00000004] *pgd=03b9f031, *pte=00000000, *ppte=00000000
[   53.650000] Internal error: Oops: 17 [#1]
[   53.650000] Modules linked in:
[   53.650000] CPU: 0
[   53.650000] PC is at xnpod_schedule+0x57c/0x7ec
[   53.650000] LR is at xnpod_schedule+0x570/0x7ec
[   53.650000] pc : [<c01573e8>]    lr : [<c01573dc>]    Not tainted
[   53.650000] sp : c347fddc  ip : c354a044  fp : c347fe10
[   53.650000] r10: c0368e30  r9 : c00c292c  r8 : 00000000
[   53.650000] r7 : 3a485725  r6 : 00000000  r5 : c3487ab4  r4 :
ffffffff
[   53.650000] r3 : 00000000  r2 : 00000000  r1 : c00c292c  r0 :
c354a000
[   53.650000] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  Segment user
[   53.650000] Control: 5317F  Table: 034C4000  DAC: 00000015
[   53.650000] Process worker (pid: 100, stack limit = 0xc347e194)
[   53.650000] Stack: (0xc347fddc to 0xc3480000)
[   53.650000] fdc0:
c0368e00 
[   53.650000] fde0: c00c292c 00000000 00000000 c0368e00 00000100
c02e05c0 00000001 c347fe38 
[   53.650000] fe00: c347fe0c c01579e4 c0156e7c c0368e00 00000001
00000000 c347e000 c02e05c0 
[   53.650000] fe20: 00000001 c00c292c 00000000 c347fe70 c347fe3c
c015c6f4 c0157834 00000000 
[   53.650000] fe40: c0153990 00000001 c0367050 c00c292c c0365fc0
c0365ba0 20000093 00000001 
[   53.650000] fe60: 00000000 c347fe8c c347fe74 c0157be8 c015c52c
c00c2f20 c0367050 c0365ba0 
[   53.650000] fe80: c347fe9c c347fe90 c0158950 c0157b38 c347feb4
c347fea0 c01539ec c015890c 
[   53.650000] fea0: 00000000 c348000c c347fec8 c347feb8 c0245040
c01539dc 00000000 c347ff0c 
[   53.650000] fec0: c347fecc c01506f0 c0244ff8 00000000 00000001
c0367900 c0365ba0 c348000c 
[   53.650000] fee0: 00000000 c02de2cc c3480040 c02e05d8 c0367380
c02e05d8 c02de33c 00000017 
[   53.650000] ff00: c347ff4c c347ff10 c0128aa0 c0150608 20000013
ffffffff c348000c 00000017 
[   53.650000] ff20: 00000004 c02de2cc c3480040 c02e05d8 c0367380
c02e05d8 c02de33c 00000017 
[   53.650000] ff40: c3480008 c347ff50 c0128e68 c01288f8 c347ff5c
c0127834 c348000c 00000004 
[   53.650000] ff60: 00000000 00000008 00000008 000f0042 60000013
c347e000 00000000 00000000 
[   53.650000] ff80: c347ff8c c0120e4c c01277e0 2001022b 00014240
c347fff0 00000000 00000000 
[   53.650000] ffa0: 00000000 00000008 ffffffff 00014240 c347fff0
00000000 00000000 00000008 
[   53.650000] ffc0: 00000008 00000000 0000001b 00000000 00000000
00000000 00010000 be5ffaf8 
[   53.650000] ffe0: ffffffff c3480040 c02e05d8 c0367380 c02e05d8
00000093 c0368e30 c3480088 
[   53.650000] Backtrace: 
[   53.650000] Backtrace aborted due to bad frame pointer <c347fe10>
[   53.650000] Code: eb03b755 e24b1030 e8910006 e3510000 (e592a004) 

-sh-3.00# ./run -- -p 1000  
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 1000 us
== Do not interrupt this program

system doesn't react after a while
debugger output
^C
Program received signal SIGSTOP, Stopped (signal).
0xffff000c in ?? ()
(gdb) next
Cannot find bounds of current function
(gdb) next
Cannot find bounds of current function
(gdb) next
Cannot find bounds of current function
(gdb) next
Cannot find bounds of current function
(gdb) next
Cannot find bounds of current function
(gdb) cont
^CRemote failure reply: E01
(gdb) cont
Remote failure reply: E01
(gdb) cont
Remote failure reply: E01


4. cyclictest
cyclictest runs, if i use the run script (built-in xenomai):

-sh-3.00# ./run 
*
*
* Type ^C to stop this application.
*
*
0.10 0.04 0.01 1/26 94          

T: 0 (   94) P:99 I:    1000 C:   22508 Min:      49 Act:      82 Max:
121


but is broken if i call it manually:

-sh-3.00# ./cyclictest 
0.10 0.04 0.01 2/23 103          

T: 0 (  103) P: 0 I:    1000 C:    1699 Min:-2660105 Act:-2660105 Max:
-985769


5. latency

For periodic user-mode task i need very high periods > 1000us.


Here are the latency-checks with printk's of the ioctls:

-sh-3.00# ./run -- -t 1
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: in-kernel periodic task
== All results in microseconds
[42949519.180000] rt_tmbench_ioctl_rt: request 1076364816 -> ret =
-ENOTTY(-25)
latency: failed to start in-kernel timer benchmark, code -25
[42949523.000000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
-ENOTTY(-25)
---|------------|------------|------------|--------|-------------------------
RTS|-1096532.504|       0.001|      93.252|   93340|
00:00:03/00:00:03

-sh-3.00# ./run -- -t 2
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: in-kernel timer handler
== All results in microseconds
[42949529.090000] rt_tmbench_ioctl_rt: request 1076364816 -> ret =
-ENOTTY(-25)
latency: failed to start in-kernel timer benchmark, code -25
[42949534.680000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
-ENOTTY(-25)
---|------------|------------|------------|--------|-------------------------
RTS|-1093751.320|       0.001|      93.252|   93340|
00:00:04/00:00:04


Userspace-codes differ from kernelspace-codes, I think...



6. Cross-Compiled Xenomai (Userspace)

I'm using elinos4.0

./configure --prefix=/ginzinger/bootdir/nfsroot/xeno-2.2.3/ --host arm 

checking build system type... i686-pc-linux-gnu
checking host system type... arm-unknown-none
checking for a BSD-compatible install... /usr/bin/install -c
checking for arm-gcc... arm_v4le-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm_v4le-gcc accepts -g... yes
checking for arm_v4le-gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... arm_v4le-gcc -E
checking target system type... arm-unknown-none
checking for arm-gcc... no
checking for gcc... gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... no
checking for gcc option to accept ANSI C... (cached) none needed
checking how to run the C preprocessor... gcc -E
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for arm-strip... no
checking for strip... strip
checking dependency style of arm_v4le-gcc... gcc3
checking whether to enable maintainer-specific portions of Makefiles...
no
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by arm_v4le-gcc... arm_v4le-ld
checking if the linker (arm_v4le-ld) is GNU ld... yes
checking for arm_v4le-ld option to reload object files... -r
checking for BSD-compatible nm... arm_v4le-nm
checking whether ln -s works... yes
checking how to recognise dependent libraries... unknown
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for arm-g++... arm_v4le-g++
checking whether we are using the GNU C++ compiler... yes
checking whether arm_v4le-g++ accepts -g... yes
checking dependency style of arm_v4le-g++... gcc3
checking how to run the C++ preprocessor... arm_v4le-g++ -E
checking for arm-g77... no
checking for arm-f77... no
checking for arm-xlf... no
checking for arm-frt... no
checking for arm-pgf77... no
checking for arm-fort77... no
checking for arm-fl32... no
checking for arm-af77... no
checking for arm-f90... no
checking for arm-xlf90... no
checking for arm-pgf90... no
checking for arm-epcf90... no
checking for arm-f95... no
checking for arm-fort... no
checking for arm-xlf95... no
checking for arm-ifc... no
checking for arm-efc... no
checking for arm-pgf95... no
checking for arm-lf95... no
checking for arm-gfortran... no
checking for g77... g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether g77 accepts -g... yes
checking the maximum length of command line arguments... 32768
checking command to parse arm_v4le-nm output from arm_v4le-gcc object...
ok
checking for objdir... .libs
checking for arm-ar... arm_v4le-ar
checking for arm-ranlib... arm_v4le-ranlib
checking for arm-strip... strip
checking if arm_v4le-gcc supports -fno-rtti -fno-exceptions... no
checking for arm_v4le-gcc option to produce PIC... -fPIC
checking if arm_v4le-gcc PIC flag -fPIC works... yes
checking if arm_v4le-gcc static flag -static works... yes
checking if arm_v4le-gcc supports -c -o file.o... yes
checking whether the arm_v4le-gcc linker (arm_v4le-ld) supports shared
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by arm_v4le-g++... arm_v4le-ld
checking if the linker (arm_v4le-ld) is GNU ld... yes
checking whether the arm_v4le-g++ linker (arm_v4le-ld) supports shared
libraries... no
checking for arm_v4le-g++ option to produce PIC... -fPIC
checking if arm_v4le-g++ PIC flag -fPIC works... yes
checking if arm_v4le-g++ static flag -static works... yes
checking if arm_v4le-g++ supports -c -o file.o... yes
checking whether the arm_v4le-g++ linker (arm_v4le-ld) supports shared
libraries... no
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
checking for g77 option to produce PIC... -fPIC
checking if g77 PIC flag -fPIC works... yes
checking if g77 static flag -static works... yes
checking if g77 supports -c -o file.o... yes
checking whether the g77 linker (arm_v4le-ld) supports shared
libraries... yes
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for target architecture... arm
checking for UVM support... y
checking for debug symbols... no
checking for SMP support... no
checking for size of system heap... 128 Kb
checking for ARM architecture version... 4
checking for ARM SA1100 architecture... no
checking whether building Linux in Xenomai build tree... no
checking for Doxygen documentation... no
checking for doxygen... no
checking for dot... NO
checking whether compiling Docbook XML documentation... no
checking for xmllint... no
checking for xsltproc... xsltproc
checking for fop.sh... no
checking whether Docbook XML documentation generation can use
network.... no
checking for docbook-xml root dir... /usr/share/sgml/docbook/dtd/xml/4.2
checking for docbook-xsl root
dir... /usr/share/sgml/docbook/stylesheet/xsl/nwalsh
checking whether using LaTeX non-stop mode... no
checking mqueue.h usability... yes
checking mqueue.h presence... yes
checking for mqueue.h... yes
checking for sched_setaffinity... ok
checking for specific GCC switches... done
checking whether ld supports @file... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config/Makefile
config.status: creating scripts/Makefile
config.status: creating scripts/xeno-config
config.status: creating scripts/xeno-load
config.status: creating scripts/xeno-test
config.status: creating src/Makefile
config.status: creating src/skins/Makefile
config.status: creating src/skins/posix/Makefile
config.status: creating src/skins/native/Makefile
config.status: creating src/skins/vxworks/Makefile
config.status: creating src/skins/vrtx/Makefile
config.status: creating src/skins/rtdm/Makefile
config.status: creating src/skins/rtai/Makefile
config.status: creating src/skins/uvm/Makefile
config.status: creating src/skins/uvm/nucleus/Makefile
config.status: creating src/skins/uvm/vxworks/Makefile
config.status: creating src/skins/uvm/psos+/Makefile
config.status: creating src/skins/uvm/vrtx/Makefile
config.status: creating src/skins/uvm/uitron/Makefile
config.status: creating src/include/Makefile
config.status: creating src/testsuite/Makefile
config.status: creating src/testsuite/latency/Makefile
config.status: creating src/testsuite/switchbench/Makefile
config.status: creating src/testsuite/cyclic/Makefile
config.status: creating src/testsuite/switchtest/Makefile
config.status: creating src/testsuite/irqbench/Makefile
config.status: creating include/Makefile
config.status: creating include/asm-generic/Makefile
config.status: creating include/asm-blackfin/Makefile
config.status: creating include/asm-i386/Makefile
config.status: creating include/asm-powerpc/Makefile
config.status: creating include/asm-ia64/Makefile
config.status: creating include/asm-arm/Makefile
config.status: creating include/asm-uvm/Makefile
config.status: creating include/asm-sim/Makefile
config.status: creating include/native/Makefile
config.status: creating include/nucleus/Makefile
config.status: creating include/posix/Makefile
config.status: creating include/posix/sys/Makefile
config.status: creating include/psos+/Makefile
config.status: creating include/rtai/Makefile
config.status: creating include/rtdm/Makefile
config.status: creating include/uitron/Makefile
config.status: creating include/vrtx/Makefile
config.status: creating include/vxworks/Makefile
config.status: creating doc/Makefile
config.status: creating doc/txt/Makefile
config.status: creating doc/man/Makefile
config.status: creating doc/man/runinfo.man
config.status: creating doc/man/xeno-config.man
config.status: creating doc/man/xeno-info.man
config.status: creating doc/man/xeno-load.man
config.status: creating doc/man/xeno-test.man
config.status: creating doc/doxygen/Makefile
config.status: creating doc/doxygen/Doxyfile
config.status: creating doc/docbook/Makefile
config.status: creating doc/docbook/catalog
config.status: creating doc/docbook/custom-stylesheets/Makefile
config.status: creating doc/docbook/custom-stylesheets/xsl/Makefile
config.status: creating
doc/docbook/custom-stylesheets/xsl/common/Makefile
config.status: creating doc/docbook/custom-stylesheets/xsl/fo/Makefile
config.status: creating doc/docbook/custom-stylesheets/xsl/html/Makefile
config.status: creating
doc/docbook/custom-stylesheets/xsl/html/chunk.xsl
config.status: creating
doc/docbook/custom-stylesheets/xsl/html/onechunk.xsl
config.status: creating doc/docbook/xenomai/Makefile
config.status: creating src/include/xeno_config.h
config.status: src/include/xeno_config.h is unchanged
config.status: linking ./include/asm-arm to src/include/asm/xenomai
config.status: linking ./include/asm-generic to
src/include/asm-generic/xenomai
config.status: executing depfiles commands



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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

On Tue, 2006-10-17 at 17:39 +0200, Schlägl Manfred jun. wrote:

> 5. latency
> 
> For periodic user-mode task i need very high periods > 1000us.
> 
> 
> Here are the latency-checks with printk's of the ioctls:
> 
> -sh-3.00# ./run -- -t 1
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> [42949519.180000] rt_tmbench_ioctl_rt: request 1076364816 -> ret =
> -ENOTTY(-25)
> latency: failed to start in-kernel timer benchmark, code -25
> [42949523.000000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
> -ENOTTY(-25)
> ---|------------|------------|------------|--------|-------------------------
> RTS|-1096532.504|       0.001|      93.252|   93340|
> 00:00:03/00:00:03
> 
> -sh-3.00# ./run -- -t 2
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> [42949529.090000] rt_tmbench_ioctl_rt: request 1076364816 -> ret =
> -ENOTTY(-25)
> latency: failed to start in-kernel timer benchmark, code -25
> [42949534.680000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
> -ENOTTY(-25)
> ---|------------|------------|------------|--------|-------------------------
> RTS|-1093751.320|       0.001|      93.252|   93340|
> 00:00:04/00:00:04
> 
> 
> Userspace-codes differ from kernelspace-codes, I think...



Yes it does!!!



#define RTTST_RTIOC_TMBENCH_START \
    _IOW(RTIOC_TYPE_TESTING, 0x10, struct rttst_tmbench_config) 

two different results in kernel-/user-space

sizeof(struct rttst_tmbench_config) 
-> kernel 	32
-> user		40


typedef struct rttst_tmbench_config {
    int                     mode;
    uint64_t                period;
    int                     priority;
    int                     warmup_loops;
    int                     histogram_size;
    int                     histogram_bucketsize;
    int                     freeze_max;
} rttst_tmbench_config_t;

sizeof(struct rttst_tmbench_config_t)
-> kernel	32	(uses packed-structure)
-> user		40	(uses unpacked-structure)

sizeof(uint64_t)
-> kernel	8
-> user		8

sizeof(int)
-> kernel	4
-> user		4


Difference has something to do with the internal structure of
rttst_tmbench_config.


Solution 1: Force userspace-app and kernel to use packed structure
--------------
typedef struct rttst_tmbench_config {
    int                     mode;
    uint64_t                period;
    int                     priority;
    int                     warmup_loops;
    int                     histogram_size;
    int                     histogram_bucketsize;
    int                     freeze_max;
} __attribute__((packed)) rttst_tmbench_config_t;

sizeof(struct rttst_tmbench_config_t)
-> kernel	32	(uses packed-structure)
-> user		32	(uses packed-structure)

Has to be done to all structures! (compiler-flag -fpack-struct)

Problems: 
 * problems with libs (see
http://gcc.gnu.org/ml/gcc-help/2005-01/msg00257.html)
 * possibly problems with typedef ????


Solution 2: Force userspace-app and kernel to use unpacked structure
--------------
typedef struct rttst_tmbench_config {
    int                     mode;
    uint64_t                period;
    int                     priority;
    int                     warmup_loops;
    int                     histogram_size;
    int                     histogram_bucketsize;
    int                     freeze_max;
} __attribute__((unpacked)) rttst_tmbench_config_t;


Kernel ignores the attribute!

Theoretically:
sizeof(struct rttst_tmbench_config_t)
-> kernel	40	(uses unpacked-structure)
-> user		40	(uses unpacked-structure)

Has to be done to all structures! 




Solution 3:
--------------
change kernel-configuration to use unpacked structures by default.



	- Manfred Schlaegl


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Philippe Gerum]

On Tue, 2006-10-17 at 17:39 +0200, Schlägl Manfred jun. wrote:

[...]

> 1. With enabled kernel-debugging (spin_debug), while loading xeno_native
> (built-in and as module) I get:

[...]

> Is this normal, or could this also depend on a "main-bug".
> 

No, that's absolutely abnormal. Switching the Linux kernel debug options
on is the usual way most of us work, and no warning should be emitted
under Xenomai operations. What you get on ARM, and which I cannot
reproduce on x86, ppc or blackfin, is worrying.

[...]

> 
> ./run -- -n 100 -p 100 (switchbench)
> 
> Most of time the system simply stands still (no more timer-activity),
> but here i've a kernel-fault with debug-symbols:
> 
> [   53.650000] Unable to handle kernel NULL pointer dereference at
> virtual address 00000004

We might have a stack overflow here, as a consequence of the shorter
sampling period.

[...]

> 4. cyclictest
> cyclictest runs, if i use the run script (built-in xenomai):
> 
> -sh-3.00# ./run 
> *
> *
> * Type ^C to stop this application.
> *
> *
> 0.10 0.04 0.01 1/26 94          
> 
> T: 0 (   94) P:99 I:    1000 C:   22508 Min:      49 Act:      82 Max:
> 121
> 
> 
> but is broken if i call it manually:
> 
> -sh-3.00# ./cyclictest 
> 0.10 0.04 0.01 2/23 103          
> 
> T: 0 (  103) P: 0 I:    1000 C:    1699 Min:-2660105 Act:-2660105 Max:
> -985769
> 

It's not actually broken, it's just that we have imported this code from
the PREEMPT_RT testsuite, and their default setup does not match our
testcase. You should at least pass -n to the test.

-- 
Philippe.

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Jan Kiszka]

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

Schlägl Manfred jun. wrote:
> On Tue, 2006-10-17 at 17:39 +0200, Schlägl Manfred jun. wrote:
> 
>> 5. latency
>>
>> For periodic user-mode task i need very high periods > 1000us.
>>
>>
>> Here are the latency-checks with printk's of the ioctls:
>>
>> -sh-3.00# ./run -- -t 1
>> *
>> *
>> * Type ^C to stop this application.
>> *
>> *
>> == Sampling period: 100 us
>> == Test mode: in-kernel periodic task
>> == All results in microseconds
>> [42949519.180000] rt_tmbench_ioctl_rt: request 1076364816 -> ret =
>> -ENOTTY(-25)
>> latency: failed to start in-kernel timer benchmark, code -25
>> [42949523.000000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
>> -ENOTTY(-25)
>> ---|------------|------------|------------|--------|-------------------------
>> RTS|-1096532.504|       0.001|      93.252|   93340|
>> 00:00:03/00:00:03
>>
>> -sh-3.00# ./run -- -t 2
>> *
>> *
>> * Type ^C to stop this application.
>> *
>> *
>> == Sampling period: 100 us
>> == Test mode: in-kernel timer handler
>> == All results in microseconds
>> [42949529.090000] rt_tmbench_ioctl_rt: request 1076364816 -> ret =
>> -ENOTTY(-25)
>> latency: failed to start in-kernel timer benchmark, code -25
>> [42949534.680000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
>> -ENOTTY(-25)
>> ---|------------|------------|------------|--------|-------------------------
>> RTS|-1093751.320|       0.001|      93.252|   93340|
>> 00:00:04/00:00:04
>>
>>
>> Userspace-codes differ from kernelspace-codes, I think...
> 
> 
> 
> Yes it does!!!
> 
> 
> 
> #define RTTST_RTIOC_TMBENCH_START \
>     _IOW(RTIOC_TYPE_TESTING, 0x10, struct rttst_tmbench_config) 
> 
> two different results in kernel-/user-space
> 
> sizeof(struct rttst_tmbench_config) 
> -> kernel 	32
> -> user		40
> 
> 
> typedef struct rttst_tmbench_config {
>     int                     mode;
>     uint64_t                period;
>     int                     priority;
>     int                     warmup_loops;
>     int                     histogram_size;
>     int                     histogram_bucketsize;
>     int                     freeze_max;
> } rttst_tmbench_config_t;
> 
> sizeof(struct rttst_tmbench_config_t)
> -> kernel	32	(uses packed-structure)
> -> user		40	(uses unpacked-structure)
> 
> sizeof(uint64_t)
> -> kernel	8
> -> user		8
> 
> sizeof(int)
> -> kernel	4
> -> user		4
> 
> 
> Difference has something to do with the internal structure of
> rttst_tmbench_config.
> 
> 
> Solution 1: Force userspace-app and kernel to use packed structure
> --------------
> typedef struct rttst_tmbench_config {
>     int                     mode;
>     uint64_t                period;
>     int                     priority;
>     int                     warmup_loops;
>     int                     histogram_size;
>     int                     histogram_bucketsize;
>     int                     freeze_max;
> } __attribute__((packed)) rttst_tmbench_config_t;
> 
> sizeof(struct rttst_tmbench_config_t)
> -> kernel	32	(uses packed-structure)
> -> user		32	(uses packed-structure)
> 
> Has to be done to all structures! (compiler-flag -fpack-struct)
> 
> Problems: 
>  * problems with libs (see
> http://gcc.gnu.org/ml/gcc-help/2005-01/msg00257.html)
>  * possibly problems with typedef ????
> 
> 
> Solution 2: Force userspace-app and kernel to use unpacked structure
> --------------
> typedef struct rttst_tmbench_config {
>     int                     mode;
>     uint64_t                period;
>     int                     priority;
>     int                     warmup_loops;
>     int                     histogram_size;
>     int                     histogram_bucketsize;
>     int                     freeze_max;
> } __attribute__((unpacked)) rttst_tmbench_config_t;
> 
> 
> Kernel ignores the attribute!
> 
> Theoretically:
> sizeof(struct rttst_tmbench_config_t)
> -> kernel	40	(uses unpacked-structure)
> -> user		40	(uses unpacked-structure)
> 
> Has to be done to all structures! 
> 
> 
> 
> 
> Solution 3:
> --------------
> change kernel-configuration to use unpacked structures by default.
> 

I vote for solution 4:

--- include/rtdm/rttesting.h    (revision 1731)
+++ include/rtdm/rttesting.h    (working copy)
@@ -85,8 +85,8 @@ typedef struct rttst_overall_bench_res {

 typedef struct rttst_tmbench_config {
     int                     mode;
-    nanosecs_rel_t          period;
     int                     priority;
+    nanosecs_rel_t          period;
     int                     warmup_loops;
     int                     histogram_size;
     int                     histogram_bucketsize;

Could you check if this helps?

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Tue, 2006-10-17 at 17:39 +0200, Schlägl Manfred jun. wrote:
> 
> [...]
> 
> 
>>1. With enabled kernel-debugging (spin_debug), while loading xeno_native
>>(built-in and as module) I get:
> 
> 
> [...]
> 
> 
>>Is this normal, or could this also depend on a "main-bug".
>>
> 
> 
> No, that's absolutely abnormal. Switching the Linux kernel debug options
> on is the usual way most of us work, and no warning should be emitted
> under Xenomai operations. What you get on ARM, and which I cannot
> reproduce on x86, ppc or blackfin, is worrying.

Some ARMs do not boot when spinlock debugging is enabled, so it would be
interesting to check if the error also occurs with I-pipe and Xenomai
off.

-- 
                                                  Gilles Chanteperdrix

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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

On Wed, 2006-10-18 at 12:35 +0200, Jan Kiszka wrote:

> I vote for solution 4:
> 
> --- include/rtdm/rttesting.h    (revision 1731)
> +++ include/rtdm/rttesting.h    (working copy)
> @@ -85,8 +85,8 @@ typedef struct rttst_overall_bench_res {
> 
>  typedef struct rttst_tmbench_config {
>      int                     mode;
> -    nanosecs_rel_t          period;
>      int                     priority;
> +    nanosecs_rel_t          period;
>      int                     warmup_loops;
>      int                     histogram_size;
>      int                     histogram_bucketsize;
> 
> Could you check if this helps?
> 
> Thanks,
> Jan
> 


Thanks! It works. ioctls are working

But there is another Problem: I've inserted debug messages

// USER-PROCESS
-sh-3.00# ./run -- -t 1 -p 10000 -T 5
*
*
* Type ^C to stop this application.
*
*
Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
LATENCY: display send RTTST_RTIOC_TMBENCH_START:
mode    0
periode 1
pri     99
warmup  1
hist_s  0
hist_bs 1000
fmax    0
DEBUG: rt_dev_ioctl: request: 1075840528
warming up...
DEBUG: rt_dev_ioctl: request: -1070594560
RTT|  00:00:01  (in-kernel periodic task, 10000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD|      29.369|      32.341|      35.879|       0|      29.369|
35.879
DEBUG: rt_dev_ioctl: request: -1070594560
RTD|      22.135|      32.381|      36.241|       0|      22.135|
36.241
DEBUG: rt_dev_ioctl: request: -1070594560
RTD|      21.050|      32.378|      37.326|       0|      21.050|
37.326
DEBUG: rt_dev_ioctl: request: -1070594560
DEBUG: rt_dev_ioctl: request: -1071118831
---|------------|------------|------------|--------|-------------------------
RTS|-1095770.696|       0.001|      93.660|   93748|
00:00:05/00:00:05
-sh-3.00# 	

// KERNEL-OUTPUT

[42949410.980000] KERNEL: rt_tmbench_ioctl_nrt got request 1075840528
[42949410.990000] KERNEL: rt_tmbench_ioctl_nrt got
RTTST_RTIOC_TMBENCH_START:
[42949411.020000] mode    0
[42949411.020000] periode 10000000
[42949411.030000] pri     99
[42949411.040000] warmup  1
[42949411.050000] hist_s  0
[42949411.060000] hist_bs 1000
[42949411.070000] fmax    0
[42949411.080000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
[42949411.090000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949411.120000] rt_tmbench_ioctl_rt -1070594560
[42949413.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
[42949413.090000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949413.120000] rt_tmbench_ioctl_rt -1070594560
[42949414.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
[42949414.090000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949414.120000] rt_tmbench_ioctl_rt -1070594560
[42949415.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
[42949415.090000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949415.120000] rt_tmbench_ioctl_rt -1070594560
[42949415.290000] KERNEL: rt_tmbench_ioctl_nrt got request -1071118831
[42949415.310000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
-ENOTTY(-25)



The RTTST_RTIOC_INTERM_BENCH_RES request is received by
rt_tmbench_ioctl_nrt and rt_tmbench_ioctl_rt. Is this normal on arm?
(on my x86 this happens only at the beginning of a test-run)


Thank you
	Manfred Schlaegl



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Jan Kiszka]

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

Schlägl Manfred jun. wrote:
> On Wed, 2006-10-18 at 12:35 +0200, Jan Kiszka wrote:
> 
>> I vote for solution 4:
>>
>> --- include/rtdm/rttesting.h    (revision 1731)
>> +++ include/rtdm/rttesting.h    (working copy)
>> @@ -85,8 +85,8 @@ typedef struct rttst_overall_bench_res {
>>
>>  typedef struct rttst_tmbench_config {
>>      int                     mode;
>> -    nanosecs_rel_t          period;
>>      int                     priority;
>> +    nanosecs_rel_t          period;
>>      int                     warmup_loops;
>>      int                     histogram_size;
>>      int                     histogram_bucketsize;
>>
>> Could you check if this helps?
>>
>> Thanks,
>> Jan
>>
> 
> 
> Thanks! It works. ioctls are working

Ok, I will apply the patch.

> 
> But there is another Problem: I've inserted debug messages
> 
> // USER-PROCESS
> -sh-3.00# ./run -- -t 1 -p 10000 -T 5
> *
> *
> * Type ^C to stop this application.
> *
> *
> Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
> == Sampling period: 10000 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> LATENCY: display send RTTST_RTIOC_TMBENCH_START:
> mode    0
> periode 1
> pri     99
> warmup  1
> hist_s  0
> hist_bs 1000
> fmax    0
> DEBUG: rt_dev_ioctl: request: 1075840528
> warming up...
> DEBUG: rt_dev_ioctl: request: -1070594560
> RTT|  00:00:01  (in-kernel periodic task, 10000 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|      29.369|      32.341|      35.879|       0|      29.369|
> 35.879
> DEBUG: rt_dev_ioctl: request: -1070594560
> RTD|      22.135|      32.381|      36.241|       0|      22.135|
> 36.241
> DEBUG: rt_dev_ioctl: request: -1070594560
> RTD|      21.050|      32.378|      37.326|       0|      21.050|
> 37.326
> DEBUG: rt_dev_ioctl: request: -1070594560
> DEBUG: rt_dev_ioctl: request: -1071118831
> ---|------------|------------|------------|--------|-------------------------
> RTS|-1095770.696|       0.001|      93.660|   93748|
> 00:00:05/00:00:05
> -sh-3.00# 	
> 
> // KERNEL-OUTPUT
> 
> [42949410.980000] KERNEL: rt_tmbench_ioctl_nrt got request 1075840528
> [42949410.990000] KERNEL: rt_tmbench_ioctl_nrt got
> RTTST_RTIOC_TMBENCH_START:
> [42949411.020000] mode    0
> [42949411.020000] periode 10000000
> [42949411.030000] pri     99
> [42949411.040000] warmup  1
> [42949411.050000] hist_s  0
> [42949411.060000] hist_bs 1000
> [42949411.070000] fmax    0
> [42949411.080000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
> [42949411.090000] rt_tmbench_ioctl_nrt: request
> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
> [42949411.120000] rt_tmbench_ioctl_rt -1070594560
> [42949413.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
> [42949413.090000] rt_tmbench_ioctl_nrt: request
> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
> [42949413.120000] rt_tmbench_ioctl_rt -1070594560
> [42949414.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
> [42949414.090000] rt_tmbench_ioctl_nrt: request
> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
> [42949414.120000] rt_tmbench_ioctl_rt -1070594560
> [42949415.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
> [42949415.090000] rt_tmbench_ioctl_nrt: request
> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
> [42949415.120000] rt_tmbench_ioctl_rt -1070594560
> [42949415.290000] KERNEL: rt_tmbench_ioctl_nrt got request -1071118831
> [42949415.310000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
> -ENOTTY(-25)
> 
> 
> 
> The RTTST_RTIOC_INTERM_BENCH_RES request is received by
> rt_tmbench_ioctl_nrt and rt_tmbench_ioctl_rt. Is this normal on arm?
> (on my x86 this happens only at the beginning of a test-run)

Remove your instrumentation printfs from the user space part. They
always switch the task to secondary mode in order to dump the messages.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Gilles Chanteperdrix]

Jan Kiszka wrote:
>>The RTTST_RTIOC_INTERM_BENCH_RES request is received by
>>rt_tmbench_ioctl_nrt and rt_tmbench_ioctl_rt. Is this normal on arm?
>>(on my x86 this happens only at the beginning of a test-run)
> 
> 
> Remove your instrumentation printfs from the user space part. They
> always switch the task to secondary mode in order to dump the messages.

Another reason why latency may switch to secondary mode is the hardware 
FPU emulation. In order to avoid that, if your toolchain is compiling
for hardware floats by default, you should pass CFLAGS=-msoft-float to 
configure.

-- 
                                                  Gilles Chanteperdrix

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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



[-- Attachment #1.2: Forwarded message - Re: [Xenomai-help] Adeos/Xenomai Arm Port --]
[-- Type: message/rfc822, Size: 12121 bytes --]

[-- Attachment #1.2.1.1: Type: text/plain, Size: 11233 bytes --]

On Wed, 2006-10-18 at 14:05 +0200, Gilles Chanteperdrix wrote:

> Some ARMs do not boot when spinlock debugging is enabled, so it would be
> interesting to check if the error also occurs with I-pipe and Xenomai
> off.
> 

You were right!

The kernel with active SPIN_DEBUG and without IPIPE doesn't boot (soft
lockup).

But very interresting: Kernel with SPIN_DEBUG and IPIPE seems to run
normally (with xenomai, but without xenomai apps).

Thanks


###############################################################################

Again Latency:

-sh-3.00#  time ./run -- -t 1 -p 1000 -T 10 
*
*
* Type ^C to stop this application.
*
*
Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/nucleus/xeno_nucleus.ko
Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/native/xeno_native.ko
Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
== Sampling period: 1000 us
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD|      11.680|      16.586|      36.126|       0|      11.680|
36.126
RTD|      11.182|      17.092|      43.947|       0|      11.182|
43.947
RTD|      11.521|      17.091|      65.411|       0|      11.182|
65.411
RTD|      11.981|      17.116|      63.388|       0|      11.182|
65.411
RTD|      11.919|      17.121|      66.767|       0|      11.182|
66.767
RTD|      12.354|      17.178|      42.996|       0|      11.182|
66.767
RTD|      11.884|      17.122|      66.315|       0|      11.182|
66.767
RTD|      11.849|      17.132|      65.287|       0|      11.182|
66.767
RTD|      11.578|      17.093|      66.824|       0|      11.182|
66.824
---|------------|------------|------------|--------|-------------------------
RTS|-1095668.296|       0.001|      93.252|   93340|
00:00:10/00:00:10

real    0m17.730s
user    0m0.840s
sys     0m5.000s
Time is running very slowly while running this test
0m17.730s on target, while 1m6 in reality


kernel-output while running latency:

[42949604.150000] I-pipe: Domain Xenomai registered.
[42949604.160000] Xenomai: hal/arm started.
[42949604.180000] Xenomai: real-time nucleus v2.2.3 (Memories) loaded.
[42949605.050000] Xenomai: starting native API services.
[42949605.860000] Xenomai: starting RTDM services.
[42949607.280000] rt_tmbench_ioctl_rt 1075840528
[42949607.280000] rt_tmbench_ioctl_rt: request
1075840528(RTTST_RTIOC_TMBENCH_START) -> ret = -ENOSYS(-38)
[42949607.320000] KERNEL: rt_tmbench_ioctl_nrt got
RTTST_RTIOC_TMBENCH_START:
[42949607.340000] mode    0
[42949607.350000] periode 1000000
[42949607.360000] pri     99
[42949607.370000] warmup  1
[42949607.370000] hist_s  0
[42949607.380000] hist_bs 1000
[42949607.390000] fmax    0
[42949607.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949607.410000] rt_tmbench_ioctl_rt -1070594560
[42949609.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949609.410000] rt_tmbench_ioctl_rt -1070594560
[42949610.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949610.410000] rt_tmbench_ioctl_rt -1070594560
[42949611.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949611.410000] rt_tmbench_ioctl_rt -1070594560
[42949612.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949612.410000] rt_tmbench_ioctl_rt -1070594560
[42949613.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949613.410000] rt_tmbench_ioctl_rt -1070594560
[42949614.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949614.410000] rt_tmbench_ioctl_rt -1070594560
[42949615.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949615.410000] rt_tmbench_ioctl_rt -1070594560
[42949616.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949616.410000] rt_tmbench_ioctl_rt -1070594560
[42949617.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[42949617.410000] rt_tmbench_ioctl_rt -1070594560
[42949618.250000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
-ENOTTY(-25)
[42949618.660000] Xenomai: stopping RTDM services.
[42949618.740000] Xenomai: stopping native API services.
[42949619.330000] I-pipe: Domain Xenomai unregistered.
[42949619.340000] Xenomai: hal/arm stopped.
[42949619.360000] Xenomai: real-time nucleus unloaded.


-sh-3.00#  time ./run -- -t 1 -T 10 -p 10000
*
*
* Type ^C to stop this application.
*
*
Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/nucleus/xeno_nucleus.ko
Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/native/xeno_native.ko
Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
== Sampling period: 10000 us
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel periodic task, 10000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD|      21.774|      26.435|      34.151|       0|      21.774|
34.151
RTD|      19.050|      26.756|      39.418|       0|      19.050|
39.418
RTD|      19.774|      27.098|      39.938|       0|      19.050|
39.938
RTD|      18.666|      26.861|      38.344|       0|      18.666|
39.938
RTD|      18.282|      26.930|      37.621|       0|      18.282|
39.938
RTD|      19.468|      26.695|      39.599|       0|      18.282|
39.938
RTD|      15.501|      27.011|      38.604|       0|      15.501|
39.938
RTD|      16.270|      26.488|      37.790|       0|      15.501|
39.938
RTD|      17.400|      26.790|      39.621|       0|      15.501|
39.938
---|------------|------------|------------|--------|-------------------------
RTS|-1098666.568|       0.001|      93.252|   93340|
00:00:10/00:00:10

real    0m17.670s
user    0m0.860s
sys     0m5.180s
time is running normally with a periode of 10000

kernel output ... see above




-sh-3.00#  time ./run -- -t 2 -p 1000 -T 10 
*
*
* Type ^C to stop this application.
*
*
Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/nucleus/xeno_nucleus.ko
Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/native/xeno_native.ko
Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
== Sampling period: 1000 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel timer handler, 1000 us period, priority 99)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD|      -9.445|      -6.173|      -4.339|       0|      -9.445|
-4.339
RTD|      -9.445|      -6.169|      -4.349|       0|      -9.445|
-4.339
RTD|      -9.445|      -6.167|      -4.100|       0|      -9.445|
-4.100
RTD|      -9.445|      -6.172|      -3.943|       0|      -9.445|
-3.943
RTD|      -9.445|      -6.164|      -4.157|       0|      -9.445|
-3.943
RTD|      -9.445|      -6.162|      -4.316|       0|      -9.445|
-3.943
RTD|      -9.445|      -6.171|      -4.780|       0|      -9.445|
-3.943
RTD|      -9.445|      -6.170|      -4.078|       0|      -9.445|
-3.943
RTD|      -9.445|      -6.166|      -4.180|       0|      -9.445|
-3.943
---|------------|------------|------------|--------|-------------------------
RTS|-1096483.400|       0.001|      93.252|   93340|
00:00:10/00:00:10

real    0m17.660s
user    0m0.880s
sys     0m5.150s
-sh-3.00# 


kernel-output:

[ 1872.720000] Xenomai: hal/arm started.
[ 1872.740000] Xenomai: real-time nucleus v2.2.3 (Memories) loaded.
[ 1873.600000] Xenomai: starting native API services.
[ 1874.410000] Xenomai: starting RTDM services.
[ 1875.810000] rt_tmbench_ioctl_rt 1075840528
[ 1875.810000] rt_tmbench_ioctl_rt: request
1075840528(RTTST_RTIOC_TMBENCH_START) -> ret = -ENOSYS(-38)
[ 1875.860000] KERNEL: rt_tmbench_ioctl_nrt got
RTTST_RTIOC_TMBENCH_START:
[ 1875.880000] mode    1
[ 1875.880000] periode 1000000
[ 1875.890000] pri     99
[ 1875.900000] warmup  1
[ 1875.910000] hist_s  0
[ 1875.910000] hist_bs 1000
[ 1875.920000] fmax    0
[ 1875.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1875.960000] rt_tmbench_ioctl_rt -1070594560
[ 1877.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1877.960000] rt_tmbench_ioctl_rt -1070594560
[ 1878.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1878.960000] rt_tmbench_ioctl_rt -1070594560
[ 1879.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1879.960000] rt_tmbench_ioctl_rt -1070594560
[ 1880.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1880.960000] rt_tmbench_ioctl_rt -1070594560
[ 1881.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1881.960000] rt_tmbench_ioctl_rt -1070594560
[ 1882.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1882.960000] rt_tmbench_ioctl_rt -1070594560
[ 1883.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1883.960000] rt_tmbench_ioctl_rt -1070594560
[ 1884.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1884.960000] rt_tmbench_ioctl_rt -1070594560
[ 1885.930000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
[ 1885.960000] rt_tmbench_ioctl_rt -1070594560
[ 1886.790000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
-ENOTTY(-25)
[ 1887.190000] Xenomai: stopping RTDM services.
[ 1887.280000] Xenomai: stopping native API services.
[ 1887.860000] I-pipe: Domain Xenomai unregistered.
[ 1887.870000] Xenomai: hal/arm stopped.
[ 1887.890000] Xenomai: real-time nucleus unloaded.

time is running normally in this case





###############################################################################


Another question relating ipipe:
My timer is running with 27648 ticks per jiffy using system-clock
divided by 64, but I'm able to simply use systemclock to get
1769472(27648*64) ticks per jiffy, so the timing-resolution gets finer. 
What do you think about it?





Thanks
	Manfred Schlaegl

[-- Attachment #1.2.1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Jan Kiszka]

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

Schlägl Manfred jun. wrote:
> 
> ------------------------------------------------------------------------
> 
> Betreff:
> Re: [Xenomai-help] Adeos/Xenomai Arm Port
> Von:
> Schlägl "Manfred jun." <manfred.schlaegl@domain.hid>
> Datum:
> Wed, 18 Oct 2006 17:15:09 +0200
> An:
> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> 
> An:
> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> 
> 
> On Wed, 2006-10-18 at 14:05 +0200, Gilles Chanteperdrix wrote:
> 
>> Some ARMs do not boot when spinlock debugging is enabled, so it would be
>> interesting to check if the error also occurs with I-pipe and Xenomai
>> off.
>>
> 
> You were right!
> 
> The kernel with active SPIN_DEBUG and without IPIPE doesn't boot (soft
> lockup).
> 
> But very interresting: Kernel with SPIN_DEBUG and IPIPE seems to run
> normally (with xenomai, but without xenomai apps).
> 
> Thanks
> 
> 
> ###############################################################################
> 
> Again Latency:
> 
> -sh-3.00#  time ./run -- -t 1 -p 1000 -T 10 
> *
> *
> * Type ^C to stop this application.
> *
> *
> Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/nucleus/xeno_nucleus.ko
> Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/native/xeno_native.ko
> Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
> Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
> == Sampling period: 1000 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|      11.680|      16.586|      36.126|       0|      11.680|
> 36.126
> RTD|      11.182|      17.092|      43.947|       0|      11.182|
> 43.947
> RTD|      11.521|      17.091|      65.411|       0|      11.182|
> 65.411
> RTD|      11.981|      17.116|      63.388|       0|      11.182|
> 65.411
> RTD|      11.919|      17.121|      66.767|       0|      11.182|
> 66.767
> RTD|      12.354|      17.178|      42.996|       0|      11.182|
> 66.767
> RTD|      11.884|      17.122|      66.315|       0|      11.182|
> 66.767
> RTD|      11.849|      17.132|      65.287|       0|      11.182|
> 66.767
> RTD|      11.578|      17.093|      66.824|       0|      11.182|
> 66.824
> ---|------------|------------|------------|--------|-------------------------
> RTS|-1095668.296|       0.001|      93.252|   93340|
> 00:00:10/00:00:10

Looks like you forgot to recompile the user space part after applying my
patch. It changes the ABI between the driver and the test tool, so both
sides have to be in sync.

> 
> real    0m17.730s
> user    0m0.840s
> sys     0m5.000s
> Time is running very slowly while running this test
> 0m17.730s on target, while 1m6 in reality
> 

Sounds like Linux is not getting (enough) timer IRQs. Check
/proc/interrupts for progress.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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


> > 
> > Again Latency:
> > 
> > -sh-3.00#  time ./run -- -t 1 -p 1000 -T 10 
> > *
> > *
> > * Type ^C to stop this application.
> > *
> > *
> > Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/nucleus/xeno_nucleus.ko
> > Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/native/xeno_native.ko
> > Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
> > Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
> > == Sampling period: 1000 us
> > == Test mode: in-kernel periodic task
> > == All results in microseconds
> > warming up...
> > RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> > worst
> > RTD|      11.680|      16.586|      36.126|       0|      11.680|
> > 36.126
> > RTD|      11.182|      17.092|      43.947|       0|      11.182|
> > 43.947
> > RTD|      11.521|      17.091|      65.411|       0|      11.182|
> > 65.411
> > RTD|      11.981|      17.116|      63.388|       0|      11.182|
> > 65.411
> > RTD|      11.919|      17.121|      66.767|       0|      11.182|
> > 66.767
> > RTD|      12.354|      17.178|      42.996|       0|      11.182|
> > 66.767
> > RTD|      11.884|      17.122|      66.315|       0|      11.182|
> > 66.767
> > RTD|      11.849|      17.132|      65.287|       0|      11.182|
> > 66.767
> > RTD|      11.578|      17.093|      66.824|       0|      11.182|
> > 66.824
> > ---|------------|------------|------------|--------|-------------------------
> > RTS|-1095668.296|       0.001|      93.252|   93340|
> > 00:00:10/00:00:10
> 
> Looks like you forgot to recompile the user space part after applying my
> patch. It changes the ABI between the driver and the test tool, so both
> sides have to be in sync.
> 

User and Kernel-space are in sync, but i'm using xenomai-2.2.3:

typedef struct rttst_tmbench_config {
    int                     mode;
-   uint64_t                period;
    int                     priority;    
+   uint64_t                period;
    int                     warmup_loops;
    int                     histogram_size;
    int                     histogram_bucketsize;
    int                     freeze_max;
} rttst_tmbench_config_t;

RTTST_RTIOC_TMBENCH_START works

but every RTTST_RTIOC_INTERM_BENCH_RES is received by
rt_tmbench_ioctl_nrt (can't handle this request -> -ENOSYS) and
rt_tmbench_ioctl_rt. is this normal?

[42949607.400000] rt_tmbench_ioctl_nrt: request
-1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)

[42949607.410000] rt_tmbench_ioctl_rt -1070594560


I think i should download the latest working copy...

> > 
> > real    0m17.730s
> > user    0m0.840s
> > sys     0m5.000s
> > Time is running very slowly while running this test
> > 0m17.730s on target, while 1m6 in reality
> > 
> 
> Sounds like Linux is not getting (enough) timer IRQs. Check
> /proc/interrupts for progress.
> 

I know. That's the Problem. But why? ... Too short periode? 
"It's sort of weird."
I'll try to check this tomorrow. 


> Jan
> 

Manfred

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Jan Kiszka]

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

Schlägl Manfred jun. wrote:
>>> Again Latency:
>>>
>>> -sh-3.00#  time ./run -- -t 1 -p 1000 -T 10 
>>> *
>>> *
>>> * Type ^C to stop this application.
>>> *
>>> *
>>> Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/nucleus/xeno_nucleus.ko
>>> Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/native/xeno_native.ko
>>> Using /lib/modules/2.6.15.7/kernel/kernel/xenomai/skins/rtdm/xeno_rtdm.ko
>>> Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
>>> == Sampling period: 1000 us
>>> == Test mode: in-kernel periodic task
>>> == All results in microseconds
>>> warming up...
>>> RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
>>> worst
>>> RTD|      11.680|      16.586|      36.126|       0|      11.680|
>>> 36.126
>>> RTD|      11.182|      17.092|      43.947|       0|      11.182|
>>> 43.947
>>> RTD|      11.521|      17.091|      65.411|       0|      11.182|
>>> 65.411
>>> RTD|      11.981|      17.116|      63.388|       0|      11.182|
>>> 65.411
>>> RTD|      11.919|      17.121|      66.767|       0|      11.182|
>>> 66.767
>>> RTD|      12.354|      17.178|      42.996|       0|      11.182|
>>> 66.767
>>> RTD|      11.884|      17.122|      66.315|       0|      11.182|
>>> 66.767
>>> RTD|      11.849|      17.132|      65.287|       0|      11.182|
>>> 66.767
>>> RTD|      11.578|      17.093|      66.824|       0|      11.182|
>>> 66.824
>>> ---|------------|------------|------------|--------|-------------------------
>>> RTS|-1095668.296|       0.001|      93.252|   93340|
>>> 00:00:10/00:00:10
>> Looks like you forgot to recompile the user space part after applying my
>> patch. It changes the ABI between the driver and the test tool, so both
>> sides have to be in sync.
>>
> 
> User and Kernel-space are in sync, but i'm using xenomai-2.2.3:
> 
> typedef struct rttst_tmbench_config {
>     int                     mode;
> -   uint64_t                period;
>     int                     priority;    
> +   uint64_t                period;
>     int                     warmup_loops;
>     int                     histogram_size;
>     int                     histogram_bucketsize;
>     int                     freeze_max;
> } rttst_tmbench_config_t;
> 
> RTTST_RTIOC_TMBENCH_START works
> 
> but every RTTST_RTIOC_INTERM_BENCH_RES is received by
> rt_tmbench_ioctl_nrt (can't handle this request -> -ENOSYS) and
> rt_tmbench_ioctl_rt. is this normal?

Yes, it is. After each of these real-time-requiring services comes a
printf in the display task of latency. So the task is switch to
secondary mode again and the next RTTST_RTIOC_INTERM_BENCH_RES has to
switch it back.

Maybe the broken output of the latency test summary correlates to the
timer issue, maybe there is just a problem in the data transfer from the
driver to the user space application.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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

Hi!

One problem I had was that I needet to set very high periode-values for
latency and switchbench.
I think I've found a solution.

1. I increased the granularity of the system-timer
I'm using full system-clock für the timer now, instead of
system-clock/64 so now I have 1769472 ticks per jiffy (instead of 27648)

2. There was a wrong value for CLOCK_TICK_RATE in timex.h I think.
It was set to 50000000 / 16 (by netsilicon), but it should be the hw
clock frequency (http://arm.nihilisme.ca/doc/aleph.pdf )
CLOCK_TICK_RATE is now set to 176947200.

Results:
I'm able to pass Periods about 200us and lower to latency and
switchbench now.



But the Problem with Latency-Test with in-kernel periodic tasks and
in-kernel timer handler exists further.

ioctl RTTST_RTIOC_INTERM_BENCH_RES is sent once in userspace
and received twice (by rt_tmbench_ioctl_rt and
rt_tmbench_ioctl_nrt) ... 
There is no such behavior on my x86 running these tests.

Now i'll try to check the communication between the rt-driver and the
userspace now and will report my results.


Greets
	Manfred



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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

On Wed, 2006-10-18 at 14:24 +0200, Schlägl Manfred jun. wrote:
> On Wed, 2006-10-18 at 12:35 +0200, Jan Kiszka wrote:
> 
> > I vote for solution 4:
> > 
> > --- include/rtdm/rttesting.h    (revision 1731)
> > +++ include/rtdm/rttesting.h    (working copy)
> > @@ -85,8 +85,8 @@ typedef struct rttst_overall_bench_res {
> > 
> >  typedef struct rttst_tmbench_config {
> >      int                     mode;
> > -    nanosecs_rel_t          period;
> >      int                     priority;
> > +    nanosecs_rel_t          period;
> >      int                     warmup_loops;
> >      int                     histogram_size;
> >      int                     histogram_bucketsize;
> > 
> > Could you check if this helps?
> > 
> > Thanks,
> > Jan
> > 
> 
> 
> Thanks! It works. ioctls are working
> 
> But there is another Problem: I've inserted debug messages
> 
> // USER-PROCESS
> -sh-3.00# ./run -- -t 1 -p 10000 -T 5
> *
> *
> * Type ^C to stop this application.
> *
> *
> Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
> == Sampling period: 10000 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> LATENCY: display send RTTST_RTIOC_TMBENCH_START:
> mode    0
> periode 1
> pri     99
> warmup  1
> hist_s  0
> hist_bs 1000
> fmax    0
> DEBUG: rt_dev_ioctl: request: 1075840528
> warming up...
> DEBUG: rt_dev_ioctl: request: -1070594560
> RTT|  00:00:01  (in-kernel periodic task, 10000 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|      29.369|      32.341|      35.879|       0|      29.369|
> 35.879
> DEBUG: rt_dev_ioctl: request: -1070594560
> RTD|      22.135|      32.381|      36.241|       0|      22.135|
> 36.241
> DEBUG: rt_dev_ioctl: request: -1070594560
> RTD|      21.050|      32.378|      37.326|       0|      21.050|
> 37.326
> DEBUG: rt_dev_ioctl: request: -1070594560
> DEBUG: rt_dev_ioctl: request: -1071118831
> ---|------------|------------|------------|--------|-------------------------
> RTS|-1095770.696|       0.001|      93.660|   93748|
> 00:00:05/00:00:05
> -sh-3.00# 	
> 
> // KERNEL-OUTPUT
> 
> [42949410.980000] KERNEL: rt_tmbench_ioctl_nrt got request 1075840528
> [42949410.990000] KERNEL: rt_tmbench_ioctl_nrt got
> RTTST_RTIOC_TMBENCH_START:
> [42949411.020000] mode    0
> [42949411.020000] periode 10000000
> [42949411.030000] pri     99
> [42949411.040000] warmup  1
> [42949411.050000] hist_s  0
> [42949411.060000] hist_bs 1000
> [42949411.070000] fmax    0
> [42949411.080000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
> [42949411.090000] rt_tmbench_ioctl_nrt: request
> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
> [42949411.120000] rt_tmbench_ioctl_rt -1070594560
> [42949413.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
> [42949413.090000] rt_tmbench_ioctl_nrt: request
> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
> [42949413.120000] rt_tmbench_ioctl_rt -1070594560
> [42949414.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
> [42949414.090000] rt_tmbench_ioctl_nrt: request
> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
> [42949414.120000] rt_tmbench_ioctl_rt -1070594560
> [42949415.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
> [42949415.090000] rt_tmbench_ioctl_nrt: request
> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
> [42949415.120000] rt_tmbench_ioctl_rt -1070594560
> [42949415.290000] KERNEL: rt_tmbench_ioctl_nrt got request -1071118831
> [42949415.310000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
> -ENOTTY(-25)
> 
> 
> 
> The RTTST_RTIOC_INTERM_BENCH_RES request is received by
> rt_tmbench_ioctl_nrt and rt_tmbench_ioctl_rt. Is this normal on arm?
> (on my x86 this happens only at the beginning of a test-run)
> 
> 
> Thank you
> 	Manfred Schlaegl
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


Like above i had a problem using RTTST_RTIOC_TMBENCH_STOP too.


typedef struct rttst_bench_res {
    long long               avg;
    long                    min;
    long                    max;
    long                    overruns;
    long                    test_loops;
} rttst_bench_res_t;

typedef struct rttst_overall_bench_res {
    struct rttst_bench_res  result;
    long                    *histogram_avg;
    long                    *histogram_min;
    long                    *histogram_max;
} rttst_overall_bench_res_t;



sizeof(struct rttst_bench_res):
Kernel	24
User	24

sizeof(struct rttst_overall_bench_res):
Kernel	36
User	40


I used this Patch:

typedef struct rttst_overall_bench_res {
    struct rttst_bench_res  result;
+   char                    __fill;	/* fill byte */
    long                    *histogram_avg;
    long                    *histogram_min;
    long                    *histogram_max;
} rttst_overall_bench_res_t;

sizeof(struct rttst_overall_bench_res):
Kernel	40
User	40




	- Manfred

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Jan Kiszka]

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

Schlägl Manfred jun. wrote:
> On Wed, 2006-10-18 at 14:24 +0200, Schlägl Manfred jun. wrote:
>> On Wed, 2006-10-18 at 12:35 +0200, Jan Kiszka wrote:
>>
>>> I vote for solution 4:
>>>
>>> --- include/rtdm/rttesting.h    (revision 1731)
>>> +++ include/rtdm/rttesting.h    (working copy)
>>> @@ -85,8 +85,8 @@ typedef struct rttst_overall_bench_res {
>>>
>>>  typedef struct rttst_tmbench_config {
>>>      int                     mode;
>>> -    nanosecs_rel_t          period;
>>>      int                     priority;
>>> +    nanosecs_rel_t          period;
>>>      int                     warmup_loops;
>>>      int                     histogram_size;
>>>      int                     histogram_bucketsize;
>>>
>>> Could you check if this helps?
>>>
>>> Thanks,
>>> Jan
>>>
>>
>> Thanks! It works. ioctls are working
>>
>> But there is another Problem: I've inserted debug messages
>>
>> // USER-PROCESS
>> -sh-3.00# ./run -- -t 1 -p 10000 -T 5
>> *
>> *
>> * Type ^C to stop this application.
>> *
>> *
>> Using /lib/modules/2.6.15.7/kernel/drivers/xenomai/testing/xeno_timerbench.ko
>> == Sampling period: 10000 us
>> == Test mode: in-kernel periodic task
>> == All results in microseconds
>> LATENCY: display send RTTST_RTIOC_TMBENCH_START:
>> mode    0
>> periode 1
>> pri     99
>> warmup  1
>> hist_s  0
>> hist_bs 1000
>> fmax    0
>> DEBUG: rt_dev_ioctl: request: 1075840528
>> warming up...
>> DEBUG: rt_dev_ioctl: request: -1070594560
>> RTT|  00:00:01  (in-kernel periodic task, 10000 us period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
>> worst
>> RTD|      29.369|      32.341|      35.879|       0|      29.369|
>> 35.879
>> DEBUG: rt_dev_ioctl: request: -1070594560
>> RTD|      22.135|      32.381|      36.241|       0|      22.135|
>> 36.241
>> DEBUG: rt_dev_ioctl: request: -1070594560
>> RTD|      21.050|      32.378|      37.326|       0|      21.050|
>> 37.326
>> DEBUG: rt_dev_ioctl: request: -1070594560
>> DEBUG: rt_dev_ioctl: request: -1071118831
>> ---|------------|------------|------------|--------|-------------------------
>> RTS|-1095770.696|       0.001|      93.660|   93748|
>> 00:00:05/00:00:05
>> -sh-3.00# 	
>>
>> // KERNEL-OUTPUT
>>
>> [42949410.980000] KERNEL: rt_tmbench_ioctl_nrt got request 1075840528
>> [42949410.990000] KERNEL: rt_tmbench_ioctl_nrt got
>> RTTST_RTIOC_TMBENCH_START:
>> [42949411.020000] mode    0
>> [42949411.020000] periode 10000000
>> [42949411.030000] pri     99
>> [42949411.040000] warmup  1
>> [42949411.050000] hist_s  0
>> [42949411.060000] hist_bs 1000
>> [42949411.070000] fmax    0
>> [42949411.080000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
>> [42949411.090000] rt_tmbench_ioctl_nrt: request
>> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
>> [42949411.120000] rt_tmbench_ioctl_rt -1070594560
>> [42949413.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
>> [42949413.090000] rt_tmbench_ioctl_nrt: request
>> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
>> [42949413.120000] rt_tmbench_ioctl_rt -1070594560
>> [42949414.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
>> [42949414.090000] rt_tmbench_ioctl_nrt: request
>> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
>> [42949414.120000] rt_tmbench_ioctl_rt -1070594560
>> [42949415.070000] KERNEL: rt_tmbench_ioctl_nrt got request -1070594560
>> [42949415.090000] rt_tmbench_ioctl_nrt: request
>> -1070594560(RTTST_RTIOC_INTERM_BENCH_RES) -> ret = -ENOSYS(-38)
>> [42949415.120000] rt_tmbench_ioctl_rt -1070594560
>> [42949415.290000] KERNEL: rt_tmbench_ioctl_nrt got request -1071118831
>> [42949415.310000] rt_tmbench_ioctl_nrt: request -1071118831 -> ret =
>> -ENOTTY(-25)
>>
>>
>>
>> The RTTST_RTIOC_INTERM_BENCH_RES request is received by
>> rt_tmbench_ioctl_nrt and rt_tmbench_ioctl_rt. Is this normal on arm?
>> (on my x86 this happens only at the beginning of a test-run)
>>
>>
>> Thank you
>> 	Manfred Schlaegl
>>
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
> 
> 
> Like above i had a problem using RTTST_RTIOC_TMBENCH_STOP too.
> 
> 
> typedef struct rttst_bench_res {
>     long long               avg;
>     long                    min;
>     long                    max;
>     long                    overruns;
>     long                    test_loops;
> } rttst_bench_res_t;
> 
> typedef struct rttst_overall_bench_res {
>     struct rttst_bench_res  result;
>     long                    *histogram_avg;
>     long                    *histogram_min;
>     long                    *histogram_max;
> } rttst_overall_bench_res_t;
> 
> 
> 
> sizeof(struct rttst_bench_res):
> Kernel	24
> User	24
> 
> sizeof(struct rttst_overall_bench_res):
> Kernel	36
> User	40
> 
> 
> I used this Patch:
> 
> typedef struct rttst_overall_bench_res {
>     struct rttst_bench_res  result;
> +   char                    __fill;	/* fill byte */
>     long                    *histogram_avg;
>     long                    *histogram_min;
>     long                    *histogram_max;
> } rttst_overall_bench_res_t;
> 
> sizeof(struct rttst_overall_bench_res):
> Kernel	40
> User	40
> 

Damn it. What alignment of the compiler is behind this? Fill up to
multiples of X bytes, ok. But how to find out what X is on some
platform? Anyone any hint on this?

Thanks for tracking down.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [Xenomai-help] Adeos/Xenomai Arm Port

[Schlägl Manfred jun.]

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


> Damn it. What alignment of the compiler is behind this? Fill up to
> multiples of X bytes, ok. But how to find out what X is on some
> platform? Anyone any hint on this?
> 
> Thanks for tracking down.
> 
> Jan
> 

I've found it:

The Kernel is compiled with -mabi=apcs-gnu

With this flag
typedef struct test1 {
    int                     mode;
    unsigned long long      period;
    int                     priority;
    int                     warmup_loops;
    int                     histogram_size;
    int                     histogram_bucketsize;
    int                     freeze_max;
} test1_t;
With flag 	-> size = 32
Without flag 	-> size = 40

I'll try to find a solution.

	- Manfred

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]