It seems there's general agreement that this is gone on 4430 and tracking kernel at least.
On 4460 and tilt-tracking I saw it work stably for ~ 200 loops until thermal stuff kicks in, at which point it starts showing damage (I modified the script a bit) ... 130616 vs 130616 131775 vs 131775 29083 vs 29083 130707 vs 130707 130463 vs 130463 87371 vs 87371 130859 vs 130859 124969 vs 130523 130584 vs 130584 129517 vs 129517 128663 vs 128663 130188 vs 130188 121307 vs 121277 126495 vs 126495 31769 vs 31769 130799 vs 130799 128540 vs 128540 130615 vs 130615 130493 vs 130493 128234 vs 128234 130371 vs 130371 129975 vs 129975 130676 vs 130676 129700 vs 129700 130523 vs 130523 130463 vs 130463 122772 vs 122772 124970 vs 124970 70740 vs 70740 127411 vs 133972 118714 vs 118714 130157 vs 130157 129028 vs 129028 69244 vs 69244 127685 vs 127685 91736 vs 91736 130615 vs 130615 121276 vs 121276 123810 vs 123810 30273 vs 30273 130707 vs 130707 122436 vs 122436 52338 vs 52338 130523 vs 130523 125641 vs 125641 130066 vs 130066 102967 vs 102967 115753 vs 115753 in dmesg contemporary with that is [ 95.840850] omap_safe_zone:hot spot temp 82135 [ 100.841094] omap_monitor_zone:hot spot temp 85689 [ 104.592437] omap_safe_zone:hot spot temp 81542 [ 105.591278] omap_monitor_zone:hot spot temp 86282 [ 115.841979] omap_safe_zone:hot spot temp 82135 Because of thermal, it's not going to give stable results on 4460 like 4430 since it's switching between 1.2GHz and 920MHz all the time. But that should always give results at or inbetween two times matching those speeds, nothing abnormally low. Notice that the default on tracking is performance cpu_freq governor now, but ~1 min after boot Ubuntu resets it to ondemand via a sleepy boot script IIRC. So you have to be careful the governor is what you think it is because it will change it behind your back. -- You received this bug notification because you are a member of TI OMAP Developers, which is subscribed to linaro-landing-team-ti. https://bugs.launchpad.net/bugs/873453 Title: odd timing behaviour on panda Status in Linaro Texas Instruments Landing Team: Confirmed Status in Linaro Ubuntu Evaluation Builds: Confirmed Bug description: I've got a set of benchmarks that use clock_gettime like: clock_gettime(CLOCK_REALTIME, &tbefore); for(l=0;l<numloops;l++) { dostuff } clock_gettime(CLOCK_REALTIME, &tafter); nsdiff=(double)(tafter.tv_nsec - tbefore.tv_nsec); nsdiff+=1000000000.0 *(tafter.tv_sec - tbefore.tv_sec); and I've just reinstalled our local panda to using Linaro 11.09 (kernel 3.0.0-1404-linaro-lt-omap) and it's starting to get weird timing artifacts. For example: smarter_strlen_ldrd: ,102400, loops of ,62, bytes=6.054688 MB, transferred in ,3936768.000000 ns, giving, 1537.984331 MB/s smarter_strlen_ldrd: ,102400, loops of ,32, bytes=3.125000 MB, transferred in ,0.000000 ns, giving, inf MB/s smarter_strlen_ldrd: ,102400, loops of ,16, bytes=1.562500 MB, transferred in ,4180909.000000 ns, giving, 373.722557 MB/s Now there is no way that loop took 0.000000 ns! Running the same binary on an older installation runs fine. Dave To manage notifications about this bug go to: https://bugs.launchpad.net/linaro-landing-team-ti/+bug/873453/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~tiomap-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~tiomap-dev More help : https://help.launchpad.net/ListHelp
