From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 14 Mar 2007 05:51:33 -0700 (PDT) From: poornima r Subject: Re: [Adeos-main] test results for switchtest and cyclictest on x86 In-Reply-To: <45DBF120.2040202@domain.hid> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1520790537-1173876693=:46909" Content-Transfer-Encoding: 8bit Message-ID: <696883.46909.qm@domain.hid> List-Id: General discussion about Adeos List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wolfgang Grandegger Cc: adeos-main@gna.org --0-1520790537-1173876693=:46909 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, There were the results for cyclictest and switchbench test results run on X86 (without load) System specifications:- Xenomai: xenomai-2.3.0 Linux kernel: linux-2.6.19.3 CPU speed : 2.79GHz Cache: 512KB a) Switchtest:- Results: ./switchtest -T 50 -n rtk rtup rtus (-T:limit of test duration i.e 50 seconds -n:disables any use of FPU instructions. threadspec:rtk i.e kernel-space realtime thread ,rtup i.e for a user-space real-time thread running in primary mode,rtus i.e user-space real-time thread running in secondary mode) RTT| 00:00:01 RTH|ctx switches|-------total RTD| 1000| 1000 RTD| 1004| 2004 RTD| 1002| 3006 RTD| 1006| 4012 RTD| 1004| 5016 RTD| 1002| 6018 RTD| 1006| 7024 RTD| 998| 8022 RTD| 1006| 9028 RTD| 1004| 10032 RTD| 516| 10548 RTD| 504| 11052 RTD| 504| 11556 RTD| 504| 12060 RTD| 504| 12564 RTD| 504| 13068 RTD| 504| 13572 RTD| 504| 14076 RTD| 504| 14580 RTD| 504| 15084 RTD| 504| 15588 RTT| 00:00:22 RTH|ctx switches|-------total RTD| 510| 16098 RTD| 846| 16944 RTD| 996| 17940 RTD| 1002| 18942 RTD| 996| 19938 RTD| 1006| 20944 RTD| 1004| 21948 RTD| 1000| 22948 RTD| 1004| 23952 RTD| 1002| 24954 RTD| 1006| 25960 RTD| 1004| 26964 RTD| 1002| 27966 RTD| 1006| 28972 RTD| 1004| 29976 RTD| 1002| 30978 RTD| 1006| 31984 RTD| 998| 32982 RTD| 1006| 33988 RTD| 1004| 34992 RTD| 1002| 35994 RTT| 00:00:43 RTH|ctx switches|-------total RTD| 1002| 36996 RTD| 1002| 37998 RTD| 1006| 39004 RTD| 1004| 40008 RTD| 1002| 41010 RTD| 1002| 42012 RTD| 1002| 43014 RTD| 790| 43804 Total no of context switches between kernel-space realtime thread ,user-space real-time thread running in primary mode and user-space real-time thread running in secondary mode is 43804. b)cyclictest:- Results:- ./cyclictest -l 100 0.59 0.13 0.06 1/99 25688 T: 0 (25688) P:99 I: 1000 C: 100 Min: 7 Act: 7 Avg: 9 Max: 24 1) Please comment on these results. 2) What are we benchmarking from the above cyclictest result? Thanks and Regards, Poornima Wolfgang Grandegger wrote: Hello, poornima r wrote: > Hello, > > These were the scheduling latency and interrupt > latency test results on ppc and x86 with IPIPE tracer > option disabled. > > 1.Please comment on these results (whether valid) and Your results are OK. These are actually the figures I remember from my own tests in the past. > 2.Is there any method to optimize these results. No that I know of. There are a few ideas how to reduce latencies further like cache locking or TLB pinning. > 1)PPC:- > (MPC-860 at 48 MHz, 4 kB I-Cache and 4 kB D-Cache) > > User mode:- > root@domain.hid# ./latency -t0 > == Sampling period: 1000000 us > == Test mode: periodic user-mode task > == All results in microseconds > warming up... > RTT| 00:00:01 (periodic user-mode task, 1000000 us > period, priority 99) > RTH|-----lat min|-----lat > avg|-----latmax|-overrun|----lat best|---lat worst > RTD| 167.000| 167.000| 167.000| 0| > 167.000| 167.000 > RTD| 176.000| 176.000| 176.000| 0| > 167.000| 176.000 > RTD| 168.000| 168.000| 168.000| 0| > 167.000| 176.000 > RTD| 171.000| 171.000| 171.000| 0| > 167.000| 176.000 > > Kernel mode:- > root@domain.hid# ./latency -t1 > == Sampling period: 1000000 us > == Test mode: in-kernel periodic task > == All results in microseconds > warming up... > RTT| 00:00:00 (in-kernel periodic task, 1000000 us > period, priority 99) > RTH|-----lat min|-----lat > avg|-----latmax|-overrun|----lat best|---lat worst > RTD| 123.000| 123.000| 123.000| 0| > 123.000| 123.000 > RTD| 125.000| 125.000| 125.000| 0| > 123.000| 125.000 > RTD| 128.333| 128.333| 128.333| 0| > 123.000| 128.333 > RTD| 127.000| 127.000| 127.000| 0| > 123.000| 128.333 > > Interrupt mode:- > root@domain.hid# ./latency -t2 > == Sampling period: 1000000 us > == Test mode: in-kernel timer handler > == All results in microseconds > warming up... > RTT| 00:00:01 (in-kernel timer handler, 1000000 us > period, priority 99) > RTH|-----lat min|-----lat > avg|-----latmax|-overrun|----lat best|---lat worst > RTD| 45.334| 45.334| 45.334| 0| > 45.334| 45.334 > RTD| 45.000| 45.000| 45.000| 0| > 45.000| 45.334 > RTD| 46.000| 46.000| 46.000| 0| > 45.000| 46.000 > RTD| 47.334| 47.334| 47.334| 0| > 45.000| 47.334 > RTD| 46.334| 46.334| 46.334| 0| > 45.000| 47.334 On the MPC860, the latencies are mainly due code execution time as this processor is very slow. > 2)X86:- > (Pentium4, 3.06GHz, 1024 KB cache size) > User mode:- > Sampling period: 100 us > == Test mode: in-kernel periodic task > == All results in microseconds > warming up... > > RTT| 00:00:01 (periodic user-mode task, 100 us > period, priority 99) > RTH|-----lat min|-----lat avg|-----lat > max|-overrun|----lat best|---lat worst > RTD| 3.807| 12.825| 21.565| 0| > 3.807| 21.565 > RTD| 3.796| 12.792| 21.483| 0| > 3.796| 21.565 > RTD| 3.770| 12.799| 21.501| 0| > 3.770| 21.565 > RTD| 3.578| 12.806| 20.890| 0| > 3.578| 21.565 > RTD| 3.755| 12.809| 21.486| 0| > 3.578| > > kernel mode:- > Sampling period: 100 us > == Test mode: in-kernel periodic task > == All results in microseconds > warming up... > > RTT| 00:00:01 (in-kernel periodic task, 100 us > period, priority 99) > RTH|-----lat min|-----lat avg|-----lat > max|-overrun|----lat best|---lat worst > RTD| 2.381| 3.451| 19.620| 0| > 2.381| 19.620 > RTD| 2.332| 3.480| 19.930| 0| > 2.332| 19.930 > RTD| 2.382| 3.649| 19.609| 0| > 2.332| 19.930 > RTD| 2.323| 2.786| 14.351| 0| > 2.323| 19.930 > RTD| 2.375| 2.532| 5.519| 0| > 2.323| 19.930 > RTD| 2.332| 3.971| 19.617| 0| > 2.323| 19.930 > > Interrupt mode:- > Sampling period: 100 us > == Test mode: in-kernel timer handler > == All results in microseconds > warming up... > > RTT| 00:00:01 (in-kernel timer handler, 100 us > period, priority 99) > RTH|-----lat min|-----lat avg|-----lat > max|-overrun|----lat best|---lat worst > RTD| -1.563| 7.553| 15.736| 0| > -1.563| 15.736 > RTD| -1.579| 7.558| 15.804| 0| > -1.579| 15.804 > RTD| -1.584| 7.529| 16.167| 0| > -1.584| 16.167 > RTD| -1.548| 7.553| 16.186| 0| > -1.584| 16.186 > RTD| -1.585| 7.556| 16.275| 0| > -1.585| 16.275 Latencies are mainly due to cache refills on the P4. Have you already put load onto your system? If not, worst case latencies will be even longer. Wolfgang. > Thanks, > Poornima > > > --- Wolfgang Grandegger wrote: > >> Hello, >> >> poornima r wrote: >>> Hello, >>> >>> Srry for not replying all these days... >>> (Was not in in station, may be too personal!!!!!) >>> >>> About software emulation error: >>> >>> 4)Output of /proc/xenomai/faults after the illegal >>>>> instruction:- >>>>> root@domain.hid# cat >>>>> /proc/xenomai/faults >>>>> TRAP CPU0 >>>>> 0: 0 (Data or instruction >> access) >>>>> 1: 0 (Alignment) >>>>> 2: 0 (Altivec unavailable) >>>>> 3: 0 (Program check exception) >>>>> 4: 0 (Machine check exception) >>>>> 5: 0 (Unknown) >>>>> 6: 0 (Instruction breakpoint) >>>>> 7: 0 (Run mode exception) >>>>> 8: 0 (Single-step exception) >>>>> 9: 0 (Non-recoverable exception) >>>>> 10: 1 (Software emulation) >>>>> 11: 0 (Debug) >>>>> 12: 0 (SPE) >>>>> 13: 0 (Altivec assist) >>>> Hm, I see a software emulation exception which is >>>> also the reason for >>>> the illegal instructions. What toolchain do you >> use? >>>> The toolchain >>>> should support software FP emulation. >>> 1)I am using open source too chain with software >>> floating point emulation support. >>> (#ppc_8xx-gcc --v >>> > /lib/gcc/powerpc/3.4.3/../../../../target_powerpc/usr/include/c++/3.4.3 >>> --with-numa-policy=no --with-float=soft) >>> >>> 2)And the kernel is included with code to emulate >> a >>> floating-point >> >>> unit, which will allow programs that >>> use floating-point >> >>> instructions to run >>> >>> Kernel configuration >>> ----CONFIG_MATH_EMULATION:y >> If you build with "--with-float=soft" there is no >> need for math >> emulation in the kernel. Likely, there is something >> wrong with your >> tool-chain. Could you please try a known-to-work >> tool-chain like the >> ELDK v4.x from http://www.denx.de. >> >> Wolfgang. >> >>> Thanks, >>> Poornima >>> >>> --- Wolfgang Grandegger wrote: >>> >>>> poornima r wrote: >>>>> Hi, >>>>> >>>>> 1)I am using open source kernel from Kernel.org, >>>>> but what is meant by vanilla kernel from >>>> Kernel.org? >>>> >>>> It's the kernel from kernel.org. This means that >> the >>>> Linux kernel 2.6.18 >>>> is running fine on your MPC860 platform as is? >>>> Thanks for the info. >>>> >>>>> 2)With sampling period of 500usec the system >>>> simply >>>>> hangs without printing any results (./latenct >>>> -p500) >>>> >>>> OK. >>>> >>>>> 3)cyclictest with -t1 option (without >>>> IPIPE-tracer) >>>>> root@domain.hid# >> ./cyclictest >>>> -t1 >>>>> 2.04 0.50 0.17 8/27 174 >>>>> >>>>> T: 0 ( 0) P:99 I: 1000 C: 0 Min: >>>> 1000000 >>>>> Act: 0 Avg: 0 Max:-1000000 >>>>> Illegal instruction >>>>> >>>>> 4)Output of /proc/xenomai/faults after the >> illegal >>>>> instruction:- >>>>> root@domain.hid# cat >>>>> /proc/xenomai/faults >>>>> TRAP CPU0 >>>>> 0: 0 (Data or instruction >> access) >>>>> 1: 0 (Alignment) >>>>> 2: 0 (Altivec unavailable) >>>>> 3: 0 (Program check exception) >>>>> 4: 0 (Machine check exception) >>>>> 5: 0 (Unknown) >>>>> 6: 0 (Instruction breakpoint) >>>>> 7: 0 (Run mode exception) >>>>> 8: 0 (Single-step exception) >>>>> 9: 0 (Non-recoverable exception) >>>>> 10: 1 (Software emulation) >>>>> 11: 0 (Debug) >>>>> 12: 0 (SPE) >>>>> 13: 0 (Altivec assist) >>>> Hm, I see a software emulation exception which is >>>> also the reason for >>>> the illegal instructions. What toolchain do you >> use? >>>> The toolchain >>>> should support software FP emulation. >>>> >>>>> 5)Running switchtest:- >>>>> root@domain.hid# >> ./switchtest >>>> -n >>>>> --The system hangs wihtout printing any results >>>>> >>>>> Thanks, >>>>> Poornima >>>>> >>>>> >>>>> --- Wolfgang Grandegger >> wrote: >>>>>> poornima r wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thanks for the reply. >>>>>>> >>>>>>> Linux version:linux-2.6.18 >>>>>>> Xenomai: xenomai-2.3.0 (Stable version) >>>>>>> adeos patch: >> adeos-ipipe-2.6.18-ppc-1.5-01.patch >>>>>> OK, I'm curious, did you use the vanilla kernel >>>> from >>>>>> kernel.org? >>>>>> More comments below. >>>>>> >>>>>>> The tests were run as follows: >>>>>>> 1)The sampling period in the code for latency >>>> and >>>>>>> switchbench was changed to 1000000000ns(to >>>> remove >>>>>>> overrun error) >>>>>>> 2)switchtest was run with -n5 option >>>>>>> 3)cyclictest was run with -t5 option(5 >> threads >>>>>>> were created.) >>>>>>> 4)cyclictest was terminated with Illegal >>>>>> instruction >>>>>>> (after creating 5 threads) with IPIPE tracer >>>>>> enabled. >>>>>> >>>>>>> These were the results without I-PIPE Tracer >>>>>> option: >>>>>>> (All the tests were run without any load) >>>>>>> 1)LATENCY TEST:- >>>>>>> User mode:- >>>>>>> /mnt/out_xen/bin# ./latency -t0 >>>>>>> == Sampling period: 1000000 us >>>>>>> == Test mode: periodic user-mode task >>>>>>> == All results in microseconds >>>>>>> warming up... >>>>>>> RTT| 00:00:01 (periodic user-mode task, >>>> 1000000 >>>>>> us >>>>>>> period, priority 99) >>>>>>> RTH|-----lat min|-----lat avg|-----lat >>>>>>> max|-overrun|----lat best|---lat worst >>>>>>> RTD| 167.000| 167.000| 167.000| >> >>>>>> 0| >>>>>>> 167.000| 167.000 >>>>>>> RTD| 176.000| 176.000| 176.000| >> >>>>>> 0| >>>>>>> 167.000| 176.000 >>>>>>> RTD| 168.000| 168.000| 168.000| >> >>>>>> 0| >>>>>>> 167.000| 176.000 > === message truncated === > > > > > ____________________________________________________________________________________ > Get your own web address. > Have a HUGE year through Yahoo! Small Business. > http://smallbusiness.yahoo.com/domains/?p=BESTDEAL > > _______________________________________________ > Adeos-main mailing list > Adeos-main@domain.hid > https://mail.gna.org/listinfo/adeos-main > > --------------------------------- Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. --------------------------------- Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. --0-1520790537-1173876693=:46909 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
 
