tiomap-dev team mailing list archive

[warmcat <873453@xxxxxxxxxxxxxxxxxx>]

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