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

[Philippe Gerum <rpm@xenomai.org>]

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.