There were the results for cyclictest and switchbench test results run on X86
(without load)
 
System specifications:-
Xenomai: xenomai-2.3.0
Linux kernel: linux-2.6.19.3
CPU speed : 2.79GHz
Cache: 512KB

 
a) Switchtest:-
 
Results:
 
./switchtest -T 50 -n rtk rtup rtus
(-T:limit of test duration i.e 50 seconds
-n:disables any use of FPU instructions.
threadspec:rtk i.e kernel-space realtime thread ,rtup i.e for a user-space real-time thread running in primary mode,rtus i.e user-space real-time thread running in secondary mode)
 
RTT| 00:00:01
RTH|ctx switches|-------total
RTD| 1000| 1000
RTD| 1004| 2004
RTD| 1002| 3006
RTD| 1006| 4012
RTD| 1004| 5016
RTD| 1002| 6018
RTD| 1006| 7024
RTD| 998| 8022
RTD| 1006| 9028
RTD| 1004| 10032
RTD| 516| 10548
RTD| 504| 11052
RTD| 504| 11556
RTD| 504| 12060
RTD| 504| 12564
RTD| 504| 13068
RTD| 504| 13572
RTD| 504| 14076
RTD| 504| 14580
RTD| 504| 15084
RTD| 504| 15588
RTT| 00:00:22
RTH|ctx switches|-------total
RTD| 510| 16098
RTD| 846| 16944
RTD| 996| 17940
RTD| 1002| 18942
RTD| 996| 19938
RTD| 1006| 20944
RTD| 1004| 21948
RTD| 1000| 22948
RTD| 1004| 23952
RTD| 1002| 24954
RTD| 1006| 25960
RTD| 1004| 26964
RTD| 1002| 27966
RTD| 1006| 28972
RTD| 1004| 29976
RTD| 1002| 30978
RTD| 1006| 31984
RTD| 998| 32982
RTD| 1006| 33988
RTD| 1004| 34992
RTD| 1002| 35994
RTT| 00:00:43
RTH|ctx switches|-------total
RTD| 1002| 36996
RTD| 1002| 37998
RTD| 1006| 39004
RTD| 1004| 40008
RTD| 1002| 41010
RTD| 1002| 42012
RTD| 1002| 43014
RTD| 790| 43804
 
