In data Wednesday 17 August 2011 21:10:47, Sankara Muthukrishnan ha scritto: > On Wed, Aug 17, 2011 at 11:54 AM, Sankara Muthukrishnan > > <sankara.m@xxxxxxxxx> wrote: > > The cyclic test results are not acceptable (attached the output of > > cyclictest). I am seeing maximum latency of 757 us on core-0 and 1905 > > us on core-1. Are you (Is anyone) seeing better results on latency > > with SMP kernel with RT patch on ARM (OMAP4 processors)? I have seen > > ~25 us of latency with single core kernel (though I have used a > > different kernel configuration). > > Never ever mind and sorry for the confusion. I did not realize that > "Kernel debugging" was enabled in the config Frank had attached. With > kernel debugging disabled, I see max latencies less than 20 us on both > cores on panda board with cyclictest (cyclictest -l1000000 -m -Sp99 > -i200 -h60 -q -n) in my quick run and it is exciting to see these > numbers. Thanks Frank. > > The only other outstanding problem as of now is that the RT kernel > hanging during boot on panda board (boots sometimes after several > resets and/or power-cycles). If i use the omap2plus_defconfig of the 3.0.1 kernel i can't get a bootable kernel with RT full preemption. If i apply the Frank config to the 3.0.1 source tree with RT-patch i get a working kernel with full preemption and SMP. Unless i'm very much mistaken the defconfig of the 3.0.0 which Frank config come from is a little bit different from the 3.0.1 version and it gives some problems when the RT-patch is applied. I tried to perform a cyclictest too but i get a segmentation fault when the test is executing with SMP testing option enabled. Did anyone get the same problem? Andrea -- Andrea Baldini Elettronica di Processo SPES. S.c.p.a Via Lamberto Corsi, 43 60044 Fabriano (AN) tel. +39 0732 25291 fax +39 0732 2529441 <mailto:andrea.baldini@xxxxxxxxxxxxxx> andrea.baldini@xxxxxxxxxxxxxx <http://www.spesonline.com> www.spesonline.com -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html