Total no of context switches between kernel-space realtime thread ,user-space real-time
thread running in primary mode and user-space real-time thread running in secondary mode is 43804.
 
b)cyclictest:-
 
Results:-
 
./cyclictest -l 100
0.59 0.13 0.06 1/99 25688
T: 0 (25688) P:99 I: 1000 C: 100 Min: 7 Act: 7 Avg: 9 Max: 24
 
1) Please comment on these results.
2) What are we benchmarking from the above cyclictest result?
 
Thanks and Regards,
Poornima
 
 
 
 
Wolfgang Grandegger <wg@domain.hid> wrote:
Hello,

poornima r wrote:
> Hello,
>
> These were the scheduling latency and interrupt
> latency test results on ppc and x86 with IPIPE tracer
> option disabled.
>
> 1.Please comment on these results (whether valid) and

Your results are OK. These are actually the figures I remember from my
own tests in the past.

> 2.Is there any method to optimize these results.

No that I know of. There are a few ideas how to reduce latencies further
like cache locking or TLB pinning.

> 1)PPC:-
> (MPC-860 at 48 MHz, 4 kB I-Cache and 4 kB D-Cache)
>
> User mode:-
> root@domain.hid# ./latency -t0
> == Sampling period: 1000000 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (periodic user-mode task, 1000000 us
> period, priority 99)
> RTH|-----lat min|-----lat
> avg|-----latmax|-overrun|----lat best|---lat worst
> RTD| 167.000| 167.000| 167.000| 0|
> 167.000| 167.000
> RTD| 176.000| 176.000| 176.000| 0|
> 167.000| 176.000
> RTD| 168.000| 168.000| 168.000| 0|
> 167.000| 176.000
> RTD| 171.000| 171.000| 171.000| 0|
> 167.000| 176.000
>
> Kernel mode:-
> root@domain.hid# ./latency -t1
> == Sampling period: 1000000 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> RTT| 00:00:00 (in-kernel periodic task, 1000000 us
> period, priority 99)
> RTH|-----lat min|-----lat
> avg|-----latmax|-overrun|----lat best|---lat worst
> RTD| 123.000| 123.000| 123.000| 0|
> 123.000| 123.000
> RTD| 125.000| 125.000| 125.000| 0|
> 123.000| 125.000
> RTD| 128.333| 128.333| 128.333| 0|
> 123.000| 128.333
> RTD| 127.000| 127.000| 127.000| 0|
> 123.000| 128.333
>
> Interrupt mode:-
> root@domain.hid# ./latency -t2
> == Sampling period: 1000000 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (in-kernel timer handler, 1000000 us
> period, priority 99)
> RTH|-----lat min|-----lat
> avg|-----latmax|-overrun|----lat best|---lat worst
> RTD| 45.334| 45.334| 45.334| 0|
> 45.334| 45.334
> RTD| 45.000| 45.000| 45.000| 0|
> 45.000| 45.334
> RTD| 46.000| 46.000| 46.000| 0|
> 45.000| 46.000
> RTD| 47.334| 47.334| 47.334| 0|
> 45.000| 47.334
> RTD| 46.334| 46.334| 46.334| 0|
> 45.000| 47.334

On the MPC860, the latencies are mainly due code execution time as this
processor is very slow.

> 2)X86:-
> (Pentium4, 3.06GHz, 1024 KB cache size)
> User mode:-
> Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
>
> RTT| 00:00:01 (periodic user-mode task, 100 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD| 3.807| 12.825| 21.565| 0|
> 3.807| 21.565
> RTD| 3.796| 12.792| 21.483| 0|
> 3.796| 21.565
> RTD| 3.770| 12.799| 21.501| 0|
> 3.770| 21.565
> RTD| 3.578| 12.806| 20.890| 0|
> 3.578| 21.565
> RTD| 3.755| 12.809| 21.486| 0|
> 3.578|
>
> kernel mode:-
> Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
>
> RTT| 00:00:01 (in-kernel periodic task, 100 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD| 2.381| 3.451| 19.620| 0|
> 2.381| 19.620
> RTD| 2.332| 3.480| 19.930| 0|
> 2.332| 19.930
> RTD| 2.382| 3.649| 19.609| 0|
> 2.332| 19.930
> RTD| 2.323| 2.786| 14.351| 0|
> 2.323| 19.930
> RTD| 2.375| 2.532| 5.519| 0|
> 2.323| 19.930
> RTD| 2.332| 3.971| 19.617| 0|
> 2.323| 19.930
>
> Interrupt mode:-
> Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
>
> RTT| 00:00:01 (in-kernel timer handler, 100 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD| -1.563| 7.553| 15.736| 0|
> -1.563| 15.736
> RTD| -1.579| 7.558| 15.804| 0|
> -1.579| 15.804
> RTD| -1.584| 7.529| 16.167| 0|
> -1.584| 16.167
> RTD| -1.548| 7.553| 16.186| 0|
> -1.584| 16.186
> RTD| -1.585| 7.556| 16.275| 0|
> -1.585| 16.275

Latencies are mainly due to cache refills on the P4. Have you already
put load onto your system? If not, worst case latencies will be even longer.

Wolfgang.

> Thanks,
> Poornima
>
>
> --- Wolfgang Grandegger wrote:
>
>> Hello,
>>
>> poornima r wrote:
>>> Hello,
>>>
>>> Srry for not replying all these days...
>>> (Was not in in station, may be too personal!!!!!)
>>>
>>> About software emulation error:
>>>
>>> 4)Output of /proc/xenomai/faults after the illegal
>>>>> instruction:-
>>>>> root@domain.hid# cat
>>>>> /proc/xenomai/faults
>>>>> TRAP CPU0
>>>>> 0: 0 (Data or instruction
>> access)
>>>>> 1: 0 (Alignment)
>>>>> 2: 0 (Altivec unavailable)
>>>>> 3: 0 (Program check exception)
>>>>> 4: 0 (Machine check exception)
>>>>> 5: 0 (Unknown)
>>>>> 6: 0 (Instruction breakpoint)
>>>>> 7: 0 (Run mode exception)
>>>>> 8: 0 (Single-step exception)
>>>>> 9: 0 (Non-recoverable exception)
>>>>> 10: 1 (Software emulation)
>>>>> 11: 0 (Debug)
>>>>> 12: 0 (SPE)
>>>>> 13: 0 (Altivec assist)
>>>> Hm, I see a software emulation exception which is
>>>> also the reason for
>>>> the illegal instructions. What toolchain do you
>> use?
>>>> The toolchain
>>>> should support software FP emulation.
>>> 1)I am using open source too chain with software
>>> floating point emulation support.
>>> (#ppc_8xx-gcc --v
>>>
> /lib/gcc/powerpc/3.4.3/../../../../target_powerpc/usr/include/c++/3.4.3
>>> --with-numa-policy=no --with-float=soft)
>>>
>>> 2)And the kernel is included with code to emulate
>> a
>>> floating-point
>>
>>> unit, which will allow programs that
>>> use floating-point
>>
>>> instructions to run
>>>
>>> Kernel configuration
>>> ----CONFIG_MATH_EMULATION:y
>> If you build with "--with-float=soft" there is no
>> need for math
>> emulation in the kernel. Likely, there is something
>> wrong with your
>> tool-chain. Could you please try a known-to-work
>> tool-chain like the
>> ELDK v4.x from http://www.denx.de.
>>
>> Wolfgang.
>>
>>> Thanks,
>>> Poornima
>>>
>>> --- Wolfgang Grandegger wrote:
>>>
>>>> poornima r wrote:
>>>>> Hi,
>>>>>
>>>>> 1)I am using open source kernel from Kernel.org,
>>>>> but what is meant by vanilla kernel from
>>>> Kernel.org?
>>>>
>>>> It's the kernel from kernel.org. This means that
>> the
>>>> Linux kernel 2.6.18
>>>> is running fine on your MPC860 platform as is?
>>>> Thanks for the info.
>>>>
>>>>> 2)With sampling period of 500usec the system
>>>> simply
>>>>> hangs without printing any results (./latenct
>>>> -p500)
>>>>
>>>> OK.
>>>>
>>>>> 3)cyclictest with -t1 option (without
>>>> IPIPE-tracer)
>>>>> root@domain.hid#
>> ./cyclictest
>>>> -t1
>>>>> 2.04 0.50 0.17 8/27 174
>>>>>
>>>>> T: 0 ( 0) P:99 I: 1000 C: 0 Min:
>>>> 1000000
>>>>> Act: 0 Avg: 0 Max:-1000000
>>>>> Illegal instruction
>>>>>
>>>>> 4)Output of /proc/xenomai/faults after the
>> illegal
>>>>> instruction:-
>>>>> root@domain.hid# cat
>>>>> /proc/xenomai/faults
>>>>> TRAP CPU0
>>>>> 0: 0 (Data or instruction
>> access)
>>>>> 1: 0 (Alignment)
>>>>> 2: 0 (Altivec unavailable)
>>>>> 3: 0 (Program check exception)
>>>>> 4: 0 (Machine check exception)
>>>>> 5: 0 (Unknown)
>>>>> 6: 0 (Instruction breakpoint)
>>>>> 7: 0 (Run mode exception)
>>>>> 8: 0 (Single-step exception)
>>>>> 9: 0 (Non-recoverable exception)
>>>>> 10: 1 (Software emulation)
>>>>> 11: 0 (Debug)
>>>>> 12: 0 (SPE)
>>>>> 13: 0 (Altivec assist)
>>>> Hm, I see a software emulation exception which is
>>>> also the reason for
>>>> the illegal instructions. What toolchain do you
>> use?
>>>> The toolchain
>>>> should support software FP emulation.
>>>>
>>>>> 5)Running switchtest:-
>>>>> root@domain.hid#
>> ./switchtest
>>>> -n
>>>>> --The system hangs wihtout printing any results
>>>>>
>>>>> Thanks,
>>>>> Poornima
>>>>>
>>>>>
>>>>> --- Wolfgang Grandegger
>> wrote:
>>>>>> poornima r wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Thanks for the reply.
>>>>>>>
>>>>>>> Linux version:linux-2.6.18
>>>>>>> Xenomai: xenomai-2.3.0 (Stable version)
>>>>>>> adeos patch:
>> adeos-ipipe-2.6.18-ppc-1.5-01.patch
>>>>>> OK, I'm curious, did you use the vanilla kernel
>>>> from
>>>>>> kernel.org?
>>>>>> More comments below.
>>>>>>
>>>>>>> The tests were run as follows:
>>>>>>> 1)The sampling period in the code for latency
>>>> and
>>>>>>> switchbench was changed to 1000000000ns(to
>>>> remove
>>>>>>> overrun error)
>>>>>>> 2)switchtest was run with -n5 option
>>>>>>> 3)cyclictest was run with -t5 option(5
>> threads
>>>>>>> were created.)
>>>>>>> 4)cyclictest was terminated with Illegal
>>>>>> instruction
>>>>>>> (after creating 5 threads) with IPIPE tracer
>>>>>> enabled.
>>>>>>
>>>>>>> These were the results without I-PIPE Tracer
>>>>>> option:
>>>>>>> (All the tests were run without any load)
>>>>>>> 1)LATENCY TEST:-
>>>>>>> User mode:-
>>>>>>> /mnt/out_xen/bin# ./latency -t0
>>>>>>> == Sampling period: 1000000 us
>>>>>>> == Test mode: periodic user-mode task
>>>>>>> == All results in microseconds
>>>>>>> warming up...
>>>>>>> RTT| 00:00:01 (periodic user-mode task,
>>>> 1000000
>>>>>> us
>>>>>>> period, priority 99)
>>>>>>> RTH|-----lat min|-----lat avg|-----lat
>>>>>>> max|-overrun|----lat best|---lat worst
>>>>>>> RTD| 167.000| 167.000| 167.000|
>>
>>>>>> 0|
>>>>>>> 167.000| 167.000
>>>>>>> RTD| 176.000| 176.000| 176.000|
>>
>>>>>> 0|
>>>>>>> 167.000| 176.000
>>>>>>> RTD| 168.000| 168.000| 168.000|
>>
>>>>>> 0|
>>>>>>> 167.000| 176.000
> === message truncated ===
>
>
>
>
> ____________________________________________________________________________________
> Get your own web address.
> Have a HUGE year through Yahoo! Small Business.
> http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
>
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
>
>


Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.

Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. --0-1520790537-1173876693=:46909--