linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* Continual reading from the PowerPc time base register is not stable
@ 2010-03-25  2:41 Csdncannon
  2010-03-25  8:21 ` Benjamin Herrenschmidt
                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Csdncannon @ 2010-03-25  2:41 UTC (permalink / raw)
  To: linuxppc-dev


[-- Attachment #1.1: Type: text/plain, Size: 612 bytes --]

         In my program, the value of the 64-bit time base register is read
out, and you will find the later value is even smaller than the earlier
value from the log “log_timebase”. While the kernel depends on the accuracy
of the timebase for the compensation of the lost PIT interrupt, the negative
value between two continual timebase reading will bring to the jump of the
jiffies. And this timebase problem will bring to the instability of the
gettimeofday system call.

         Do you have any idea about this problem, thanks for your any
advice. Attached is the code and log.


Thanks

Gino

[-- Attachment #1.2: Type: text/html, Size: 1363 bytes --]

[-- Attachment #2: gettime.c --]
[-- Type: application/octet-stream, Size: 767 bytes --]

#include <iostream>

#include <stdlib.h>

#include <string.h>

#include <sys/time.h>

 

int main(void) 

{

    struct timeval now, timeout;

    gettimeofday( &now, (struct timezone *)NULL );

    int count = 0;

 

    while(1)

    {

        count ++;

        gettimeofday( &timeout, (struct timezone *)NULL );

        usleep( 5 );

        gettimeofday( &now, (struct timezone *)NULL );

 

        if (now.tv_sec - timeout.tv_sec > 100)

        {

            printf("Failed : timeout %d , now %d \n", timeout.tv_sec, now.tv_sec);

        }

        if(count > 1000000)

        {

            count = 0;

            printf(" %d ,   %d \n", timeout.tv_sec, now.tv_sec);

        }

    }

 

}


[-- Attachment #3: log_timebase --]
[-- Type: application/octet-stream, Size: 51493 bytes --]

Fri Mar 19 09:38:36 GMT 2010
0x808a77ed
--------------------
0x808a77ff
0x808a77cf
--------------------
0x808a77cf
0x808a77df
0x808a77ed
0x808a77ed
0x808a77fd
0x808a77fd
0x808a784f
0x808a784f
0x808a785f
0x808a785f
0x808a786d
0x808a787d
--------------------
0x808a787f
0x808a784f
--------------------
0x808a785d
0x808a785d
0x808a786d
0x808a786d
0x808a787f
0x808a787f
0x808a78cf
0x808a78cf
0x808a78df
0x808a78ef
0x808a78ef
--------------------
0x808a78ff
0x808a78cd
--------------------
0x808a78cd
0x808a78dd
0x808a78dd
0x808a78ef
0x808a78ff
0x808a78ff
0x808a794f
0x808a795d
0x808a795d
0x808a795f
0x808a796f
0x808a797d
--------------------
0x808a797d
0x808a794d
--------------------
0x808a794d
0x808a795f
0x808a796f
0x808a796f
0x808a797f
0x808a79cf
0x808a79cf
0x808a79dd
0x808a79dd
0x808a79ef
0x808a79ef
0x808a79ff
--------------------
0x808a79ff
0x808a79cd
--------------------
0x808a79dd
0x808a79dd
0x808a79ed
0x808a79ff
0x808a79ff
--------------------
0x808a7a4f
Fri Mar 19 09:38:36 GMT 2010
--------------------
0x80ca1e7d
0x80ca1e4d
--------------------
0x80ca1e5d
0x80ca1e5f
0x80ca1e6f
0x80ca1e7d
0x80ca1e7d
0x80ca1ecd
0x80ca1ecd
0x80ca1edf
0x80ca1edf
0x80ca1eef
0x80ca1eef
--------------------
0x80ca1eff
--------------------
0x80ca1ecf
0x80ca1ecd
--------------------
0x80ca1edd
0x80ca1eef
0x80ca1eef
0x80ca1eff
0x80ca1eff
0x80ca1f4d
0x80ca1f5d
0x80ca1f5f
0x80ca1f6f
0x80ca1f7d
--------------------
0x80ca1f7d
0x80ca1f4d
--------------------
0x80ca1f4d
0x80ca1f5f
0x80ca1f5f
0x80ca1f6f
0x80ca1f6f
0x80ca1f7d
0x80ca1fcd
0x80ca1fcd
0x80ca1fdd
0x80ca1fef
0x80ca1fef
0x80ca1ffd
--------------------
0x80ca1ffd
0x80ca1fcf
--------------------
0x80ca1fcf
0x80ca1fdf
0x80ca1fdf
0x80ca1fed
0x80ca1ffd
0x80ca1ffd
0x80ca204d
0x80ca205f
0x80ca205f
0x80ca206f
0x80ca206f
--------------------
0x80ca207d
0x80ca204d
--------------------
0x80ca204f
0x80ca204f
0x80ca205d
0x80ca206d
0x80ca206d
0x80ca207d
0x80ca20cf
0x80ca20cf
--------------------
0x80ca20df
Fri Mar 19 09:38:36 GMT 2010
0x8109e14f
0x8109e15f
0x8109e16f
0x8109e16f
--------------------
0x8109e17f
0x8109e14d
--------------------
0x8109e14d
0x8109e15d
0x8109e15d
0x8109e16f
--------------------
0x8109e17f
0x8109e17d
--------------------
0x8109e1cd
0x8109e1cf
0x8109e1df
0x8109e1df
0x8109e1ef
--------------------
0x8109e1fd
0x8109e1cd
--------------------
0x8109e1cf
0x8109e1cf
0x8109e1dd
0x8109e1ed
0x8109e1ed
0x8109e1fd
0x8109e24f
0x8109e24f
0x8109e25f
0x8109e25f
0x8109e26d
0x8109e27d
--------------------
0x8109e27d
0x8109e24d
--------------------
0x8109e24f
0x8109e25f
0x8109e25f
0x8109e26f
0x8109e27d
0x8109e27d
0x8109e2cd
0x8109e2cd
0x8109e2df
0x8109e2ef
0x8109e2ef
--------------------
0x8109e2ff
0x8109e2cd
--------------------
0x8109e2cd
0x8109e2cf
0x8109e2df
0x8109e2ed
0x8109e2ed
0x8109e2fd
0x8109e2fd
0x8109e34f
0x8109e35f
0x8109e35f
0x8109e36f
0x8109e37d
--------------------
0x8109e37d
0x8109e34d
--------------------
0x8109e34d
0x8109e35f
0x8109e35f
--------------------
0x8109e36d
Fri Mar 19 09:38:36 GMT 2010
0x81498fcf
0x81498fef
0x81498fef
0x81498ffd
0x81498ffd
0x8149904f
0x8149904f
0x8149905f
0x8149905f
0x8149906d
0x8149907d
--------------------
0x8149907d
0x8149904d
--------------------
0x8149905f
0x8149905f
0x8149906f
0x8149906f
0x8149907d
0x814990cd
0x814990cf
0x814990cf
0x814990dd
0x814990ed
0x814990ed
--------------------
0x814990fd
0x814990cf
--------------------
0x814990cf
0x814990df
0x814990df
0x814990ed
0x814990fd
0x814990fd
0x8149914d
0x8149914f
--------------------
0x8149915f
0x8149915d
--------------------
0x8149916d
0x8149917f
--------------------
0x8149917f
0x8149914f
--------------------
0x8149914f
0x8149915d
0x8149916d
0x8149916d
0x8149917d
0x8149917f
0x814991cf
0x814991cf
0x814991df
0x814991ed
0x814991ed
0x814991fd
--------------------
0x814991fd
0x814991cf
--------------------
0x814991df
0x814991df
0x814991ef
0x814991fd
0x814991fd
0x8149924d
0x8149924d
0x8149925f
0x8149925f
--------------------
0x8149926d
Fri Mar 19 09:38:36 GMT 2010
0x81894edd
0x81894efd
0x81894efd
0x81894f4d
0x81894f4d
0x81894f5f
0x81894f6f
0x81894f6f
--------------------
0x81894f7f
0x81894f4f
--------------------
0x81894f4f
0x81894f5f
0x81894f5f
0x81894f6d
0x81894f7d
0x81894f7d
0x81894fcd
0x81894fcf
--------------------
0x81894fdf
0x81894fdd
--------------------
0x81894fed
0x81894fff
--------------------
0x81894fff
0x81894fcf
--------------------
0x81894fcf
0x81894fdd
0x81894fed
0x81894fed
0x81894ffd
0x8189504d
0x8189504d
0x8189505d
0x8189505d
0x8189506d
0x8189507d
--------------------
0x8189507d
0x8189504d
--------------------
0x8189505f
0x8189505f
0x8189506d
0x8189506d
0x8189507f
0x8189507f
0x818950cf
0x818950cf
0x818950dd
0x818950ed
0x818950ed
--------------------
0x818950fd
0x818950cf
--------------------
0x818950cf
0x818950df
0x818950df
0x818950ef
0x818950ff
0x818950ff
0x8189514f
0x8189515d
0x8189515d
0x8189516d
0x8189516d
0x8189517f
--------------------
0x8189517f
--------------------
0x8189514d
--------------------
Fri Mar 19 09:38:37 GMT 2010
--------------------
0x81c917fd
0x81c917df
--------------------
0x81c917df
0x81c917ef
0x81c917ef
0x81c917fd
0x81c9184d
0x81c9184f
0x81c9184f
0x81c9185d
0x81c9186d
0x81c9186d
--------------------
0x81c9187d
0x81c9184f
--------------------
0x81c9184f
0x81c9185f
0x81c9185f
0x81c9186d
0x81c9187d
0x81c9187d
0x81c918cd
0x81c918cf
--------------------
0x81c918df
0x81c918dd
--------------------
0x81c918ed
0x81c918ff
--------------------
0x81c918ff
0x81c918cf
--------------------
0x81c918cf
0x81c918ef
0x81c918ef
0x81c918ff
0x81c918ff
0x81c9194d
0x81c9195d
0x81c9195f
0x81c9195f
0x81c9197d
--------------------
0x81c9197d
0x81c9194d
--------------------
0x81c9194d
0x81c9195f
0x81c9195f
0x81c9196d
0x81c9196d
0x81c9197f
0x81c919cf
0x81c919cf
0x81c919df
0x81c919ed
0x81c919ed
0x81c919fd
--------------------
0x81c919fd
0x81c919cf
--------------------
0x81c919cf
0x81c919df
0x81c919df
0x81c919ef
0x81c919ff
0x81c919ff
0x81c91a4f
0x81c91a5d
0x81c91a5d
--------------------
0x81c91a6d
Fri Mar 19 09:38:37 GMT 2010
0x8208cd5f
0x8208cd7d
0x8208cd7d
0x8208cdcd
0x8208cdcd
0x8208cddf
0x8208cddf
0x8208cded
0x8208cded
--------------------
0x8208cdff
0x8208cdcf
--------------------
0x8208cdcf
0x8208cddf
0x8208cded
0x8208cded
0x8208cdfd
0x8208cdfd
0x8208ce4f
0x8208ce4f
0x8208ce5f
0x8208ce5f
0x8208ce6d
0x8208ce7d
--------------------
0x8208ce7f
0x8208ce4f
--------------------
0x8208ce5d
0x8208ce5d
0x8208ce6d
0x8208ce6d
0x8208ce7f
0x8208ce7f
0x8208cecf
0x8208cecf
0x8208cedd
0x8208ceed
0x8208ceed
--------------------
0x8208cefd
0x8208cecf
--------------------
0x8208cecf
0x8208cedd
0x8208cedd
0x8208ceef
0x8208ceef
0x8208ceff
0x8208ceff
0x8208cf4d
0x8208cf5d
0x8208cf5d
0x8208cf6d
0x8208cf7f
--------------------
0x8208cf7f
0x8208cf4f
--------------------
0x8208cf4f
0x8208cf5d
0x8208cf6d
0x8208cf6f
0x8208cf6f
0x8208cf7d
0x8208cfcd
0x8208cfcd
0x8208cfdd
0x8208cfef
0x8208cfef
--------------------
0x8208cfff
Fri Mar 19 09:38:37 GMT 2010
--------------------
0x824882fd
0x824882cf
--------------------
0x824882df
0x824882df
0x824882ef
0x824882fd
0x824882fd
0x8248834d
0x8248834d
0x8248835f
0x8248835f
0x8248836f
0x8248836f
--------------------
0x8248837d
0x8248834d
--------------------
0x8248834f
0x8248835f
0x8248836d
0x8248836d
0x8248837d
0x8248837d
0x824883cf
0x824883cf
0x824883df
0x824883df
0x824883ed
0x824883fd
--------------------
0x824883fd
0x824883cd
--------------------
0x824883df
0x824883df
0x824883ed
0x824883ed
0x824883ff
0x824883ff
0x8248844f
0x8248844f
0x8248845d
0x8248846d
0x8248846d
--------------------
0x8248847d
0x8248844d
--------------------
0x8248844d
0x8248845f
0x8248845f
0x8248846d
0x8248847d
0x8248847d
0x824884cd
0x824884df
0x824884df
0x824884ed
0x824884ed
0x824884ff
--------------------
0x824884ff
0x824884cf
--------------------
0x824884cf
0x824884dd
0x824884ed
0x824884ed
0x824884fd
0x8248854f
0x8248854f
--------------------
0x8248855f
Fri Mar 19 09:38:37 GMT 2010
0x82883e5f
0x82883e7f
--------------------
0x82883e7f
0x82883e4f
--------------------
0x82883e4f
0x82883e5d
0x82883e6d
0x82883e6d
0x82883e7d
0x82883e7f
--------------------
0x82883ecf
0x82883ecd
--------------------
0x82883edd
0x82883eef
0x82883eef
0x82883eff
--------------------
0x82883eff
0x82883ecd
--------------------
0x82883edd
0x82883edd
0x82883eed
0x82883eef
0x82883eff
0x82883eff
0x82883f4f
0x82883f5d
0x82883f5d
0x82883f6f
0x82883f6f
--------------------
0x82883f7d
0x82883f4d
--------------------
0x82883f4d
0x82883f5d
0x82883f6f
0x82883f6f
0x82883f7d
0x82883f7d
0x82883fcf
0x82883fcf
0x82883fdf
0x82883fdf
0x82883fed
0x82883ffd
--------------------
0x82883ffd
0x82883fcd
--------------------
0x82883fdf
0x82883fdf
0x82883fef
0x82883fef
0x82883ffd
0x8288404d
0x8288404f
0x8288404f
0x8288405d
0x8288406d
0x8288406d
--------------------
0x8288407d
0x8288404d
--------------------
0x8288404d
0x8288405d
0x8288405d
0x8288406f
--------------------
0x8288407f
--------------------
0x8288407d
--------------------
Fri Mar 19 09:38:37 GMT 2010
0x82c80b5d
0x82c80b7d
--------------------
0x82c80b7d
0x82c80b4d
--------------------
0x82c80b4d
0x82c80b5f
0x82c80b6f
0x82c80b6f
0x82c80b7f
0x82c80bcd
0x82c80bcd
0x82c80bdd
0x82c80bdd
0x82c80bef
0x82c80bef
0x82c80bff
--------------------
0x82c80bff
0x82c80bcd
--------------------
0x82c80bdd
0x82c80bdd
0x82c80bed
0x82c80bff
0x82c80bff
0x82c80c4d
0x82c80c4d
0x82c80c5f
0x82c80c5f
0x82c80c6f
0x82c80c6f
--------------------
0x82c80c7d
0x82c80c4d
--------------------
0x82c80c4d
0x82c80c5d
0x82c80c6f
0x82c80c6f
0x82c80c7f
0x82c80c7f
0x82c80ccd
0x82c80cdd
0x82c80cdf
0x82c80cdf
0x82c80ced
0x82c80cfd
--------------------
0x82c80cfd
0x82c80ccd
--------------------
0x82c80cdf
0x82c80cdf
0x82c80cef
0x82c80cef
0x82c80cfd
0x82c80d4d
0x82c80d4d
0x82c80d5d
0x82c80d5f
--------------------
0x82c80d6f
0x82c80d6d
--------------------
--------------------
0x82c80d7d
0x82c80d4f
--------------------
0x82c80d4f
0x82c80d5f
0x82c80d5f
0x82c80d6d
0x82c80d7d
--------------------
0x82c80d7d
Fri Mar 19 09:38:37 GMT 2010
--------------------
0x8307c6ff
0x8307c6cf
--------------------
0x8307c6df
0x8307c6df
0x8307c6ef
0x8307c6fd
0x8307c6fd
0x8307c6ff
0x8307c74f
0x8307c75d
0x8307c75d
0x8307c76d
0x8307c76d
--------------------
0x8307c77f
0x8307c74f
--------------------
0x8307c74f
0x8307c75f
0x8307c76d
0x8307c76d
0x8307c77d
0x8307c77d
0x8307c7cf
0x8307c7cf
0x8307c7df
0x8307c7df
0x8307c7ed
0x8307c7fd
--------------------
0x8307c7fd
0x8307c7cd
--------------------
0x8307c7df
0x8307c7df
0x8307c7ef
0x8307c7ef
0x8307c7fd
0x8307c84d
0x8307c84f
0x8307c84f
0x8307c85d
0x8307c86d
0x8307c86d
--------------------
0x8307c87d
0x8307c84f
--------------------
0x8307c84f
0x8307c85f
0x8307c85f
0x8307c86d
0x8307c87d
0x8307c87d
0x8307c8cd
0x8307c8cf
--------------------
0x8307c8df
0x8307c8dd
--------------------
0x8307c8ed
0x8307c8ff
--------------------
0x8307c8ff
0x8307c8cf
--------------------
0x8307c8cf
0x8307c8dd
0x8307c8ed
0x8307c8ed
0x8307c8fd
0x8307c8ff
0x8307c94f
--------------------
0x8307c94f
Fri Mar 19 09:38:37 GMT 2010
--------------------
0x834782ef
0x834782cf
--------------------
0x834782cf
0x834782df
0x834782df
0x834782ed
0x834782fd
0x834782fd
0x8347834d
0x8347835f
0x8347835f
0x8347836d
0x8347836d
0x8347837f
--------------------
0x8347837f
0x8347834f
--------------------
0x8347834f
0x8347835d
0x8347836d
0x8347836d
0x8347837d
0x834783cd
0x834783cd
0x834783dd
0x834783dd
0x834783ef
--------------------
0x834783ff
--------------------
0x834783fd
0x834783cd
--------------------
0x834783cf
0x834783df
0x834783df
0x834783ef
0x834783fd
0x834783fd
0x8347844d
0x8347844d
0x8347845f
0x8347846f
0x8347846f
--------------------
0x8347847f
0x8347844d
--------------------
0x8347844d
0x8347844f
0x8347845f
0x8347846d
0x8347846d
0x8347847d
0x8347847d
0x834784cf
0x834784df
0x834784df
0x834784ef
0x834784fd
--------------------
0x834784fd
0x834784cd
--------------------
0x834784cd
0x834784df
0x834784df
0x834784ed
0x834784ed
0x834784ff
0x8347854f
--------------------
0x8347854f
Fri Mar 19 09:38:37 GMT 2010
--------------------
0x848a9a7d
0x848a9a5d
--------------------
0x848a9a5d
0x848a9a5f
0x848a9a6f
0x848a9a7d
0x848a9a7d
0x848a9acd
0x848a9acd
0x848a9adf
0x848a9aef
0x848a9aef
--------------------
0x848a9aff
0x848a9acd
--------------------
0x848a9acd
0x848a9add
0x848a9add
0x848a9aed
0x848a9afd
0x848a9afd
0x848a9b4d
0x848a9b4f
0x848a9b5f
0x848a9b5f
0x848a9b6f
0x848a9b7d
--------------------
0x848a9b7d
0x848a9b4f
--------------------
0x848a9b4f
0x848a9b5d
0x848a9b6d
0x848a9b6d
0x848a9b7d
0x848a9b7f
0x848a9bcf
0x848a9bcf
0x848a9bdf
0x848a9bed
0x848a9bed
0x848a9bfd
--------------------
0x848a9bfd
0x848a9bcf
--------------------
--------------------
0x848a9bdf
0x848a9bdd
--------------------
0x848a9bed
0x848a9bef
0x848a9bff
0x848a9bff
0x848a9c4f
0x848a9c5f
0x848a9c5f
0x848a9c6f
0x848a9c6f
--------------------
0x848a9c7d
0x848a9c4d
--------------------
0x848a9c4f
0x848a9c5f
0x848a9c6d
0x848a9c6d
0x848a9c7d
0x848a9c7d
0x848a9ccf
0x848a9ccf
--------------------
0x848a9cdf
Fri Mar 19 09:38:37 GMT 2010
0x84c556ef
--------------------
0x84c556ff
0x84c556cf
--------------------
0x84c556cf
0x84c556df
0x84c556ed
0x84c556ed
0x84c556fd
0x84c556fd
0x84c5574f
--------------------
0x84c5575f
0x84c5575d
--------------------
0x84c5576d
0x84c5576f
0x84c5577f
--------------------
0x84c5577f
0x84c5574f
--------------------
0x84c5575d
0x84c5575d
0x84c5576d
0x84c5576d
0x84c5577f
0x84c557cf
0x84c557cf
0x84c557df
0x84c557ed
0x84c557ed
0x84c557ef
--------------------
0x84c557ff
0x84c557cd
--------------------
0x84c557cd
0x84c557dd
0x84c557dd
0x84c557ef
0x84c557ff
0x84c557ff
0x84c5584f
0x84c5585d
0x84c5585d
0x84c5586d
0x84c5586d
0x84c5587f
--------------------
0x84c5587f
0x84c5584d
--------------------
0x84c5584d
0x84c5585d
0x84c5586d
0x84c5586d
0x84c5587d
0x84c558cf
0x84c558cf
0x84c558df
0x84c558df
0x84c558ed
0x84c558fd
0x84c558ff
--------------------
0x84c558ff
0x84c558cd
--------------------
0x84c558dd
0x84c558dd
0x84c558ed
0x84c558ff
0x84c558ff
--------------------
0x84c5594f
Fri Mar 19 09:38:37 GMT 2010
0x8505154f
0x8505156f
0x8505156f
0x8505157d
--------------------
0x8505157d
0x8505154f
--------------------
0x8505155f
0x8505155f
0x8505156f
0x8505157d
0x8505157d
0x850515cd
0x850515cd
0x850515dd
0x850515ed
0x850515ed
0x850515fd
--------------------
0x850515ff
0x850515cf
--------------------
0x850515cf
0x850515df
0x850515ed
0x850515ed
0x850515fd
0x850515fd
0x8505164f
--------------------
0x8505165f
0x8505165d
--------------------
0x8505166d
0x8505166f
0x8505167f
--------------------
0x8505167f
0x8505164f
--------------------
0x8505165d
0x8505166d
0x8505166f
0x8505166f
0x8505167d
0x850516cd
0x850516cd
0x850516dd
0x850516ef
0x850516ef
0x850516ff
--------------------
0x850516ff
0x850516cf
--------------------
0x850516df
0x850516df
0x850516ef
0x850516ff
0x850516ff
0x8505174f
0x8505174f
0x8505175d
0x8505176d
0x8505176f
0x8505176f
--------------------
0x8505177d
0x8505174d
--------------------
0x8505174d
0x8505175d
0x8505176f
0x8505176f
--------------------
0x8505177f
Fri Mar 19 09:38:37 GMT 2010
0x853a2f7f
0x853a2fdd
0x853a2fdd
0x853a2fed
0x853a2fed
0x853a2fff
--------------------
0x853a2fff
0x853a2fcf
--------------------
0x853a2fcf
0x853a2fdd
0x853a2fed
0x853a2fed
0x853a2ffd
0x853a304f
0x853a304f
0x853a305d
0x853a305d
0x853a306f
0x853a306f
0x853a307f
--------------------
0x853a307f
0x853a304d
--------------------
0x853a305d
0x853a305d
0x853a306d
0x853a307f
0x853a307f
0x853a30cf
0x853a30cf
0x853a30dd
0x853a30ed
0x853a30ef
0x853a30ef
--------------------
0x853a30fd
0x853a30cd
--------------------
0x853a30cd
0x853a30dd
0x853a30ef
0x853a30ef
0x853a30fd
0x853a30fd
0x853a314d
0x853a315d
0x853a315d
0x853a316d
0x853a317d
--------------------
0x853a317d
0x853a314d
--------------------
0x853a314d
0x853a315f
0x853a316f
0x853a316f
0x853a317f
0x853a31cd
0x853a31cd
0x853a31dd
0x853a31dd
0x853a31ef
0x853a31ef
0x853a31fd
--------------------
0x853a31fd
0x853a31cf
--------------------
0x853a31df
--------------------
0x853a31df
Fri Mar 19 09:38:37 GMT 2010
--------------------
0x856f51fd
0x856f51dd
--------------------
0x856f51dd
0x856f51ed
0x856f51ed
0x856f51ff
0x856f51ff
0x856f524d
0x856f524d
0x856f525f
0x856f526f
0x856f526f
--------------------
0x856f527f
0x856f524d
--------------------
0x856f524d
0x856f525f
0x856f525f
0x856f526d
0x856f527d
0x856f527d
0x856f52cd
0x856f52cf
0x856f52df
0x856f52df
0x856f52ef
0x856f52fd
--------------------
0x856f52fd
0x856f52cd
--------------------
0x856f52cd
0x856f52df
0x856f52ef
0x856f52ef
0x856f52ff
0x856f534d
0x856f534d
0x856f535d
0x856f535d
0x856f536d
0x856f537d
--------------------
0x856f537d
0x856f534d
--------------------
0x856f534f
0x856f535f
0x856f535f
0x856f536f
0x856f537d
0x856f537d
0x856f53cd
0x856f53cd
0x856f53df
--------------------
0x856f53ef
0x856f53ed
--------------------
0x856f53fd
--------------------
0x856f53ff
0x856f53cf
--------------------
0x856f53cf
0x856f53df
0x856f53ed
0x856f53ed
0x856f53fd
0x856f53fd
0x856f544d
0x856f545d
--------------------
0x856f545d
Fri Mar 19 09:38:37 GMT 2010
--------------------
0x85a48ced
0x85a48ccd
--------------------
0x85a48ccd
0x85a48cdd
0x85a48cdd
0x85a48cef
0x85a48cef
0x85a48cfd
0x85a48cfd
0x85a48d4f
0x85a48d5f
0x85a48d5f
0x85a48d6f
0x85a48d7d
--------------------
0x85a48d7d
0x85a48d4d
--------------------
0x85a48d4d
0x85a48d5f
0x85a48d5f
0x85a48d6f
0x85a48d6f
0x85a48d7d
0x85a48dcd
0x85a48dcf
0x85a48ddf
0x85a48ded
0x85a48ded
0x85a48dfd
--------------------
0x85a48dfd
0x85a48dcf
--------------------
0x85a48dcf
0x85a48ddf
0x85a48ddf
0x85a48dff
0x85a48dff
0x85a48e4f
0x85a48e4f
0x85a48e5d
0x85a48e6d
0x85a48e6f
0x85a48e6f
--------------------
0x85a48e7d
0x85a48e4d
--------------------
0x85a48e4d
0x85a48e5d
0x85a48e6f
0x85a48e6f
0x85a48e7f
0x85a48e7f
0x85a48ecd
0x85a48edd
0x85a48edd
0x85a48eed
0x85a48eef
--------------------
0x85a48eff
--------------------
0x85a48efd
0x85a48ecd
--------------------
0x85a48edf
0x85a48edf
0x85a48eef
0x85a48eef
0x85a48efd
0x85a48f4d
--------------------
0x85a48f4d
Fri Mar 19 09:38:37 GMT 2010
0x85d9aa4f
0x85d9aa6f
0x85d9aa6f
0x85d9aa7f
--------------------
0x85d9aa7f
0x85d9aa4d
--------------------
0x85d9aa5d
0x85d9aa5d
0x85d9aa6d
0x85d9aa6f
--------------------
0x85d9aa7f
0x85d9aa7d
--------------------
0x85d9aacd
0x85d9aaed
0x85d9aaed
0x85d9aafd
--------------------
0x85d9aafd
0x85d9aacf
--------------------
0x85d9aacf
0x85d9aadd
0x85d9aadd
0x85d9aaef
0x85d9aaff
0x85d9aaff
0x85d9ab4f
0x85d9ab5d
0x85d9ab5d
0x85d9ab6d
0x85d9ab6d
0x85d9ab7f
--------------------
0x85d9ab7f
0x85d9ab4f
--------------------
0x85d9ab4f
0x85d9ab5d
0x85d9ab6d
0x85d9ab6f
0x85d9ab7f
0x85d9abcd
0x85d9abcd
0x85d9abdd
0x85d9abdd
0x85d9abef
0x85d9abef
0x85d9abff
--------------------
0x85d9abff
0x85d9abcd
--------------------
0x85d9abdd
0x85d9abdd
0x85d9abed
0x85d9abff
0x85d9abff
0x85d9ac4d
0x85d9ac4d
0x85d9ac5f
0x85d9ac5f
0x85d9ac6f
0x85d9ac6f
--------------------
0x85d9ac7d
0x85d9ac4d
--------------------
0x85d9ac4d
0x85d9ac5d
0x85d9ac6f
0x85d9ac6f
--------------------
0x85d9ac7f
Fri Mar 19 09:38:37 GMT 2010
0x860ed05f
0x860ed06f
0x860ed07f
--------------------
0x860ed07f
0x860ed04f
--------------------
0x860ed05d
0x860ed05d
0x860ed06d
0x860ed06d
0x860ed07f
0x860ed07f
0x860ed0cd
0x860ed0cd
0x860ed0df
0x860ed0ef
0x860ed0ef
--------------------
0x860ed0ff
0x860ed0cd
--------------------
0x860ed0cd
0x860ed0dd
0x860ed0dd
0x860ed0ef
0x860ed0ef
0x860ed0ff
0x860ed0ff
0x860ed14d
0x860ed15d
0x860ed15f
0x860ed16f
0x860ed17d
--------------------
0x860ed17d
0x860ed14d
--------------------
0x860ed14d
0x860ed15f
0x860ed15f
0x860ed16f
0x860ed16f
0x860ed17f
--------------------
0x860ed1cf
0x860ed1cd
--------------------
0x860ed1dd
0x860ed1ef
0x860ed1ef
0x860ed1ff
--------------------
0x860ed1ff
0x860ed1cd
--------------------
0x860ed1dd
0x860ed1dd
0x860ed1ed
0x860ed1ef
0x860ed1ff
0x860ed1ff
0x860ed24f
0x860ed25d
0x860ed25d
0x860ed26f
0x860ed26f
--------------------
0x860ed27d
0x860ed24d
--------------------
0x860ed24d
0x860ed25d
0x860ed25f
0x860ed26f
--------------------
0x860ed26f
Fri Mar 19 09:38:37 GMT 2010
--------------------
0x86456a6d
0x86456a4f
--------------------
0x86456a4f
0x86456a5f
0x86456a5f
0x86456a6d
0x86456a7d
0x86456a7d
0x86456acd
0x86456acf
--------------------
0x86456adf
0x86456add
--------------------
0x86456aed
0x86456aff
--------------------
0x86456aff
0x86456acf
--------------------
0x86456acf
0x86456add
0x86456aed
0x86456aed
0x86456afd
0x86456b4d
0x86456b4d
0x86456b5d
0x86456b5d
0x86456b6f
0x86456b6f
0x86456b7d
--------------------
0x86456b7d
0x86456b4f
--------------------
0x86456b5f
0x86456b5f
0x86456b6f
0x86456b7d
0x86456b7d
0x86456bcd
0x86456bcd
0x86456bdf
0x86456bdf
0x86456bef
0x86456bef
--------------------
0x86456bfd
0x86456bcd
--------------------
0x86456bcf
0x86456bdf
0x86456bed
0x86456bed
0x86456bfd
0x86456bfd
0x86456c4f
0x86456c4f
0x86456c5f
0x86456c5f
0x86456c6d
0x86456c7d
--------------------
0x86456c7d
0x86456c4d
--------------------
0x86456c5f
0x86456c5f
0x86456c6d
0x86456c6d
0x86456c7f
0x86456c7f
--------------------
0x86456ccf
Fri Mar 19 09:38:37 GMT 2010
--------------------
0x867aa7ff
0x867aa7dd
--------------------
0x867aa7dd
0x867aa7ed
0x867aa7ed
0x867aa7ff
0x867aa7ff
0x867aa84f
0x867aa84f
0x867aa85d
0x867aa86d
0x867aa86f
--------------------
0x867aa87f
0x867aa84d
--------------------
0x867aa84d
0x867aa85d
0x867aa85d
0x867aa86f
0x867aa86f
0x867aa87f
0x867aa87f
0x867aa8cd
0x867aa8dd
0x867aa8dd
0x867aa8ed
0x867aa8ff
--------------------
0x867aa8ff
0x867aa8cf
--------------------
0x867aa8cf
0x867aa8dd
0x867aa8ed
0x867aa8ed
0x867aa8fd
0x867aa8ff
0x867aa94f
0x867aa94f
0x867aa95f
0x867aa96d
0x867aa96d
0x867aa97f
--------------------
0x867aa97f
0x867aa94d
--------------------
0x867aa95d
0x867aa95d
0x867aa96d
0x867aa97f
0x867aa97f
0x867aa9cd
0x867aa9cd
0x867aa9df
0x867aa9df
0x867aa9ef
0x867aa9ef
--------------------
0x867aa9fd
0x867aa9cd
--------------------
0x867aa9cd
0x867aa9dd
0x867aa9ef
0x867aa9ef
0x867aa9ff
0x867aa9ff
0x867aaa4d
0x867aaa5d
--------------------
0x867aaa5f
Fri Mar 19 09:38:38 GMT 2010
0x86afc37f
0x86afc3cf
--------------------
0x86afc3df
0x86afc3dd
--------------------
0x86afc3ed
0x86afc3ef
0x86afc3ff
--------------------
0x86afc3ff
0x86afc3cf
--------------------
0x86afc3dd
0x86afc3dd
0x86afc3ed
0x86afc3ed
0x86afc3ff
0x86afc44f
0x86afc44f
0x86afc45f
0x86afc46f
0x86afc46f
0x86afc47f
--------------------
0x86afc47f
0x86afc44d
--------------------
0x86afc45d
0x86afc45d
0x86afc46d
0x86afc46f
--------------------
0x86afc47f
0x86afc47d
--------------------
0x86afc4cd
0x86afc4df
0x86afc4df
0x86afc4ef
0x86afc4ef
--------------------
0x86afc4fd
0x86afc4cd
--------------------
0x86afc4cd
0x86afc4dd
0x86afc4df
0x86afc4ef
0x86afc4ef
0x86afc4ff
0x86afc54d
0x86afc54d
0x86afc55f
0x86afc55f
0x86afc56d
0x86afc57d
--------------------
0x86afc57d
0x86afc54d
--------------------
0x86afc55f
0x86afc56f
0x86afc56f
0x86afc57f
0x86afc5cd
0x86afc5cd
0x86afc5df
0x86afc5df
0x86afc5ed
0x86afc5fd
--------------------
0x86afc5fd
0x86afc5cd
--------------------
0x86afc5cf
0x86afc5df
--------------------
0x86afc5df
Fri Mar 19 09:38:38 GMT 2010
0x86e4e54d
0x86e4e55f
0x86e4e56f
0x86e4e56f
--------------------
0x86e4e57f
0x86e4e54d
--------------------
0x86e4e54d
0x86e4e55d
0x86e4e55d
0x86e4e56f
0x86e4e57f
0x86e4e57f
0x86e4e5cf
0x86e4e5dd
0x86e4e5dd
0x86e4e5df
0x86e4e5ef
0x86e4e5fd
--------------------
0x86e4e5fd
0x86e4e5cd
--------------------
0x86e4e5cd
0x86e4e5df
0x86e4e5ef
0x86e4e5ef
0x86e4e5ff
0x86e4e64d
0x86e4e64d
0x86e4e65d
0x86e4e65d
0x86e4e66f
0x86e4e66f
0x86e4e67d
--------------------
0x86e4e67d
0x86e4e64f
--------------------
0x86e4e65f
0x86e4e65f
0x86e4e66f
0x86e4e67d
0x86e4e67d
0x86e4e6cd
0x86e4e6cd
0x86e4e6df
0x86e4e6df
0x86e4e6ef
0x86e4e6ef
--------------------
0x86e4e6fd
0x86e4e6cd
--------------------
0x86e4e6cf
0x86e4e6df
0x86e4e6ed
0x86e4e6ed
0x86e4e6fd
0x86e4e6fd
0x86e4e74f
0x86e4e74f
0x86e4e75f
0x86e4e75f
0x86e4e76f
--------------------
0x86e4e77f
--------------------
0x86e4e77d
0x86e4e74d
--------------------
0x86e4e75f
0x86e4e75f
--------------------
0x86e4e76f
Fri Mar 19 09:38:38 GMT 2010
0x871a0a6d
0x871a0a7f
0x871a0acf
0x871a0acf
0x871a0adf
0x871a0aed
0x871a0aed
0x871a0aef
--------------------
0x871a0aff
0x871a0acd
--------------------
0x871a0acd
0x871a0add
0x871a0add
0x871a0aef
0x871a0aff
0x871a0aff
0x871a0b4f
0x871a0b5d
0x871a0b5d
0x871a0b6d
0x871a0b6d
0x871a0b7f
--------------------
0x871a0b7f
0x871a0b4d
--------------------
0x871a0b4d
0x871a0b5f
0x871a0b6f
0x871a0b6f
0x871a0b7f
0x871a0bcf
0x871a0bcf
0x871a0bdf
0x871a0bdf
0x871a0bed
0x871a0bfd
0x871a0bff
--------------------
0x871a0bff
0x871a0bcd
--------------------
0x871a0bdd
0x871a0bdd
0x871a0bed
0x871a0bff
0x871a0bff
0x871a0c4f
0x871a0c4f
0x871a0c5d
0x871a0c6d
0x871a0c6d
0x871a0c7d
--------------------
0x871a0c7f
--------------------
0x871a0c4f
0x871a0c4d
--------------------
0x871a0c5d
0x871a0c6f
0x871a0c6f
0x871a0c7f
0x871a0c7f
0x871a0ccd
0x871a0cdd
0x871a0cdd
0x871a0ced
0x871a0cef
0x871a0cff
--------------------
0x871a0cff
Fri Mar 19 09:38:38 GMT 2010
0x874f3ccf
0x874f3cdd
0x874f3ced
0x874f3ced
0x874f3cfd
0x874f3cff
0x874f3d4f
0x874f3d4f
0x874f3d5f
0x874f3d6f
0x874f3d6f
0x874f3d7f
--------------------
0x874f3d7f
0x874f3d4d
--------------------
0x874f3d5d
0x874f3d5d
0x874f3d6d
0x874f3d7f
0x874f3d7f
0x874f3dcf
0x874f3dcf
0x874f3ddf
0x874f3def
0x874f3def
--------------------
0x874f3dff
0x874f3dcd
--------------------
0x874f3dcd
0x874f3ddd
0x874f3ddd
0x874f3def
0x874f3def
0x874f3dfd
0x874f3dfd
0x874f3e4f
0x874f3e5f
0x874f3e5f
0x874f3e6f
0x874f3e7d
--------------------
0x874f3e7d
0x874f3e4d
--------------------
0x874f3e4d
0x874f3e5f
0x874f3e5f
0x874f3e6f
0x874f3e6f
0x874f3e7f
0x874f3ecf
0x874f3ecf
0x874f3edf
0x874f3eed
0x874f3eed
0x874f3efd
--------------------
0x874f3efd
0x874f3ecf
--------------------
--------------------
0x874f3edf
0x874f3edd
--------------------
0x874f3eed
0x874f3efd
0x874f3efd
0x874f3f4d
0x874f3f4d
0x874f3f5f
--------------------
0x874f3f6f
--------------------
0x874f3f6d
--------------------
Fri Mar 19 09:38:38 GMT 2010
0x878461df
0x878461ff
0x878461ff
0x8784624d
0x8784624d
0x8784625f
0x8784626f
0x8784626f
--------------------
0x8784627f
0x8784624d
--------------------
0x8784624d
0x8784625d
0x8784625d
0x8784626f
0x8784626f
0x8784627f
0x8784627f
0x878462cd
0x878462dd
0x878462df
0x878462ef
0x878462fd
--------------------
0x878462fd
0x878462cd
--------------------
0x878462cd
0x878462df
0x878462df
0x878462ef
0x878462ef
0x878462fd
0x8784634d
0x8784634d
0x8784635d
0x8784636f
0x8784636f
0x8784637d
--------------------
0x8784637d
0x8784634d
--------------------
0x8784635d
0x8784635d
0x8784636d
0x8784636f
0x8784637f
0x8784637f
0x878463cf
0x878463dd
0x878463dd
0x878463ef
0x878463ef
--------------------
0x878463fd
0x878463cd
--------------------
0x878463cd
0x878463dd
0x878463df
0x878463ef
0x878463ef
0x878463ff
0x8784644d
0x8784644d
0x8784645d
0x8784645d
0x8784646f
--------------------
0x8784647f
--------------------
0x8784647d
--------------------
Fri Mar 19 09:38:38 GMT 2010
0x87b977cd
0x87b977dd
0x87b977ed
0x87b977ef
0x87b977ef
--------------------
0x87b977fd
0x87b977cd
--------------------
0x87b977cd
0x87b977dd
0x87b977ef
0x87b977ef
0x87b977ff
0x87b977ff
0x87b9784f
0x87b9785f
0x87b9785f
0x87b9786f
0x87b9787d
--------------------
0x87b9787d
0x87b9784f
--------------------
0x87b9784f
0x87b9785f
0x87b9786f
0x87b9786f
0x87b9787f
0x87b978cf
0x87b978cf
0x87b978df
0x87b978df
0x87b978ed
0x87b978fd
--------------------
0x87b978ff
0x87b978cf
--------------------
0x87b978dd
0x87b978dd
0x87b978ed
0x87b978ed
0x87b978ff
0x87b978ff
0x87b9794f
0x87b9794f
0x87b9795d
0x87b9796d
0x87b9796d
--------------------
0x87b9797d
0x87b9794f
--------------------
0x87b9794f
0x87b9795d
0x87b9795d
0x87b9796f
0x87b9797f
0x87b9797f
0x87b979cf
0x87b979dd
0x87b979dd
0x87b979df
0x87b979ef
0x87b979fd
--------------------
0x87b979fd
0x87b979cd
--------------------
0x87b979cd
0x87b979df
0x87b979ef
--------------------
0x87b979ef
Fri Mar 19 09:38:38 GMT 2010
0x87eeae5d
0x87eeae7d
--------------------
0x87eeae7d
0x87eeae4f
--------------------
0x87eeae4f
0x87eeae6f
0x87eeae6f
0x87eeae7f
0x87eeae7f
0x87eeaecd
0x87eeaedd
0x87eeaedf
0x87eeaedf
0x87eeaefd
--------------------
0x87eeaefd
0x87eeaecd
--------------------
0x87eeaecd
0x87eeaedf
0x87eeaedf
0x87eeaeed
0x87eeaeed
0x87eeaeff
0x87eeaf4f
0x87eeaf4f
0x87eeaf5f
0x87eeaf6d
0x87eeaf6d
0x87eeaf7d
--------------------
0x87eeaf7d
0x87eeaf4f
--------------------
0x87eeaf4f
0x87eeaf5f
0x87eeaf5f
0x87eeaf6f
0x87eeaf7f
0x87eeaf7f
0x87eeafcf
0x87eeafdd
0x87eeafdd
0x87eeafed
0x87eeafed
--------------------
0x87eeafff
--------------------
0x87eeafcf
0x87eeafcd
--------------------
0x87eeafdd
0x87eeafef
0x87eeafef
0x87eeafff
0x87eeafff
0x87eeb04d
0x87eeb05d
0x87eeb05f
0x87eeb05f
0x87eeb06d
0x87eeb07d
--------------------
0x87eeb07d
0x87eeb04d
--------------------
0x87eeb05f
0x87eeb05f
0x87eeb06f
0x87eeb06f
0x87eeb07d
0x87eeb0cd
--------------------
0x87eeb0cd
Fri Mar 19 09:38:38 GMT 2010
--------------------
0x8823d0ff
0x8823d0dd
--------------------
0x8823d0dd
0x8823d0ed
0x8823d0ed
0x8823d0ff
0x8823d0ff
0x8823d14f
0x8823d14f
0x8823d15d
0x8823d16d
0x8823d16f
--------------------
0x8823d17f
0x8823d14d
--------------------
0x8823d14d
0x8823d15d
0x8823d15d
0x8823d16f
0x8823d16f
0x8823d17f
0x8823d17f
0x8823d1cd
0x8823d1dd
0x8823d1dd
0x8823d1ed
0x8823d1ff
--------------------
0x8823d1ff
0x8823d1cd
--------------------
0x8823d1cd
0x8823d1df
0x8823d1df
0x8823d1ef
0x8823d1ef
0x8823d1fd
0x8823d24d
0x8823d24d
0x8823d25d
0x8823d26f
0x8823d26f
0x8823d27f
--------------------
0x8823d27f
0x8823d24d
--------------------
0x8823d25d
0x8823d25f
0x8823d25f
0x8823d26d
0x8823d27d
0x8823d27d
0x8823d2cd
0x8823d2df
0x8823d2df
0x8823d2ef
0x8823d2ef
--------------------
0x8823d2ff
--------------------
0x8823d2cf
0x8823d2cd
--------------------
0x8823d2dd
0x8823d2df
0x8823d2ef
0x8823d2ef
0x8823d2ff
0x8823d34d
0x8823d34d
--------------------
0x8823d35d
Fri Mar 19 09:38:38 GMT 2010
0x8858f05d
0x8858f06f
0x8858f07f
--------------------
0x8858f07f
0x8858f04f
--------------------
0x8858f05d
0x8858f05d
0x8858f06d
0x8858f06d
0x8858f07f
0x8858f0cf
0x8858f0cf
0x8858f0df
0x8858f0ed
0x8858f0ed
0x8858f0ef
--------------------
0x8858f0ff
0x8858f0cd
--------------------
0x8858f0cd
0x8858f0dd
0x8858f0dd
0x8858f0ef
0x8858f0ff
0x8858f0ff
0x8858f14f
0x8858f15d
0x8858f15d
0x8858f16d
0x8858f16d
0x8858f17f
--------------------
0x8858f17f
0x8858f14d
--------------------
0x8858f14d
0x8858f15f
0x8858f16f
0x8858f16f
0x8858f17f
0x8858f1cd
0x8858f1cd
0x8858f1dd
0x8858f1dd
0x8858f1ef
0x8858f1ef
0x8858f1ff
--------------------
0x8858f1ff
0x8858f1cd
--------------------
0x8858f1dd
0x8858f1df
0x8858f1ef
0x8858f1ff
0x8858f1ff
0x8858f24f
0x8858f24f
0x8858f25d
0x8858f26d
0x8858f26d
0x8858f27d
--------------------
0x8858f27f
--------------------
0x8858f24f
0x8858f24d
--------------------
0x8858f25d
0x8858f26f
0x8858f26f
--------------------
0x8858f27f
Fri Mar 19 09:38:38 GMT 2010
--------------------
0x888e13fd
0x888e13cf
--------------------
--------------------
0x888e13df
0x888e13dd
--------------------
0x888e13ed
0x888e13ef
0x888e13ff
0x888e13ff
0x888e144f
0x888e145d
0x888e145d
0x888e146d
0x888e146d
--------------------
0x888e147f
0x888e144f
--------------------
0x888e144f
0x888e145f
0x888e146d
0x888e146d
0x888e146f
0x888e147f
0x888e14cd
0x888e14cd
0x888e14dd
0x888e14dd
0x888e14ef
0x888e14ff
--------------------
0x888e14ff
0x888e14cf
--------------------
0x888e14dd
0x888e14dd
0x888e14ed
0x888e14ed
0x888e14ff
0x888e14ff
0x888e154d
0x888e154d
0x888e155f
0x888e156f
0x888e156f
--------------------
0x888e157f
0x888e154d
--------------------
0x888e154d
0x888e155d
0x888e155d
0x888e156f
0x888e156f
0x888e157f
0x888e157f
0x888e15cd
0x888e15dd
0x888e15df
0x888e15ef
0x888e15fd
--------------------
0x888e15fd
0x888e15cd
--------------------
0x888e15cd
0x888e15df
0x888e15df
0x888e15ef
0x888e15ef
0x888e15fd
0x888e164d
--------------------
0x888e164d
Fri Mar 19 09:38:38 GMT 2010
0x88c335ed
--------------------
0x88c335fd
0x88c335cd
--------------------
0x88c335cd
0x88c335dd
0x88c335ef
0x88c335ef
0x88c335fd
0x88c335fd
0x88c3364f
0x88c3364f
0x88c3365f
0x88c3365f
0x88c3366d
0x88c3367d
--------------------
0x88c3367d
0x88c3364d
--------------------
0x88c3365f
0x88c3365f
0x88c3366f
0x88c3366f
0x88c3367d
0x88c336cd
0x88c336cf
0x88c336cf
0x88c336dd
0x88c336ed
0x88c336ed
--------------------
0x88c336fd
0x88c336cf
--------------------
0x88c336cf
0x88c336df
0x88c336df
0x88c336ed
0x88c336fd
0x88c336fd
0x88c3374d
0x88c3374f
--------------------
0x88c3375f
0x88c3375d
--------------------
0x88c3376d
0x88c3377f
--------------------
0x88c3377f
0x88c3374f
--------------------
0x88c3374f
0x88c3375d
0x88c3376d
0x88c3376d
0x88c3377d
0x88c3377f
0x88c337cf
0x88c337cf
0x88c337df
0x88c337ed
0x88c337ed
0x88c337ff
--------------------
0x88c337ff
0x88c337cd
--------------------
0x88c337dd
0x88c337dd
0x88c337ed
0x88c337fd
0x88c337fd
--------------------
0x88c3384d
Fri Mar 19 09:38:38 GMT 2010
--------------------
0x88f851ed
0x88f851cd
--------------------
0x88f851cd
0x88f851dd
0x88f851dd
0x88f851ef
--------------------
0x88f851ff
0x88f851fd
--------------------
0x88f8524d
0x88f8525d
0x88f8526d
0x88f8526d
0x88f8527d
--------------------
0x88f8527f
--------------------
0x88f8524f
0x88f8524d
--------------------
0x88f8525d
0x88f8526f
0x88f8526f
0x88f8527f
0x88f8527f
0x88f852cd
0x88f852dd
0x88f852dd
0x88f852ed
0x88f852ef
0x88f852ff
--------------------
0x88f852ff
0x88f852cf
--------------------
0x88f852df
0x88f852df
0x88f852ef
0x88f852ef
0x88f852fd
0x88f8534d
0x88f8534d
0x88f8535d
0x88f8536f
0x88f8536f
0x88f8537d
--------------------
0x88f8537d
0x88f8534f
--------------------
0x88f8534f
0x88f8535f
0x88f8535f
0x88f8536d
0x88f8537d
0x88f8537d
0x88f853cd
0x88f853df
0x88f853df
0x88f853ef
0x88f853ef
--------------------
0x88f853fd
0x88f853cd
--------------------
0x88f853cf
0x88f853cf
0x88f853dd
0x88f853ed
0x88f853ed
0x88f853fd
0x88f8544f
0x88f8544f
--------------------
0x88f8545f
Fri Mar 19 09:38:38 GMT 2010
0x8938295f
0x8938296d
0x8938297d
0x8938297d
0x893829cd
0x893829df
0x893829df
0x893829ef
0x893829ef
--------------------
0x893829fd
0x893829cd
--------------------
0x893829cd
0x893829dd
0x893829df
--------------------
0x893829ef
0x893829ed
--------------------
0x893829fd
0x89382a4f
0x89382a5f
0x89382a5f
0x89382a6f
0x89382a7d
0x89382a7d
--------------------
0x89382a7f
0x89382a4f
--------------------
0x89382a5d
0x89382a5d
0x89382a6d
0x89382a6d
0x89382a7f
0x89382acf
0x89382acf
0x89382adf
0x89382aed
0x89382aed
0x89382afd
--------------------
0x89382afd
0x89382acf
--------------------
0x89382acf
0x89382add
0x89382add
0x89382aef
0x89382aff
0x89382aff
0x89382b4f
0x89382b5d
0x89382b5d
0x89382b6d
0x89382b6d
0x89382b7f
--------------------
0x89382b7f
0x89382b4f
--------------------
0x89382b4f
0x89382b5d
0x89382b6d
0x89382b6f
0x89382b7f
0x89382bcd
0x89382bcd
0x89382bdd
0x89382bdd
0x89382bef
0x89382bef
--------------------
0x89382bff
Fri Mar 19 09:38:38 GMT 2010
--------------------
0x8977d87d
0x8977d84d
--------------------
0x8977d85d
0x8977d85d
0x8977d86d
0x8977d87f
0x8977d87f
0x8977d8cd
0x8977d8cd
0x8977d8df
0x8977d8df
0x8977d8ef
0x8977d8ef
--------------------
0x8977d8fd
0x8977d8cd
--------------------
0x8977d8cd
0x8977d8dd
0x8977d8ef
0x8977d8ef
0x8977d8ff
0x8977d8ff
0x8977d94d
0x8977d95d
0x8977d95f
0x8977d95f
0x8977d96d
0x8977d97d
--------------------
0x8977d97d
0x8977d94d
--------------------
0x8977d95d
0x8977d96d
0x8977d96d
0x8977d97d
0x8977d9cf
0x8977d9cf
0x8977d9dd
0x8977d9dd
0x8977d9ef
0x8977d9ff
--------------------
0x8977d9ff
0x8977d9cf
--------------------
0x8977d9dd
0x8977d9dd
0x8977d9df
0x8977d9ef
0x8977d9fd
0x8977d9fd
0x8977da4d
0x8977da4d
0x8977da5f
0x8977da6f
0x8977da6f
--------------------
0x8977da7f
0x8977da4d
--------------------
0x8977da4d
0x8977da5d
0x8977da5d
0x8977da6f
0x8977da6f
0x8977da7d
0x8977da7d
0x8977dacf
0x8977dadf
--------------------
0x8977dadf
Fri Mar 19 09:38:38 GMT 2010
0x8abc02ef
--------------------
0x8abc02ff
0x8abc02cf
--------------------
0x8abc02cf
0x8abc02df
0x8abc02ed
0x8abc02ed
0x8abc02fd
0x8abc02fd
0x8abc034f
0x8abc034f
0x8abc035d
0x8abc035d
0x8abc036f
0x8abc037f
--------------------
0x8abc037f
0x8abc034f
--------------------
0x8abc035d
0x8abc035d
0x8abc036d
0x8abc036d
0x8abc037f
0x8abc037f
0x8abc03cf
0x8abc03cf
0x8abc03dd
0x8abc03ed
0x8abc03ef
--------------------
0x8abc03ff
0x8abc03cd
--------------------
0x8abc03cd
0x8abc03dd
0x8abc03dd
0x8abc03ef
0x8abc03ef
0x8abc03ff
0x8abc03ff
0x8abc045d
0x8abc045d
0x8abc046d
0x8abc046d
--------------------
0x8abc047f
--------------------
0x8abc044f
0x8abc044d
--------------------
0x8abc045d
0x8abc045f
0x8abc046f
0x8abc046f
0x8abc047f
0x8abc04cd
0x8abc04dd
0x8abc04df
0x8abc04df
0x8abc04ed
0x8abc04fd
--------------------
0x8abc04fd
0x8abc04cd
--------------------
0x8abc04df
0x8abc04df
0x8abc04ed
0x8abc04ed
0x8abc04ff
0x8abc054f
--------------------
0x8abc054f
Fri Mar 19 09:38:38 GMT 2010
0x8af5a2cd
0x8af5a2dd
0x8af5a2ed
0x8af5a2ed
0x8af5a2fd
0x8af5a2ff
0x8af5a34f
0x8af5a34f
0x8af5a35f
0x8af5a36d
0x8af5a36d
0x8af5a37f
--------------------
0x8af5a37f
0x8af5a34d
--------------------
0x8af5a35d
0x8af5a35d
0x8af5a36d
0x8af5a36f
0x8af5a37f
0x8af5a37f
0x8af5a3cf
0x8af5a3dd
0x8af5a3dd
0x8af5a3ed
0x8af5a3ed
--------------------
0x8af5a3ff
--------------------
0x8af5a3cf
0x8af5a3cd
--------------------
0x8af5a3dd
0x8af5a3df
0x8af5a3ef
0x8af5a3ef
0x8af5a3ff
0x8af5a44d
0x8af5a45d
0x8af5a45d
0x8af5a46d
0x8af5a46f
--------------------
0x8af5a47f
--------------------
0x8af5a47d
0x8af5a44d
--------------------
0x8af5a45f
0x8af5a45f
0x8af5a46f
0x8af5a46f
0x8af5a47d
0x8af5a4cd
0x8af5a4cd
0x8af5a4dd
0x8af5a4df
0x8af5a4ef
0x8af5a4ef
--------------------
0x8af5a4ff
0x8af5a4cf
--------------------
0x8af5a4cf
0x8af5a4df
0x8af5a4df
0x8af5a4ed
0x8af5a4fd
0x8af5a4fd
0x8af5a54d
0x8af5a55f
0x8af5a55f
--------------------
0x8af5a56d
Fri Mar 19 09:38:38 GMT 2010
0x8b3572dd
0x8b3572ff
0x8b3572ff
0x8b35734f
0x8b35734f
0x8b35735d
0x8b35736d
0x8b35736d
0x8b35737d
--------------------
0x8b35737f
--------------------
0x8b35734f
0x8b35734d
--------------------
0x8b35735d
0x8b35736f
0x8b35736f
0x8b35737f
0x8b35737f
0x8b3573cd
0x8b3573dd
0x8b3573dd
0x8b3573ed
0x8b3573ef
0x8b3573ff
--------------------
0x8b3573ff
0x8b3573cf
--------------------
0x8b3573dd
0x8b3573dd
0x8b3573ef
0x8b3573ef
0x8b3573fd
0x8b35744d
0x8b35744d
0x8b35745d
0x8b35745f
0x8b35746f
0x8b35746f
--------------------
0x8b35747f
0x8b35744d
--------------------
0x8b35744d
0x8b35745d
0x8b35745d
0x8b35746f
0x8b35747f
0x8b35747f
0x8b3574cf
0x8b3574dd
0x8b3574dd
0x8b3574ed
0x8b3574ed
0x8b3574ff
--------------------
0x8b3574ff
0x8b3574cf
--------------------
0x8b3574cf
0x8b3574dd
0x8b3574ed
0x8b3574ef
0x8b3574ff
0x8b35754d
0x8b35754d
0x8b35755d
0x8b35755d
0x8b35756f
0x8b35756f
--------------------
0x8b35757f
Fri Mar 19 09:38:38 GMT 2010
0x8b75294f
0x8b75295d
0x8b75296d
0x8b75296d
0x8b75297d
--------------------
0x8b75297f
0x8b75294f
--------------------
0x8b75294f
0x8b75295f
0x8b75296d
0x8b75296d
0x8b75297d
0x8b75297d
0x8b7529cf
--------------------
0x8b7529df
0x8b7529dd
--------------------
0x8b7529ed
0x8b7529ef
0x8b7529ff
--------------------
0x8b7529ff
0x8b7529cf
--------------------
0x8b7529dd
0x8b7529dd
0x8b7529ed
0x8b7529ed
0x8b7529ff
0x8b752a4f
0x8b752a4f
0x8b752a5f
0x8b752a6d
0x8b752a6d
0x8b752a6f
--------------------
0x8b752a7f
0x8b752a4d
--------------------
0x8b752a4d
0x8b752a5d
0x8b752a5d
0x8b752a6f
0x8b752a7f
0x8b752a7f
0x8b752acf
0x8b752add
0x8b752add
0x8b752aed
0x8b752aed
0x8b752aff
--------------------
0x8b752aff
0x8b752acd
--------------------
0x8b752acd
0x8b752adf
0x8b752aef
0x8b752aef
0x8b752aff
0x8b752b4d
0x8b752b4d
0x8b752b5d
0x8b752b5d
0x8b752b6f
0x8b752b6f
0x8b752b7f
--------------------
0x8b752b7f
0x8b752b4d
--------------------
0x8b752b5d
--------------------
0x8b752b5d
Fri Mar 19 09:38:39 GMT 2010
0x8bb4e8dd
0x8bb4e8ef
0x8bb4e8ff
--------------------
0x8bb4e8ff
0x8bb4e8cf
--------------------
0x8bb4e8dd
0x8bb4e8dd
0x8bb4e8ed
0x8bb4e8ed
0x8bb4e8ff
0x8bb4e8ff
0x8bb4e94f
0x8bb4e94f
0x8bb4e95d
0x8bb4e96d
0x8bb4e96f
--------------------
0x8bb4e97f
0x8bb4e94d
--------------------
0x8bb4e94d
0x8bb4e95d
0x8bb4e95d
0x8bb4e96f
0x8bb4e96f
0x8bb4e97f
0x8bb4e97f
0x8bb4e9cd
0x8bb4e9dd
0x8bb4e9dd
0x8bb4e9ed
0x8bb4e9ff
--------------------
0x8bb4e9ff
0x8bb4e9cd
--------------------
0x8bb4e9cd
0x8bb4e9df
0x8bb4e9ef
0x8bb4e9ef
0x8bb4e9ff
0x8bb4ea4d
0x8bb4ea4d
0x8bb4ea4f
0x8bb4ea5f
0x8bb4ea6d
0x8bb4ea6d
0x8bb4ea7d
--------------------
0x8bb4ea7d
0x8bb4ea4f
--------------------
0x8bb4ea5f
0x8bb4ea5f
0x8bb4ea6f
0x8bb4ea7d
0x8bb4ea7d
0x8bb4eacd
0x8bb4eacd
0x8bb4eadf
0x8bb4eadf
0x8bb4eaed
0x8bb4eaed
--------------------
0x8bb4eaff
0x8bb4eacf
--------------------
0x8bb4eacf
0x8bb4eadf
0x8bb4eaed
0x8bb4eaed
--------------------
0x8bb4eafd
Fri Mar 19 09:38:39 GMT 2010
0x8bf49b5d
0x8bf49b6f
0x8bf49b6f
0x8bf49b7f
--------------------
0x8bf49b7f
0x8bf49b4d
--------------------
0x8bf49b5d
0x8bf49b5d
0x8bf49b6d
0x8bf49b7f
0x8bf49b7f
0x8bf49bcf
0x8bf49bcf
0x8bf49bdd
0x8bf49bed
0x8bf49bef
0x8bf49bef
--------------------
0x8bf49bff
0x8bf49bcf
--------------------
0x8bf49bcf
0x8bf49bdf
0x8bf49bed
0x8bf49bed
0x8bf49bfd
0x8bf49bfd
0x8bf49c4f
--------------------
0x8bf49c5f
0x8bf49c5d
--------------------
0x8bf49c6d
0x8bf49c6f
0x8bf49c7f
--------------------
0x8bf49c7f
0x8bf49c4f
--------------------
0x8bf49c5d
0x8bf49c5d
0x8bf49c6d
0x8bf49c6d
0x8bf49c7f
0x8bf49ccf
0x8bf49ccf
0x8bf49cdf
0x8bf49cef
0x8bf49cef
0x8bf49cff
--------------------
0x8bf49cff
0x8bf49ccd
--------------------
0x8bf49cdd
0x8bf49cdd
0x8bf49ced
0x8bf49cef
--------------------
0x8bf49cff
0x8bf49cfd
--------------------
0x8bf49d4d
0x8bf49d5f
0x8bf49d5f
0x8bf49d6f
0x8bf49d6f
--------------------
0x8bf49d7d
0x8bf49d4d
--------------------
0x8bf49d4d
0x8bf49d5d
0x8bf49d5f
0x8bf49d6f
--------------------
0x8bf49d6f
Fri Mar 19 09:38:39 GMT 2010
--------------------
0x8c3474ef
0x8c3474cf
--------------------
0x8c3474cf
0x8c3474df
0x8c3474df
0x8c3474ed
0x8c3474fd
0x8c3474fd
0x8c34754d
0x8c34754f
--------------------
0x8c34755f
0x8c34755d
--------------------
0x8c34756d
0x8c34757f
--------------------
0x8c34757f
0x8c34754f
--------------------
0x8c34754f
0x8c34755d
0x8c34756d
0x8c34756d
0x8c34757d
0x8c34757f
0x8c3475cf
0x8c3475cf
0x8c3475df
0x8c3475ed
0x8c3475ed
0x8c3475ff
--------------------
0x8c3475ff
0x8c3475cd
--------------------
0x8c3475dd
0x8c3475dd
0x8c3475ed
0x8c3475ef
0x8c3475ff
0x8c3475ff
0x8c34764f
0x8c34765d
0x8c34765d
0x8c34766d
0x8c34766d
--------------------
0x8c34767f
0x8c34764f
--------------------
0x8c34764f
0x8c34765f
0x8c34766d
0x8c34766d
0x8c34767d
0x8c34767d
0x8c3476cf
0x8c3476cf
0x8c3476df
0x8c3476df
0x8c3476ed
0x8c3476fd
--------------------
0x8c3476ff
0x8c3476cf
--------------------
0x8c3476dd
0x8c3476dd
0x8c3476ed
0x8c3476ed
0x8c3476ff
0x8c3476ff
--------------------
0x8c34774f
Fri Mar 19 09:38:39 GMT 2010
0x8c741e7d
0x8c741edd
0x8c741edd
0x8c741edf
0x8c741eef
0x8c741efd
--------------------
0x8c741efd
0x8c741ecd
--------------------
0x8c741ecd
0x8c741edf
0x8c741eef
0x8c741eef
0x8c741eff
0x8c741f4f
0x8c741f4f
0x8c741f5f
0x8c741f5f
0x8c741f6d
0x8c741f7d
--------------------
0x8c741f7d
0x8c741f4d
--------------------
0x8c741f4f
0x8c741f5f
0x8c741f5f
0x8c741f6f
0x8c741f7d
0x8c741f7d
0x8c741fcf
0x8c741fcf
0x8c741fdd
0x8c741fed
0x8c741fed
0x8c741ffd
--------------------
0x8c741fff
0x8c741fcf
--------------------
0x8c741fcf
0x8c741fdf
0x8c741fed
0x8c741fed
0x8c741ffd
0x8c741ffd
0x8c74204f
--------------------
0x8c74205f
0x8c74205d
--------------------
0x8c74206d
0x8c74206f
0x8c74207f
--------------------
0x8c74207f
0x8c74204f
--------------------
0x8c74205d
0x8c74205d
0x8c74206d
0x8c74206d
0x8c74207d
0x8c7420cd
0x8c7420cf
0x8c7420df
0x8c7420ed
0x8c7420ed
0x8c7420fd
--------------------
0x8c7420fd
0x8c7420cf
--------------------
--------------------
0x8c7420df
--------------------
0x8c7420dd
--------------------
Fri Mar 19 09:38:39 GMT 2010
0x8cb3e2cd
0x8cb3e2ed
0x8cb3e2ed
0x8cb3e2fd
--------------------
0x8cb3e2fd
0x8cb3e2cf
--------------------
0x8cb3e2df
0x8cb3e2df
0x8cb3e2ef
0x8cb3e2fd
0x8cb3e2fd
0x8cb3e2ff
0x8cb3e34f
0x8cb3e35d
0x8cb3e35d
0x8cb3e36d
0x8cb3e36d
--------------------
0x8cb3e37f
0x8cb3e34f
--------------------
0x8cb3e34f
0x8cb3e35f
0x8cb3e36d
0x8cb3e36d
0x8cb3e37d
0x8cb3e37d
0x8cb3e3cf
0x8cb3e3cf
0x8cb3e3dd
0x8cb3e3dd
0x8cb3e3ef
0x8cb3e3ff
--------------------
0x8cb3e3ff
0x8cb3e3cf
--------------------
0x8cb3e3dd
0x8cb3e3dd
0x8cb3e3ed
0x8cb3e3ed
0x8cb3e3ff
0x8cb3e3ff
0x8cb3e44f
0x8cb3e44f
0x8cb3e45d
0x8cb3e46d
0x8cb3e46d
--------------------
0x8cb3e47d
0x8cb3e44f
--------------------
0x8cb3e44f
0x8cb3e45f
0x8cb3e45f
0x8cb3e46d
0x8cb3e47d
0x8cb3e47d
0x8cb3e4cd
0x8cb3e4cf
--------------------
0x8cb3e4df
0x8cb3e4dd
--------------------
0x8cb3e4ed
0x8cb3e4ff
--------------------
0x8cb3e4ff
0x8cb3e4cf
--------------------
0x8cb3e4cf
0x8cb3e4dd
0x8cb3e4ed
--------------------
0x8cb3e4ed
Fri Mar 19 09:38:39 GMT 2010
0x8df7966f
--------------------
0x8df7967f
--------------------
0x8df7964f
0x8df7964d
--------------------
0x8df7965d
0x8df7966f
0x8df7966f
0x8df7967f
0x8df7967f
0x8df796cd
0x8df796dd
0x8df796dd
0x8df796ed
0x8df796ef
0x8df796ff
--------------------
0x8df796ff
0x8df796cf
--------------------
0x8df796dd
0x8df796dd
0x8df796ef
0x8df796ef
0x8df796fd
0x8df7974d
0x8df7974d
0x8df7975d
0x8df7975f
0x8df7976f
0x8df7976f
--------------------
0x8df7977f
0x8df7974d
--------------------
0x8df7974d
0x8df7975d
0x8df7975d
0x8df7977d
0x8df7977d
0x8df797cd
0x8df797cd
0x8df797df
--------------------
0x8df797ef
0x8df797ed
--------------------
0x8df797fd
--------------------
0x8df797ff
0x8df797cf
--------------------
0x8df797cf
0x8df797df
0x8df797ed
0x8df797ed
0x8df797fd
0x8df797fd
0x8df7984f
0x8df7985f
0x8df7985f
0x8df7986f
0x8df7987d
0x8df7987d
--------------------
0x8df7987f
0x8df7984f
--------------------
0x8df7985d
0x8df7985d
0x8df7986d
0x8df7986d
0x8df7987f
0x8df798cf
--------------------
0x8df798cf
Fri Mar 19 09:38:39 GMT 2010
0x8e31b07f
0x8e31b0df
0x8e31b0df
0x8e31b0ef
0x8e31b0ef
--------------------
0x8e31b0fd
0x8e31b0cd
--------------------
0x8e31b0cf
0x8e31b0cf
0x8e31b0dd
0x8e31b0ed
0x8e31b0ed
0x8e31b0fd
0x8e31b14f
0x8e31b14f
0x8e31b15f
0x8e31b15f
0x8e31b16d
0x8e31b17d
--------------------
0x8e31b17d
0x8e31b14d
--------------------
0x8e31b14f
0x8e31b15f
0x8e31b15f
0x8e31b16f
0x8e31b17d
0x8e31b17d
0x8e31b1cd
0x8e31b1cd
0x8e31b1df
0x8e31b1ef
0x8e31b1ef
--------------------
0x8e31b1ff
0x8e31b1cd
--------------------
0x8e31b1cd
0x8e31b1cf
0x8e31b1df
0x8e31b1ed
0x8e31b1ed
0x8e31b1fd
0x8e31b1fd
0x8e31b24f
0x8e31b25f
0x8e31b25f
0x8e31b26f
0x8e31b27d
--------------------
0x8e31b27d
0x8e31b24d
--------------------
0x8e31b24d
0x8e31b25f
0x8e31b25f
0x8e31b26d
0x8e31b26d
0x8e31b27f
0x8e31b2cf
0x8e31b2cf
0x8e31b2df
0x8e31b2ed
0x8e31b2ed
0x8e31b2fd
--------------------
0x8e31b2fd
0x8e31b2cf
--------------------
0x8e31b2cf
--------------------
0x8e31b2df
Fri Mar 19 09:38:39 GMT 2010
0x8e716c7f
0x8e716cdd
0x8e716cdd
0x8e716ced
0x8e716ced
--------------------
0x8e716cff
0x8e716ccf
--------------------
0x8e716ccf
0x8e716cdf
0x8e716ced
0x8e716ced
0x8e716cfd
0x8e716cfd
0x8e716d4f
0x8e716d4f
0x8e716d5d
0x8e716d5d
0x8e716d6f
0x8e716d7f
--------------------
0x8e716d7f
0x8e716d4f
--------------------
0x8e716d5f
0x8e716d5f
0x8e716d6f
0x8e716d6f
0x8e716d7d
0x8e716dcd
0x8e716dcf
0x8e716dcf
0x8e716ddd
0x8e716ded
0x8e716ded
--------------------
0x8e716dfd
0x8e716dcf
--------------------
0x8e716dcf
0x8e716ddf
0x8e716ddf
0x8e716ded
0x8e716dfd
0x8e716dfd
0x8e716e4d
0x8e716e4f
--------------------
0x8e716e5f
0x8e716e5d
--------------------
0x8e716e6d
0x8e716e7f
--------------------
0x8e716e7f
0x8e716e4f
--------------------
0x8e716e4f
0x8e716e5d
0x8e716e6d
0x8e716e6d
0x8e716e7d
0x8e716e7f
0x8e716ecf
0x8e716ecf
0x8e716edf
0x8e716eed
0x8e716eed
0x8e716eff
--------------------
0x8e716eff
0x8e716ecd
--------------------
0x8e716edd
--------------------
0x8e716edd
Fri Mar 19 09:38:39 GMT 2010
0x8eb121df
0x8eb121fd
0x8eb121fd
0x8eb1224f
0x8eb1224f
0x8eb1225d
0x8eb1226d
0x8eb1226d
0x8eb1227d
--------------------
0x8eb1227f
0x8eb1224f
--------------------
0x8eb1224f
0x8eb1225f
0x8eb1226d
0x8eb1226d
0x8eb1227d
0x8eb1227d
0x8eb122cf
--------------------
0x8eb122df
0x8eb122dd
--------------------
0x8eb122ed
0x8eb122ef
0x8eb122ff
--------------------
0x8eb122ff
0x8eb122cf
--------------------
0x8eb122dd
0x8eb122dd
0x8eb122ed
0x8eb122ed
0x8eb122ff
0x8eb1234f
0x8eb1234f
0x8eb1235f
0x8eb1236d
0x8eb1236d
0x8eb1236f
--------------------
0x8eb1237f
0x8eb1234d
--------------------
0x8eb1234d
0x8eb1235d
0x8eb1235d
0x8eb1236f
0x8eb1237f
0x8eb1237f
0x8eb123cf
0x8eb123dd
0x8eb123dd
0x8eb123ed
0x8eb123ed
0x8eb123ff
--------------------
0x8eb123ff
0x8eb123cd
--------------------
0x8eb123cd
0x8eb123df
0x8eb123ef
0x8eb123ef
0x8eb123ff
0x8eb1244d
0x8eb1244d
0x8eb1245d
0x8eb1245d
0x8eb1246f
0x8eb1246f
--------------------
0x8eb1247f
Fri Mar 19 09:38:39 GMT 2010
0x8ef0dd4d
0x8ef0dd5d
0x8ef0dd6d
0x8ef0dd6f
0x8ef0dd6f
0x8ef0dd7d
0x8ef0ddcd
0x8ef0ddcd
0x8ef0dddd
0x8ef0ddef
0x8ef0ddef
0x8ef0ddff
--------------------
0x8ef0ddff
0x8ef0ddcf
--------------------
--------------------
0x8ef0dddf
0x8ef0dddd
--------------------
0x8ef0dded
0x8ef0ddef
0x8ef0ddff
0x8ef0ddff
0x8ef0de4f
0x8ef0de5d
0x8ef0de5d
0x8ef0de6d
0x8ef0de6d
--------------------
0x8ef0de7f
0x8ef0de4f
--------------------
0x8ef0de4f
0x8ef0de5f
0x8ef0de6d
0x8ef0de6d
0x8ef0de6f
0x8ef0de7f
0x8ef0decd
0x8ef0dedd
0x8ef0dedd
0x8ef0deed
0x8ef0deef
--------------------
0x8ef0deff
--------------------
0x8ef0defd
0x8ef0decd
--------------------
0x8ef0dedf
0x8ef0dedf
0x8ef0deef
0x8ef0deef
0x8ef0defd
0x8ef0df4d
0x8ef0df4d
0x8ef0df5d
0x8ef0df5f
0x8ef0df6f
0x8ef0df6f
--------------------
0x8ef0df7f
0x8ef0df4d
--------------------
0x8ef0df4d
0x8ef0df5f
0x8ef0df5f
0x8ef0df6d
0x8ef0df7d
0x8ef0df7d
0x8ef0dfcd
0x8ef0dfdf
0x8ef0dfdf
--------------------
0x8ef0dfed
Fri Mar 19 09:38:39 GMT 2010
--------------------
0x8f30a96f
0x8f30a94f
--------------------
0x8f30a94f
0x8f30a95d
0x8f30a95d
0x8f30a96f
0x8f30a97f
0x8f30a97f
0x8f30a9cf
0x8f30a9dd
0x8f30a9dd
0x8f30a9ed
0x8f30a9ed
0x8f30a9ff
--------------------
0x8f30a9ff
0x8f30a9cf
--------------------
0x8f30a9cf
0x8f30a9dd
0x8f30a9ed
0x8f30a9ef
0x8f30a9ff
0x8f30aa4d
0x8f30aa4d
0x8f30aa5d
0x8f30aa5d
0x8f30aa6f
0x8f30aa6f
0x8f30aa7f
--------------------
0x8f30aa7f
0x8f30aa4d
--------------------
0x8f30aa5d
0x8f30aa5d
0x8f30aa6d
0x8f30aa7f
0x8f30aa7f
0x8f30aacd
0x8f30aacd
0x8f30aadf
0x8f30aadf
0x8f30aaef
0x8f30aaef
--------------------
0x8f30aafd
0x8f30aacd
--------------------
0x8f30aacd
0x8f30aadd
0x8f30aaef
0x8f30aaef
0x8f30aaff
0x8f30aaff
0x8f30ab4d
0x8f30ab5d
0x8f30ab5f
0x8f30ab5f
0x8f30ab6d
0x8f30ab7d
--------------------
0x8f30ab7d
0x8f30ab4d
--------------------
0x8f30ab5f
0x8f30ab5f
0x8f30ab6f
0x8f30ab6f
0x8f30abcd
0x8f30abcd
--------------------
0x8f30abdd
Fri Mar 19 09:38:39 GMT 2010
0x8f7066cf
0x8f7066dd
0x8f7066ed
0x8f7066ed
0x8f7066fd
0x8f7066ff
0x8f70674f
0x8f70674f
0x8f70675f
0x8f70676d
0x8f70676d
0x8f70677d
--------------------
0x8f70677d
0x8f70674f
--------------------
--------------------
0x8f70675f
0x8f70675d
--------------------
0x8f70676d
0x8f70676f
0x8f70677f
0x8f70677f
0x8f7067cf
0x8f7067df
0x8f7067df
0x8f7067ef
0x8f7067ef
--------------------
0x8f7067ff
0x8f7067cf
--------------------
0x8f7067cf
0x8f7067df
0x8f7067ed
0x8f7067ed
0x8f7067fd
0x8f7067fd
0x8f70684d
0x8f70685d
0x8f70685d
0x8f70686d
0x8f70687d
--------------------
0x8f70687d
0x8f70684d
--------------------
0x8f70684d
0x8f70685f
0x8f70686f
0x8f70686f
0x8f70687f
0x8f7068cf
0x8f7068cf
0x8f7068df
0x8f7068df
0x8f7068ed
0x8f7068fd
--------------------
0x8f7068fd
0x8f7068cd
--------------------
0x8f7068cf
0x8f7068df
0x8f7068df
0x8f7068ef
0x8f7068fd
0x8f7068fd
0x8f70694f
0x8f70694f
0x8f70695d
0x8f70696d
--------------------
0x8f70696d

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25  2:41 Continual reading from the PowerPc time base register is not stable Csdncannon
@ 2010-03-25  8:21 ` Benjamin Herrenschmidt
  2010-03-25 10:05   ` Arnd Bergmann
  2010-03-25 21:37 ` Segher Boessenkool
  2010-04-10  3:14 ` Csdncannon
  2 siblings, 1 reply; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2010-03-25  8:21 UTC (permalink / raw)
  To: Csdncannon; +Cc: linuxppc-dev, Arnd Bergmann

On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote:
>          In my program, the value of the 64-bit time base register is
> read out, and you will find the later value is even smaller than the
> earlier value from the log “log_timebase”. While the kernel depends on
> the accuracy of the timebase for the compensation of the lost PIT
> interrupt, the negative value between two continual timebase reading
> will bring to the jump of the jiffies. And this timebase problem will
> bring to the instability of the gettimeofday system call.
> 
>          Do you have any idea about this problem, thanks for your any
> advice. Attached is the code and log.

This is a concern, it should definitely not happen. What machine is
that ? is the code compiled 32-bit or 64-bit ? What kernel version ?

Arnd, any chance that could relate to the bug you've been chasing on
Cell ?

Cheers,
Ben.

> 
> Thanks
> 
> Gino
> 
> 
> 
>  
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25  8:21 ` Benjamin Herrenschmidt
@ 2010-03-25 10:05   ` Arnd Bergmann
  2010-03-25 15:00     ` Csdncannon
  0 siblings, 1 reply; 23+ messages in thread
From: Arnd Bergmann @ 2010-03-25 10:05 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Csdncannon

On Thursday 25 March 2010, Benjamin Herrenschmidt wrote:
> On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote:
> >          In my program, the value of the 64-bit time base register is
> > read out, and you will find the later value is even smaller than the
> > earlier value from the log “log_timebase”. While the kernel depends on
> > the accuracy of the timebase for the compensation of the lost PIT
> > interrupt, the negative value between two continual timebase reading
> > will bring to the jump of the jiffies. And this timebase problem will
> > bring to the instability of the gettimeofday system call.
> > 
> >          Do you have any idea about this problem, thanks for your any
> > advice. Attached is the code and log.
> 
> This is a concern, it should definitely not happen. What machine is
> that ? is the code compiled 32-bit or 64-bit ? What kernel version ?
> 
> Arnd, any chance that could relate to the bug you've been chasing on
> Cell ?

We're still busy with the problem analysis on Cell, waiting for a time
slot to run the next test kernel. So far it seems like the timebase
is actually synchronized at a significant accuracy on QS22 to never
cause this problem with correct code, however it is possible to
observe incorrect timebase values on Cell whenever the mftb instruction
is not serialized with memory accesses, e.g. by using an isync in front
of the mftb. On Power6 and other CPUs, that problem will not happen.

	Arnd

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25 10:05   ` Arnd Bergmann
@ 2010-03-25 15:00     ` Csdncannon
  2010-03-25 20:38       ` Benjamin Herrenschmidt
                         ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Csdncannon @ 2010-03-25 15:00 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev


[-- Attachment #1.1: Type: text/plain, Size: 1832 bytes --]

I am really sorry that the previously attached code is wrong, this one
"timebase.c" is the right one, and the "log_timebase" file is the right log.

We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit.


Thanks
Gino

2010/3/25 Arnd Bergmann <arnd@arndb.de>

> On Thursday 25 March 2010, Benjamin Herrenschmidt wrote:
> > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote:
> > >          In my program, the value of the 64-bit time base register is
> > > read out, and you will find the later value is even smaller than the
> > > earlier value from the log “log_timebase”. While the kernel depends on
> > > the accuracy of the timebase for the compensation of the lost PIT
> > > interrupt, the negative value between two continual timebase reading
> > > will bring to the jump of the jiffies. And this timebase problem will
> > > bring to the instability of the gettimeofday system call.
> > >
> > >          Do you have any idea about this problem, thanks for your any
> > > advice. Attached is the code and log.
> >
> > This is a concern, it should definitely not happen. What machine is
> > that ? is the code compiled 32-bit or 64-bit ? What kernel version ?
> >
> > Arnd, any chance that could relate to the bug you've been chasing on
> > Cell ?
>
> We're still busy with the problem analysis on Cell, waiting for a time
> slot to run the next test kernel. So far it seems like the timebase
> is actually synchronized at a significant accuracy on QS22 to never
> cause this problem with correct code, however it is possible to
> observe incorrect timebase values on Cell whenever the mftb instruction
> is not serialized with memory accesses, e.g. by using an isync in front
> of the mftb. On Power6 and other CPUs, that problem will not happen.
>
>        Arnd
>

[-- Attachment #1.2: Type: text/html, Size: 2319 bytes --]

[-- Attachment #2: timebase.c --]
[-- Type: application/octet-stream, Size: 1604 bytes --]

/* TSC sync test
 *		by: john stultz (johnstul@us.ibm.com)
 *		(C) Copyright IBM 2003, 2005
 *		Licensed under the GPL
 */


#include <stdio.h>
#include <sys/time.h>
#include <stdlib.h>

#define CALLS_PER_LOOP 64

volatile unsigned long long getTimeBase()
{
	unsigned long upper,lower,upper2;
	do {
		asm volatile("sync; isync":::"memory");
		asm volatile("mftbu %0" : "=r" (upper));
		asm volatile("sync; isync":::"memory");
		asm volatile("mftbl %0" : "=r" (lower));
		asm volatile("sync; isync":::"memory");
		asm volatile("mftbu %0" : "=r" (upper2));
		asm volatile("sync; isync":::"memory");
	}while(upper2!=upper);

	return (upper<<32)|lower;
}

int main(int argc, char *argv[])
{
	volatile unsigned long long list[CALLS_PER_LOOP];
	bool bad[CALLS_PER_LOOP];
	int i, inconsistent;


	/* timestamp start of test */
	system("date");
	while(1){
		inconsistent = 0;

		/* Fill list */
		for(i=0; i < CALLS_PER_LOOP; i++)
			list[i] = getTimeBase();
		
		/* Check for inconsistencies */
		for(i=0; i < CALLS_PER_LOOP-1; i++)
		{
			if(list[i] > list[i+1])
			{
				inconsistent = i+1;
				bad[i] = true;
			}
			else{
				bad[i] = false;
			}
		}

		/* display inconsistency */
		if(inconsistent){
			inconsistent--;
			for(i=0; i < CALLS_PER_LOOP; i++){
				if(bad[i] == true)
					printf("--------------------\n");
				printf("0x%llx\n",list[i]);
				if(bad[i-1] == true && bad[i] == false )
					printf("--------------------\n");
			}
			fflush(0);
			/* timestamp inconsistency*/
			system("date");	
		}

	}
	return 0;
}


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25 15:00     ` Csdncannon
@ 2010-03-25 20:38       ` Benjamin Herrenschmidt
  2010-03-26  1:11         ` Csdncannon
  2010-03-25 22:00       ` Chris Friesen
  2010-03-25 23:37       ` Kumar Gala
  2 siblings, 1 reply; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2010-03-25 20:38 UTC (permalink / raw)
  To: Csdncannon; +Cc: linuxppc-dev, Arnd Bergmann

On Thu, 2010-03-25 at 23:00 +0800, Csdncannon wrote:
> I am really sorry that the previously attached code is wrong, this one
> "timebase.c" is the right one, and the "log_timebase" file is the
> right log.
> 
> We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as
> 32-bit.

And despite all those sync/isync you can still observe the timebase
going backward ? That sounds scary. However, at this stage all I can
suggest is getting freescale folks to have a look, as this should really
not happen. Maybe there's some setting with that specific SoC that is
missing or similar...

Cheers,
Ben.

> 
> Thanks
> Gino
> 
> 2010/3/25 Arnd Bergmann <arnd@arndb.de>
>         On Thursday 25 March 2010, Benjamin Herrenschmidt wrote:
>         > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote:
>         > >          In my program, the value of the 64-bit time base
>         register is
>         > > read out, and you will find the later value is even
>         smaller than the
>         > > earlier value from the log “log_timebase”. While the
>         kernel depends on
>         > > the accuracy of the timebase for the compensation of the
>         lost PIT
>         > > interrupt, the negative value between two continual
>         timebase reading
>         > > will bring to the jump of the jiffies. And this timebase
>         problem will
>         > > bring to the instability of the gettimeofday system call.
>         > >
>         > >          Do you have any idea about this problem, thanks
>         for your any
>         > > advice. Attached is the code and log.
>         >
>         > This is a concern, it should definitely not happen. What
>         machine is
>         > that ? is the code compiled 32-bit or 64-bit ? What kernel
>         version ?
>         >
>         > Arnd, any chance that could relate to the bug you've been
>         chasing on
>         > Cell ?
>         
>         
>         We're still busy with the problem analysis on Cell, waiting
>         for a time
>         slot to run the next test kernel. So far it seems like the
>         timebase
>         is actually synchronized at a significant accuracy on QS22 to
>         never
>         cause this problem with correct code, however it is possible
>         to
>         observe incorrect timebase values on Cell whenever the mftb
>         instruction
>         is not serialized with memory accesses, e.g. by using an isync
>         in front
>         of the mftb. On Power6 and other CPUs, that problem will not
>         happen.
>         
>                Arnd
> 

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25  2:41 Continual reading from the PowerPc time base register is not stable Csdncannon
  2010-03-25  8:21 ` Benjamin Herrenschmidt
@ 2010-03-25 21:37 ` Segher Boessenkool
  2010-04-10  3:14 ` Csdncannon
  2 siblings, 0 replies; 23+ messages in thread
From: Segher Boessenkool @ 2010-03-25 21:37 UTC (permalink / raw)
  To: Csdncannon; +Cc: linuxppc-dev

>          In my program, the value of the 64-bit time base register is read
> out, and you will find the later value is even smaller than the earlier
> value from the log “log_timebase”.

>          Do you have any idea about this problem, thanks for your any
> advice. Attached is the code and log.

Your code has a problem, you do (upper << 32) | lower, it should
be ((unsigned long long)upper << 32) | lower .

That is not the problem though: in your TBL, the bit with value
0x40 is stuck to 1.  Broken hardware?


Segher

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25 15:00     ` Csdncannon
  2010-03-25 20:38       ` Benjamin Herrenschmidt
@ 2010-03-25 22:00       ` Chris Friesen
  2010-03-25 22:57         ` Benjamin Herrenschmidt
  2010-03-25 23:37       ` Kumar Gala
  2 siblings, 1 reply; 23+ messages in thread
From: Chris Friesen @ 2010-03-25 22:00 UTC (permalink / raw)
  To: Csdncannon; +Cc: linuxppc-dev, Arnd Bergmann

On 03/25/2010 09:00 AM, Csdncannon wrote:
> I am really sorry that the previously attached code is wrong, this one
> "timebase.c" is the right one, and the "log_timebase" file is the right log.
> 
> We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit.


volatile unsigned long long getTimeBase()
{
	unsigned long upper,lower,upper2;
	do {
		asm volatile("sync; isync":::"memory");
		asm volatile("mftbu %0" : "=r" (upper));
		asm volatile("sync; isync":::"memory");
		asm volatile("mftbl %0" : "=r" (lower));
		asm volatile("sync; isync":::"memory");
		asm volatile("mftbu %0" : "=r" (upper2));
		asm volatile("sync; isync":::"memory");
	}while(upper2!=upper);

	return (upper<<32)|lower;
}


Shouldn't "upper" be cast to 64-bit before shifting?

Chris

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25 22:00       ` Chris Friesen
@ 2010-03-25 22:57         ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2010-03-25 22:57 UTC (permalink / raw)
  To: Chris Friesen; +Cc: linuxppc-dev, Csdncannon, Arnd Bergmann

On Thu, 2010-03-25 at 16:00 -0600, Chris Friesen wrote:
> Shouldn't "upper" be cast to 64-bit before shifting?

Yup but that doesn't explain his results. I think Segher nailed it to a
stuck bit tho, so I would blame defective HW or HW used outside of
normal operating conditions (maybe the TB is sourced out of bounds ?)

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25 15:00     ` Csdncannon
  2010-03-25 20:38       ` Benjamin Herrenschmidt
  2010-03-25 22:00       ` Chris Friesen
@ 2010-03-25 23:37       ` Kumar Gala
  2 siblings, 0 replies; 23+ messages in thread
From: Kumar Gala @ 2010-03-25 23:37 UTC (permalink / raw)
  To: Csdncannon; +Cc: linuxppc-dev, Arnd Bergmann


On Mar 25, 2010, at 10:00 AM, Csdncannon wrote:

> I am really sorry that the previously attached code is wrong, this one =
"timebase.c" is the right one, and the "log_timebase" file is the right =
log.
>=20
> We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as =
32-bit.
>=20
>=20
> Thanks
> Gino

Is this a custom board or FSL reference board?

- k

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25 20:38       ` Benjamin Herrenschmidt
@ 2010-03-26  1:11         ` Csdncannon
  2010-03-26  1:22           ` Segher Boessenkool
  2010-03-26  1:55           ` Benjamin Herrenschmidt
  0 siblings, 2 replies; 23+ messages in thread
From: Csdncannon @ 2010-03-26  1:11 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann

[-- Attachment #1: Type: text/plain, Size: 3098 bytes --]

After trying the new code with "isync" and unsigned long long convertion,
this problem doesn't happen(I tested for several minutes). But the previous
block of codes(lacking of isync) is borrowed from kernel. And if this is a
bug of kernel?

Thanks
Gino

2010/3/26 Benjamin Herrenschmidt <benh@kernel.crashing.org>

> On Thu, 2010-03-25 at 23:00 +0800, Csdncannon wrote:
> > I am really sorry that the previously attached code is wrong, this one
> > "timebase.c" is the right one, and the "log_timebase" file is the
> > right log.
> >
> > We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as
> > 32-bit.
>
> And despite all those sync/isync you can still observe the timebase
> going backward ? That sounds scary. However, at this stage all I can
> suggest is getting freescale folks to have a look, as this should really
> not happen. Maybe there's some setting with that specific SoC that is
> missing or similar...
>
> Cheers,
> Ben.
>
> >
> > Thanks
> > Gino
> >
> > 2010/3/25 Arnd Bergmann <arnd@arndb.de>
> >         On Thursday 25 March 2010, Benjamin Herrenschmidt wrote:
> >         > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote:
> >         > >          In my program, the value of the 64-bit time base
> >         register is
> >         > > read out, and you will find the later value is even
> >         smaller than the
> >         > > earlier value from the log “log_timebase”. While the
> >         kernel depends on
> >         > > the accuracy of the timebase for the compensation of the
> >         lost PIT
> >         > > interrupt, the negative value between two continual
> >         timebase reading
> >         > > will bring to the jump of the jiffies. And this timebase
> >         problem will
> >         > > bring to the instability of the gettimeofday system call.
> >         > >
> >         > >          Do you have any idea about this problem, thanks
> >         for your any
> >         > > advice. Attached is the code and log.
> >         >
> >         > This is a concern, it should definitely not happen. What
> >         machine is
> >         > that ? is the code compiled 32-bit or 64-bit ? What kernel
> >         version ?
> >         >
> >         > Arnd, any chance that could relate to the bug you've been
> >         chasing on
> >         > Cell ?
> >
> >
> >         We're still busy with the problem analysis on Cell, waiting
> >         for a time
> >         slot to run the next test kernel. So far it seems like the
> >         timebase
> >         is actually synchronized at a significant accuracy on QS22 to
> >         never
> >         cause this problem with correct code, however it is possible
> >         to
> >         observe incorrect timebase values on Cell whenever the mftb
> >         instruction
> >         is not serialized with memory accesses, e.g. by using an isync
> >         in front
> >         of the mftb. On Power6 and other CPUs, that problem will not
> >         happen.
> >
> >                Arnd
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 3915 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not   stable
  2010-03-26  1:11         ` Csdncannon
@ 2010-03-26  1:22           ` Segher Boessenkool
  2010-03-26  2:01             ` Csdncannon
  2010-03-26  1:55           ` Benjamin Herrenschmidt
  1 sibling, 1 reply; 23+ messages in thread
From: Segher Boessenkool @ 2010-03-26  1:22 UTC (permalink / raw)
  To: Csdncannon; +Cc: Arnd Bergmann, linuxppc-dev

> After trying the new code with "isync" and unsigned long long convertion,
> this problem doesn't happen(I tested for several minutes).

Do you now ever get two consecutive time readings that are closer
that 64 tick together?  If not, it's simply hiding the problem.

Do you ever now read a value that does not have the bit with value
0x40 set?


Segher

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-26  1:11         ` Csdncannon
  2010-03-26  1:22           ` Segher Boessenkool
@ 2010-03-26  1:55           ` Benjamin Herrenschmidt
  2010-03-26  2:04             ` Csdncannon
  1 sibling, 1 reply; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2010-03-26  1:55 UTC (permalink / raw)
  To: Csdncannon; +Cc: linuxppc-dev, Arnd Bergmann

On Fri, 2010-03-26 at 09:11 +0800, Csdncannon wrote:
> After trying the new code with "isync" and unsigned long long
> convertion, this problem doesn't happen(I tested for several minutes).
> But the previous block of codes(lacking of isync) is borrowed from
> kernel. And if this is a bug of kernel?

There's an outstanding question about that. Some processors make mftb
context synchronizing but it appears that it may not be the case for all
of them.

Thus indeed, we -might- need some isync's in some places, it's not
totally clear to me though.

Can you send the code that fails (without the isync) ? The one you sent
did have them everywhere.

Cheers,
Ben.

> Thanks
> Gino
> 
> 2010/3/26 Benjamin Herrenschmidt <benh@kernel.crashing.org>
>         On Thu, 2010-03-25 at 23:00 +0800, Csdncannon wrote:
>         > I am really sorry that the previously attached code is
>         wrong, this one
>         > "timebase.c" is the right one, and the "log_timebase" file
>         is the
>         > right log.
>         >
>         > We are using FreeScale PowerPc 8378, kernel 2.6.28 and
>         compiled as
>         > 32-bit.
>         
>         
>         And despite all those sync/isync you can still observe the
>         timebase
>         going backward ? That sounds scary. However, at this stage all
>         I can
>         suggest is getting freescale folks to have a look, as this
>         should really
>         not happen. Maybe there's some setting with that specific SoC
>         that is
>         missing or similar...
>         
>         Cheers,
>         Ben.
>         
>         
>         >
>         > Thanks
>         > Gino
>         >
>         > 2010/3/25 Arnd Bergmann <arnd@arndb.de>
>         >         On Thursday 25 March 2010, Benjamin Herrenschmidt
>         wrote:
>         >         > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon
>         wrote:
>         >         > >          In my program, the value of the 64-bit
>         time base
>         >         register is
>         >         > > read out, and you will find the later value is
>         even
>         >         smaller than the
>         >         > > earlier value from the log “log_timebase”. While
>         the
>         >         kernel depends on
>         >         > > the accuracy of the timebase for the
>         compensation of the
>         >         lost PIT
>         >         > > interrupt, the negative value between two
>         continual
>         >         timebase reading
>         >         > > will bring to the jump of the jiffies. And this
>         timebase
>         >         problem will
>         >         > > bring to the instability of the gettimeofday
>         system call.
>         >         > >
>         >         > >          Do you have any idea about this
>         problem, thanks
>         >         for your any
>         >         > > advice. Attached is the code and log.
>         >         >
>         >         > This is a concern, it should definitely not
>         happen. What
>         >         machine is
>         >         > that ? is the code compiled 32-bit or 64-bit ?
>         What kernel
>         >         version ?
>         >         >
>         >         > Arnd, any chance that could relate to the bug
>         you've been
>         >         chasing on
>         >         > Cell ?
>         >
>         >
>         >         We're still busy with the problem analysis on Cell,
>         waiting
>         >         for a time
>         >         slot to run the next test kernel. So far it seems
>         like the
>         >         timebase
>         >         is actually synchronized at a significant accuracy
>         on QS22 to
>         >         never
>         >         cause this problem with correct code, however it is
>         possible
>         >         to
>         >         observe incorrect timebase values on Cell whenever
>         the mftb
>         >         instruction
>         >         is not serialized with memory accesses, e.g. by
>         using an isync
>         >         in front
>         >         of the mftb. On Power6 and other CPUs, that problem
>         will not
>         >         happen.
>         >
>         >                Arnd
>         >
>         
>         
>         
> 

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-26  1:22           ` Segher Boessenkool
@ 2010-03-26  2:01             ` Csdncannon
  2010-03-26  8:52               ` Segher Boessenkool
  0 siblings, 1 reply; 23+ messages in thread
From: Csdncannon @ 2010-03-26  2:01 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: Arnd Bergmann, linuxppc-dev


[-- Attachment #1.1: Type: text/plain, Size: 695 bytes --]

I enabled the printing of all values. There is bigger gap between two
reading, it seems isync bring to performance drop.
Could you elaborate what does "closer that 64 tick together" mean?

You can see the attached log, the 0x40 is not always set.

Thanks
Gino

2010/3/26 Segher Boessenkool <segher@kernel.crashing.org>

> > After trying the new code with "isync" and unsigned long long convertion,
> > this problem doesn't happen(I tested for several minutes).
>
> Do you now ever get two consecutive time readings that are closer
> that 64 tick together?  If not, it's simply hiding the problem.
>
> Do you ever now read a value that does not have the bit with value
> 0x40 set?
>
>
> Segher
>

[-- Attachment #1.2: Type: text/html, Size: 1101 bytes --]

[-- Attachment #2: log --]
[-- Type: application/octet-stream, Size: 4466 bytes --]

Thu Jan  1 00:22:50 GMT 1970
0x1d66f3b12f
0x1d66f3b155
0x1d66f3b15f
0x1d66f3b171
0x1d66f3b17b
0x1d66f3b185
0x1d66f3b18f
0x1d66f3b1a0
0x1d66f3b1aa
0x1d66f3b1b4
0x1d66f3b1be
0x1d66f3b1cf
0x1d66f3b1d9
0x1d66f3b1e3
0x1d66f3b1ed
0x1d66f3b1fe
0x1d66f3b208
0x1d66f3b212
0x1d66f3b21c
0x1d66f3b22d
0x1d66f3b237
0x1d66f3b241
0x1d66f3b24b
0x1d66f3b25c
0x1d66f3b266
0x1d66f3b270
0x1d66f3b27a
0x1d66f3b28b
0x1d66f3b295
0x1d66f3b29f
0x1d66f3b2a9
0x1d66f3b2ba
0x1d66f3b2c4
0x1d66f3b2ce
0x1d66f3b2d8
0x1d66f3b2e9
0x1d66f3b2f3
0x1d66f3b2fd
0x1d66f3b307
0x1d66f3b318
0x1d66f3b322
0x1d66f3b32c
0x1d66f3b336
0x1d66f3b347
0x1d66f3b351
0x1d66f3b35b
0x1d66f3b365
0x1d66f3b376
0x1d66f3b380
0x1d66f3b38a
0x1d66f3b394
0x1d66f3b3a5
0x1d66f3b3af
0x1d66f3b3b9
0x1d66f3b3c3
0x1d66f3b3d4
0x1d66f3b3de
0x1d66f3b3e8
0x1d66f3b3f2
0x1d66f3b404
0x1d66f3b40e
0x1d66f3b419
0x1d66f3b423
--------------------
0x1d66f3b433
Thu Jan  1 00:22:51 GMT 1970
0x1d6728d175
0x1d6728d19b
0x1d6728d1a5
0x1d6728d1b6
0x1d6728d1c0
0x1d6728d1ca
0x1d6728d1d4
0x1d6728d1e5
0x1d6728d1ef
0x1d6728d1f9
0x1d6728d203
0x1d6728d214
0x1d6728d21e
0x1d6728d228
0x1d6728d232
0x1d6728d243
0x1d6728d24d
0x1d6728d257
0x1d6728d261
0x1d6728d272
0x1d6728d27c
0x1d6728d286
0x1d6728d290
0x1d6728d2a1
0x1d6728d2ab
0x1d6728d2b5
0x1d6728d2bf
0x1d6728d2d0
0x1d6728d2da
0x1d6728d2e4
0x1d6728d2ee
0x1d6728d2ff
0x1d6728d309
0x1d6728d313
0x1d6728d31d
0x1d6728d32f
0x1d6728d339
0x1d6728d344
0x1d6728d34e
0x1d6728d35e
0x1d6728d368
0x1d6728d373
0x1d6728d37d
0x1d6728d38d
0x1d6728d397
0x1d6728d3a2
0x1d6728d3ac
0x1d6728d3bc
0x1d6728d3c6
0x1d6728d3d1
0x1d6728d3db
0x1d6728d3eb
0x1d6728d3f5
0x1d6728d400
0x1d6728d40a
0x1d6728d41a
0x1d6728d424
0x1d6728d42f
0x1d6728d439
0x1d6728d449
0x1d6728d453
0x1d6728d45e
0x1d6728d468
--------------------
0x1d6728d478
Thu Jan  1 00:22:51 GMT 1970
0x1d675df210
0x1d675df236
0x1d675df240
0x1d675df251
0x1d675df25b
0x1d675df265
0x1d675df26f
0x1d675df281
0x1d675df28b
0x1d675df296
0x1d675df2a0
0x1d675df2b0
0x1d675df2ba
0x1d675df2c5
0x1d675df2cf
0x1d675df2df
0x1d675df2e9
0x1d675df2f4
0x1d675df2fe
0x1d675df30e
0x1d675df318
0x1d675df323
0x1d675df32d
0x1d675df33d
0x1d675df347
0x1d675df352
0x1d675df35c
0x1d675df36c
0x1d675df376
0x1d675df381
0x1d675df38b
0x1d675df39b
0x1d675df3a5
0x1d675df3b0
0x1d675df3ba
0x1d675df3ca
0x1d675df3d4
0x1d675df3df
0x1d675df3e9
0x1d675df3f9
0x1d675df403
0x1d675df40e
0x1d675df418
0x1d675df428
0x1d675df432
0x1d675df43d
0x1d675df447
0x1d675df457
0x1d675df461
0x1d675df46c
0x1d675df476
0x1d675df486
0x1d675df490
0x1d675df49b
0x1d675df4a5
0x1d675df4b5
0x1d675df4bf
0x1d675df4ca
0x1d675df4d4
0x1d675df4ec
0x1d675df4f6
0x1d675df500
0x1d675df50a
--------------------
0x1d675df51b
Thu Jan  1 00:22:51 GMT 1970
0x1d67931055
0x1d6793107b
0x1d67931085
0x1d67931095
0x1d6793109f
0x1d679310aa
0x1d679310b4
0x1d679310c4
0x1d679310ce
0x1d679310d9
0x1d679310e3
0x1d679310f3
0x1d679310fd
0x1d67931108
0x1d67931112
0x1d67931122
0x1d6793112c
0x1d67931137
0x1d67931141
0x1d67931151
0x1d6793115b
0x1d67931166
0x1d67931170
0x1d67931180
0x1d6793118a
0x1d67931195
0x1d6793119f
0x1d679311b1
0x1d679311bb
0x1d679311c5
0x1d679311cf
0x1d679311e0
0x1d679311ea
0x1d679311f4
0x1d679311fe
0x1d6793120f
0x1d67931219
0x1d67931223
0x1d6793122d
0x1d6793123e
0x1d67931248
0x1d67931252
0x1d6793125c
0x1d6793126d
0x1d67931277
0x1d67931281
0x1d6793128b
0x1d6793129c
0x1d679312a6
0x1d679312b0
0x1d679312ba
0x1d679312cb
0x1d679312d5
0x1d679312df
0x1d679312e9
0x1d679312fa
0x1d67931304
0x1d6793130e
0x1d67931318
0x1d67931329
0x1d67931333
0x1d6793133d
0x1d67931347
--------------------
0x1d67931358
Thu Jan  1 00:22:51 GMT 1970
0x1d67c826f2
0x1d67c82718
0x1d67c82722
0x1d67c82733
0x1d67c8273d
0x1d67c82747
0x1d67c82751
0x1d67c82762
0x1d67c8276c
0x1d67c82776
0x1d67c82780
0x1d67c82791
0x1d67c8279b
0x1d67c827a5
0x1d67c827af
0x1d67c827c0
0x1d67c827ca
0x1d67c827d4
0x1d67c827de
0x1d67c827ef
0x1d67c827f9
0x1d67c82803
0x1d67c8280d
0x1d67c8281e
0x1d67c82828
0x1d67c82832
0x1d67c8283c
0x1d67c8284d
0x1d67c82857
0x1d67c82861
0x1d67c8286b
0x1d67c8287c
0x1d67c82886
0x1d67c82890
0x1d67c8289a
0x1d67c828ab
0x1d67c828b5
0x1d67c828bf
0x1d67c828c9
0x1d67c828da
0x1d67c828e4
0x1d67c828ee
0x1d67c828f8
0x1d67c82909
0x1d67c82913
0x1d67c8291d
0x1d67c82927
0x1d67c82939
0x1d67c82943
0x1d67c8294e
0x1d67c82958
0x1d67c82968
0x1d67c82972
0x1d67c8297d
0x1d67c82987
0x1d67c82997
0x1d67c829a1
0x1d67c829ac
0x1d67c829b6
0x1d67c829c6
0x1d67c829d0
0x1d67c829db
0x1d67c829e5
--------------------
0x1d67c829f5
Thu Jan  1 00:22:51 GMT 1970
0x1d67fd67e2
0x1d67fd680b


[-- Attachment #3: timebase.c --]
[-- Type: application/octet-stream, Size: 1643 bytes --]

/* TSC sync test
 *		by: john stultz (johnstul@us.ibm.com)
 *		(C) Copyright IBM 2003, 2005
 *		Licensed under the GPL
 */


#include <stdio.h>
#include <sys/time.h>
#include <stdlib.h>

#define CALLS_PER_LOOP 64

volatile unsigned long long getTimeBase()
{
	unsigned long upper,lower,upper2;
	do {
		asm volatile("sync; isync":::"memory");
		asm volatile("mftbu %0" : "=r" (upper));
		asm volatile("sync; isync":::"memory");
		asm volatile("mftbl %0" : "=r" (lower));
		asm volatile("sync; isync":::"memory");
		asm volatile("mftbu %0" : "=r" (upper2));
		asm volatile("sync; isync":::"memory");
	}while(upper2!=upper);

	return ((unsigned long long)upper<<32)|lower;
}

int main(int argc, char *argv[])
{
	volatile unsigned long long list[CALLS_PER_LOOP];
	bool bad[CALLS_PER_LOOP];
	int i, inconsistent;


	/* timestamp start of test */
	system("date");
	while(1){
		inconsistent = 0;

		/* Fill list */
		for(i=0; i < CALLS_PER_LOOP; i++)
			list[i] = getTimeBase();
		
		/* Check for inconsistencies */
		for(i=0; i < CALLS_PER_LOOP-1; i++)
		{
			if(list[i] > list[i+1])
			{
				inconsistent = i+1;
				bad[i] = true;
			}
			else{
				bad[i] = false;
			}
		}
		inconsistent = 1;
		/* display inconsistency */
		if(inconsistent){
			inconsistent--;
			for(i=0; i < CALLS_PER_LOOP; i++){
				if(bad[i] == true)
					printf("--------------------\n");
				printf("0x%llx\n",list[i]);
				if(bad[i-1] == true && bad[i] == false )
					printf("--------------------\n");
			}
			fflush(0);
			/* timestamp inconsistency*/
			system("date");	
		}

	}
	return 0;
}


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-26  1:55           ` Benjamin Herrenschmidt
@ 2010-03-26  2:04             ` Csdncannon
  0 siblings, 0 replies; 23+ messages in thread
From: Csdncannon @ 2010-03-26  2:04 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann


[-- Attachment #1.1: Type: text/plain, Size: 4760 bytes --]

Ben
       Attached is the previous failing one.

Thanks
Gino

2010/3/26 Benjamin Herrenschmidt <benh@kernel.crashing.org>

> On Fri, 2010-03-26 at 09:11 +0800, Csdncannon wrote:
> > After trying the new code with "isync" and unsigned long long
> > convertion, this problem doesn't happen(I tested for several minutes).
> > But the previous block of codes(lacking of isync) is borrowed from
> > kernel. And if this is a bug of kernel?
>
> There's an outstanding question about that. Some processors make mftb
> context synchronizing but it appears that it may not be the case for all
> of them.
>
> Thus indeed, we -might- need some isync's in some places, it's not
> totally clear to me though.
>
> Can you send the code that fails (without the isync) ? The one you sent
> did have them everywhere.
>
> Cheers,
> Ben.
>
> > Thanks
> > Gino
> >
> > 2010/3/26 Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >         On Thu, 2010-03-25 at 23:00 +0800, Csdncannon wrote:
> >         > I am really sorry that the previously attached code is
> >         wrong, this one
> >         > "timebase.c" is the right one, and the "log_timebase" file
> >         is the
> >         > right log.
> >         >
> >         > We are using FreeScale PowerPc 8378, kernel 2.6.28 and
> >         compiled as
> >         > 32-bit.
> >
> >
> >         And despite all those sync/isync you can still observe the
> >         timebase
> >         going backward ? That sounds scary. However, at this stage all
> >         I can
> >         suggest is getting freescale folks to have a look, as this
> >         should really
> >         not happen. Maybe there's some setting with that specific SoC
> >         that is
> >         missing or similar...
> >
> >         Cheers,
> >         Ben.
> >
> >
> >         >
> >         > Thanks
> >         > Gino
> >         >
> >         > 2010/3/25 Arnd Bergmann <arnd@arndb.de>
> >         >         On Thursday 25 March 2010, Benjamin Herrenschmidt
> >         wrote:
> >         >         > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon
> >         wrote:
> >         >         > >          In my program, the value of the 64-bit
> >         time base
> >         >         register is
> >         >         > > read out, and you will find the later value is
> >         even
> >         >         smaller than the
> >         >         > > earlier value from the log “log_timebase”. While
> >         the
> >         >         kernel depends on
> >         >         > > the accuracy of the timebase for the
> >         compensation of the
> >         >         lost PIT
> >         >         > > interrupt, the negative value between two
> >         continual
> >         >         timebase reading
> >         >         > > will bring to the jump of the jiffies. And this
> >         timebase
> >         >         problem will
> >         >         > > bring to the instability of the gettimeofday
> >         system call.
> >         >         > >
> >         >         > >          Do you have any idea about this
> >         problem, thanks
> >         >         for your any
> >         >         > > advice. Attached is the code and log.
> >         >         >
> >         >         > This is a concern, it should definitely not
> >         happen. What
> >         >         machine is
> >         >         > that ? is the code compiled 32-bit or 64-bit ?
> >         What kernel
> >         >         version ?
> >         >         >
> >         >         > Arnd, any chance that could relate to the bug
> >         you've been
> >         >         chasing on
> >         >         > Cell ?
> >         >
> >         >
> >         >         We're still busy with the problem analysis on Cell,
> >         waiting
> >         >         for a time
> >         >         slot to run the next test kernel. So far it seems
> >         like the
> >         >         timebase
> >         >         is actually synchronized at a significant accuracy
> >         on QS22 to
> >         >         never
> >         >         cause this problem with correct code, however it is
> >         possible
> >         >         to
> >         >         observe incorrect timebase values on Cell whenever
> >         the mftb
> >         >         instruction
> >         >         is not serialized with memory accesses, e.g. by
> >         using an isync
> >         >         in front
> >         >         of the mftb. On Power6 and other CPUs, that problem
> >         will not
> >         >         happen.
> >         >
> >         >                Arnd
> >         >
> >
> >
> >
> >
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 6088 bytes --]

[-- Attachment #2: timebase.c --]
[-- Type: application/octet-stream, Size: 1576 bytes --]

/* TSC sync test
 *		by: john stultz (johnstul@us.ibm.com)
 *		(C) Copyright IBM 2003, 2005
 *		Licensed under the GPL
 */


#include <stdio.h>
#include <sys/time.h>
#include <stdlib.h>

#define CALLS_PER_LOOP 64

volatile unsigned long long getTimeBase()
{
	unsigned long upper,lower,upper2;
	do {
		asm volatile("sync":::"memory");
		asm volatile("mftbu %0" : "=r" (upper));
		asm volatile("sync":::"memory");
		asm volatile("mftbl %0" : "=r" (lower));
		asm volatile("sync":::"memory");
		asm volatile("mftbu %0" : "=r" (upper2));
		asm volatile("sync":::"memory");
	}while(upper2!=upper);

	return (upper<<32)|lower;
}

int main(int argc, char *argv[])
{
	volatile unsigned long long list[CALLS_PER_LOOP];
	bool bad[CALLS_PER_LOOP];
	int i, inconsistent;


	/* timestamp start of test */
	system("date");
	while(1){
		inconsistent = 0;

		/* Fill list */
		for(i=0; i < CALLS_PER_LOOP; i++)
			list[i] = getTimeBase();
		
		/* Check for inconsistencies */
		for(i=0; i < CALLS_PER_LOOP-1; i++)
		{
			if(list[i] > list[i+1])
			{
				inconsistent = i+1;
				bad[i] = true;
			}
			else{
				bad[i] = false;
			}
		}

		/* display inconsistency */
		if(inconsistent){
			inconsistent--;
			for(i=0; i < CALLS_PER_LOOP; i++){
				if(bad[i] == true)
					printf("--------------------\n");
				printf("0x%llx\n",list[i]);
				if(bad[i-1] == true && bad[i] == false )
					printf("--------------------\n");
			}
			fflush(0);
			/* timestamp inconsistency*/
			system("date");	
		}

	}
	return 0;
}


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not   stable
  2010-03-26  2:01             ` Csdncannon
@ 2010-03-26  8:52               ` Segher Boessenkool
  2010-03-26  9:01                 ` Segher Boessenkool
  0 siblings, 1 reply; 23+ messages in thread
From: Segher Boessenkool @ 2010-03-26  8:52 UTC (permalink / raw)
  To: Csdncannon; +Cc: Arnd Bergmann, linuxppc-dev

[please do not top-post]

>> Do you now ever get two consecutive time readings that are closer
>> that 64 tick together?  If not, it's simply hiding the problem.
>>
>> Do you ever now read a value that does not have the bit with value
>> 0x40 set?

> I enabled the printing of all values. There is bigger gap between two
> reading, it seems isync bring to performance drop.

Yes exactly, which is to be expected.

> Could you elaborate what does "closer that 64 tick together" mean?

It means I cannot type -- "closer than 64 ticks".

My concern was that the sync;isync thing might slow down things
so much that you always get readings 64 or more cycles apart.
But you don't.

> You can see the attached log, the 0x40 is not always set.

Yes indeed.  Could you post the relevant piece if disassembly from
your original binary (the one that has the problem)?  Or send me the
binary (not to the mailing list), I'll do it then.


Segher

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not    stable
  2010-03-26  8:52               ` Segher Boessenkool
@ 2010-03-26  9:01                 ` Segher Boessenkool
  2010-03-26 12:14                   ` Csdncannon
  0 siblings, 1 reply; 23+ messages in thread
From: Segher Boessenkool @ 2010-03-26  9:01 UTC (permalink / raw)
  To: Csdncannon, Segher Boessenkool, Benjamin Herrenschmidt,
	linuxppc-dev, Arnd Bergmann

> Yes indeed.  Could you post the relevant piece if disassembly from
> your original binary (the one that has the problem)?  Or send me the
> binary (not to the mailing list), I'll do it then.

Ah scratch that.  I compiled your original code (after fixing the
compile errors -- there is no such type as "bool" in C).

The problem is that  (upper << 32) | lower  thing.  "upper" is a 32-bit
type, so shifting it by 32 or more bits is undefined.  GCC compiles this
to (shortened):

0: mftbu 9 ; mftbl 11 ; mftbu 0 ; cmpw 0,9 ; bne 0b  # so far so good
   slwi 0,0,0 ; or 4,0,11 ; li 3,0 ; blr

so it shifts by 0, i.e. it does  upper | lower .

Case closed, no hardware problem :-)


Segher

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-26  9:01                 ` Segher Boessenkool
@ 2010-03-26 12:14                   ` Csdncannon
  2010-04-06  8:02                     ` Csdncannon
  0 siblings, 1 reply; 23+ messages in thread
From: Csdncannon @ 2010-03-26 12:14 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: Arnd Bergmann, linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

Yes, the missing 64-bit conversion is the key problem, I will try removing
isync later.

Thanks for your support.


2010/3/26 Segher Boessenkool <segher@kernel.crashing.org>

> > Yes indeed.  Could you post the relevant piece if disassembly from
> > your original binary (the one that has the problem)?  Or send me the
> > binary (not to the mailing list), I'll do it then.
>
> Ah scratch that.  I compiled your original code (after fixing the
> compile errors -- there is no such type as "bool" in C).
>
> The problem is that  (upper << 32) | lower  thing.  "upper" is a 32-bit
> type, so shifting it by 32 or more bits is undefined.  GCC compiles this
> to (shortened):
>
> 0: mftbu 9 ; mftbl 11 ; mftbu 0 ; cmpw 0,9 ; bne 0b  # so far so good
>   slwi 0,0,0 ; or 4,0,11 ; li 3,0 ; blr
>
> so it shifts by 0, i.e. it does  upper | lower .
>
> Case closed, no hardware problem :-)
>
>
> Segher
>
>

[-- Attachment #2: Type: text/html, Size: 1335 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-26 12:14                   ` Csdncannon
@ 2010-04-06  8:02                     ` Csdncannon
  0 siblings, 0 replies; 23+ messages in thread
From: Csdncannon @ 2010-04-06  8:02 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: Arnd Bergmann, linuxppc-dev


[-- Attachment #1.1: Type: text/plain, Size: 1223 bytes --]

Hi guys
       In fact my problem is gettimeofday cannot return right value
sometimes, and this will bring instability to our system software. You can
find a law from the log that there is a 17592 seconds' shift every time
error occurs.



2010/3/26 Csdncannon <csdncannon@gmail.com>

> Yes, the missing 64-bit conversion is the key problem, I will try removing
> isync later.
>
> Thanks for your support.
>
>
> 2010/3/26 Segher Boessenkool <segher@kernel.crashing.org>
>
>> > Yes indeed.  Could you post the relevant piece if disassembly from
>>
>> > your original binary (the one that has the problem)?  Or send me the
>> > binary (not to the mailing list), I'll do it then.
>>
>> Ah scratch that.  I compiled your original code (after fixing the
>> compile errors -- there is no such type as "bool" in C).
>>
>> The problem is that  (upper << 32) | lower  thing.  "upper" is a 32-bit
>> type, so shifting it by 32 or more bits is undefined.  GCC compiles this
>> to (shortened):
>>
>> 0: mftbu 9 ; mftbl 11 ; mftbu 0 ; cmpw 0,9 ; bne 0b  # so far so good
>>   slwi 0,0,0 ; or 4,0,11 ; li 3,0 ; blr
>>
>> so it shifts by 0, i.e. it does  upper | lower .
>>
>> Case closed, no hardware problem :-)
>>
>>
>> Segher
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 2014 bytes --]

[-- Attachment #2: gettime.c --]
[-- Type: application/octet-stream, Size: 1112 bytes --]

#include <iostream>

#include <stdlib.h>

#include <string.h>

#include <sys/time.h>

 

int main(void) 

{

    struct timeval now, timeout;

    gettimeofday( &now, (struct timezone *)NULL );

    int count = 0;

 

    while(1)

    {

        count ++;

        if(gettimeofday( &timeout, (struct timezone *)NULL ))
		{
			printf("gettimeofday failed1: tv_sec %d , tv_usec %d \n", timeout.tv_sec, timeout.tv_usec);
		}		

        usleep( 5 );

        if(gettimeofday( &now, (struct timezone *)NULL ))
		{
			printf("gettimeofday failed2: tv_sec %d , tv_usec %d \n", now.tv_sec, now.tv_usec);
		};

 

        if ((timeout.tv_sec - now.tv_sec) > 1)

        {

            printf("Serious : timeout %d , now %d \n", timeout.tv_sec, now.tv_sec);

        }
		else if((now.tv_sec - timeout.tv_sec) > 1)
		{
			printf("Failed : timeout %d , now %d \n", timeout.tv_sec, now.tv_sec);
		}

        if(count > 1000000)

        {

            count = 0;

            printf(" %d ,   %d \n", timeout.tv_sec, now.tv_sec);

        }

    }

 

}


[-- Attachment #3: gettime.log --]
[-- Type: application/octet-stream, Size: 939 bytes --]

root@tlab8378:/root> /mnt/server/Gino/gettime
 1270540744 ,   1270540744
Failed : timeout 1270540749 , now 1270558341
Serious : timeout 1270558341 , now 1270540749
 1270540755 ,   1270540755
 1270540765 ,   1270540765
Failed : timeout 1270540774 , now 1270558366
Serious : timeout 1270558366 , now 1270540774
 1270540775 ,   1270540775
 1270540786 ,   1270540786
 1270540796 ,   1270540796
Failed : timeout 1270540802 , now 1270558394
Serious : timeout 1270558394 , now 1270540802
Failed : timeout 1270540803 , now 1270558395
Serious : timeout 1270558395 , now 1270540803
 1270540806 ,   1270540806
Failed : timeout 1270540814 , now 1270558406
Serious : timeout 1270558406 , now 1270540814
 1270540816 ,   1270540816
 1270540827 ,   1270540827
 1270540837 ,   1270540837
 1270540847 ,   1270540847
Failed : timeout 1270540855 , now 1270558447
Serious : timeout 1270558447 , now 1270540855
 1270540858 ,   1270540858

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-03-25  2:41 Continual reading from the PowerPc time base register is not stable Csdncannon
  2010-03-25  8:21 ` Benjamin Herrenschmidt
  2010-03-25 21:37 ` Segher Boessenkool
@ 2010-04-10  3:14 ` Csdncannon
  2010-04-22  0:44   ` Kim Phillips
  2 siblings, 1 reply; 23+ messages in thread
From: Csdncannon @ 2010-04-10  3:14 UTC (permalink / raw)
  To: linuxppc-dev, zhouminggang


[-- Attachment #1.1: Type: text/plain, Size: 769 bytes --]

Sorry, I attached the wrong log, this attachment is the right one.


2010/3/25 Csdncannon <csdncannon@gmail.com>

>          In my program, the value of the 64-bit time base register is read
> out, and you will find the later value is even smaller than the earlier
> value from the log “log_timebase”. While the kernel depends on the accuracy
> of the timebase for the compensation of the lost PIT interrupt, the negative
> value between two continual timebase reading will bring to the jump of the
> jiffies. And this timebase problem will bring to the instability of the
> gettimeofday system call.
>
>          Do you have any idea about this problem, thanks for your any
> advice. Attached is the code and log.
>
>
> Thanks
>
> Gino
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 1744 bytes --]

[-- Attachment #2: gettime.log --]
[-- Type: application/octet-stream, Size: 939 bytes --]

root@tlab8378:/root> /mnt/server/Gino/gettime
 1270540744 ,   1270540744
Failed : timeout 1270540749 , now 1270558341
Serious : timeout 1270558341 , now 1270540749
 1270540755 ,   1270540755
 1270540765 ,   1270540765
Failed : timeout 1270540774 , now 1270558366
Serious : timeout 1270558366 , now 1270540774
 1270540775 ,   1270540775
 1270540786 ,   1270540786
 1270540796 ,   1270540796
Failed : timeout 1270540802 , now 1270558394
Serious : timeout 1270558394 , now 1270540802
Failed : timeout 1270540803 , now 1270558395
Serious : timeout 1270558395 , now 1270540803
 1270540806 ,   1270540806
Failed : timeout 1270540814 , now 1270558406
Serious : timeout 1270558406 , now 1270540814
 1270540816 ,   1270540816
 1270540827 ,   1270540827
 1270540837 ,   1270540837
 1270540847 ,   1270540847
Failed : timeout 1270540855 , now 1270558447
Serious : timeout 1270558447 , now 1270540855
 1270540858 ,   1270540858

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-04-10  3:14 ` Csdncannon
@ 2010-04-22  0:44   ` Kim Phillips
  2010-04-22  0:50     ` Benjamin Herrenschmidt
  2010-04-23 10:57     ` Csdncannon
  0 siblings, 2 replies; 23+ messages in thread
From: Kim Phillips @ 2010-04-22  0:44 UTC (permalink / raw)
  To: Csdncannon; +Cc: linuxppc-dev, zhouminggang

On Sat, 10 Apr 2010 11:14:09 +0800
Csdncannon <csdncannon@gmail.com> wrote:

> Sorry, I attached the wrong log, this attachment is the right one.
> 
> 2010/3/25 Csdncannon <csdncannon@gmail.com>
> 
> >          In my program, the value of the 64-bit time base register is read
> > out, and you will find the later value is even smaller than the earlier
> > value from the log “log_timebase”. While the kernel depends on the accuracy
> > of the timebase for the compensation of the lost PIT interrupt, the negative
> > value between two continual timebase reading will bring to the jump of the
> > jiffies. And this timebase problem will bring to the instability of the
> > gettimeofday system call.
> >
> >          Do you have any idea about this problem, thanks for your any
> > advice. Attached is the code and log.

Hi, has this been resolved yet?

I took an 8377 rdb board, and let it run timebase.c (with the isync &
long long casts) all weekend, and have failed to reproduce the issue.
That was on linux 2.6.33, and I've got another machine running the same
thing under 2.6.28 for the last couple of hours, still unable to
reproduce the issue.

Can you please answer the "custom board or FSL reference board"
question, try duplicating with a newer kernel version, discuss other
time sources that may be running on your system (RTC_DRV, ntp service),
post a .config, ...

Kim

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-04-22  0:44   ` Kim Phillips
@ 2010-04-22  0:50     ` Benjamin Herrenschmidt
  2010-04-22 23:27       ` Kim Phillips
  2010-04-23 10:57     ` Csdncannon
  1 sibling, 1 reply; 23+ messages in thread
From: Benjamin Herrenschmidt @ 2010-04-22  0:50 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-dev, Csdncannon, zhouminggang

On Wed, 2010-04-21 at 19:44 -0500, Kim Phillips wrote:
> I took an 8377 rdb board, and let it run timebase.c (with the isync &
> long long casts) all weekend, and have failed to reproduce the issue.
> That was on linux 2.6.33, and I've got another machine running the
> same
> thing under 2.6.28 for the last couple of hours, still unable to
> reproduce the issue.

Do we need to add an isync to the vdso and kernel gettimeofday() ?

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-04-22  0:50     ` Benjamin Herrenschmidt
@ 2010-04-22 23:27       ` Kim Phillips
  0 siblings, 0 replies; 23+ messages in thread
From: Kim Phillips @ 2010-04-22 23:27 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Csdncannon, zhouminggang

On Thu, 22 Apr 2010 10:50:16 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2010-04-21 at 19:44 -0500, Kim Phillips wrote:
> > I took an 8377 rdb board, and let it run timebase.c (with the isync &
> > long long casts) all weekend, and have failed to reproduce the issue.
> > That was on linux 2.6.33, and I've got another machine running the
> > same
> > thing under 2.6.28 for the last couple of hours, still unable to
> > reproduce the issue.
> 
> Do we need to add an isync to the vdso and kernel gettimeofday() ?

don't see why: I put two gettimeofday calls in a tight loop, checking
if (t2.tv_sec < t1.tv_sec) || (t2.tv_sec > t1.tv_sec + 1), and the
condition was never met.  I also removed all {i,}sync instructions from
timebase.c (but left the long long casts in), and no failures were
reported.

Kim

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Continual reading from the PowerPc time base register is not stable
  2010-04-22  0:44   ` Kim Phillips
  2010-04-22  0:50     ` Benjamin Herrenschmidt
@ 2010-04-23 10:57     ` Csdncannon
  1 sibling, 0 replies; 23+ messages in thread
From: Csdncannon @ 2010-04-23 10:57 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-dev, zhouminggang

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

Hi Kim
      The isync is not needed, when I only added the long long cast, the
problem can never reproduced.

      And I found after Linux started, I ran the "gettime" test code in the
background, if I ran our software application, the gettime could fail
sometimes, and even after killing our software application, the gettime
still failed, if I didn't run our software application after Linux started,
the gettime never fail . I checked out that there is no NTP damone nor cron
tasks running behind, but our software application has the mechanism like
NTP to synchronize time with other boards in our system, the problem is I
cannot figure out why gettime still failed after killing our software
application. Maybe there is a timer running for this proprietary NTP
implementation, even after killing software application?

Thanks
Gino

2010/4/22 Kim Phillips <kim.phillips@freescale.com>

> On Sat, 10 Apr 2010 11:14:09 +0800
> Csdncannon <csdncannon@gmail.com> wrote:
>
> > Sorry, I attached the wrong log, this attachment is the right one.
> >
> > 2010/3/25 Csdncannon <csdncannon@gmail.com>
> >
> > >          In my program, the value of the 64-bit time base register is
> read
> > > out, and you will find the later value is even smaller than the earlier
> > > value from the log “log_timebase”. While the kernel depends on the
> accuracy
> > > of the timebase for the compensation of the lost PIT interrupt, the
> negative
> > > value between two continual timebase reading will bring to the jump of
> the
> > > jiffies. And this timebase problem will bring to the instability of the
> > > gettimeofday system call.
> > >
> > >          Do you have any idea about this problem, thanks for your any
> > > advice. Attached is the code and log.
>
> Hi, has this been resolved yet?
>
> I took an 8377 rdb board, and let it run timebase.c (with the isync &
> long long casts) all weekend, and have failed to reproduce the issue.
> That was on linux 2.6.33, and I've got another machine running the same
> thing under 2.6.28 for the last couple of hours, still unable to
> reproduce the issue.
>
> Can you please answer the "custom board or FSL reference board"
> question, try duplicating with a newer kernel version, discuss other
> time sources that may be running on your system (RTC_DRV, ntp service),
> post a .config, ...
>
> Kim
>

[-- Attachment #2: Type: text/html, Size: 2991 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2010-04-23 10:57 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-25  2:41 Continual reading from the PowerPc time base register is not stable Csdncannon
2010-03-25  8:21 ` Benjamin Herrenschmidt
2010-03-25 10:05   ` Arnd Bergmann
2010-03-25 15:00     ` Csdncannon
2010-03-25 20:38       ` Benjamin Herrenschmidt
2010-03-26  1:11         ` Csdncannon
2010-03-26  1:22           ` Segher Boessenkool
2010-03-26  2:01             ` Csdncannon
2010-03-26  8:52               ` Segher Boessenkool
2010-03-26  9:01                 ` Segher Boessenkool
2010-03-26 12:14                   ` Csdncannon
2010-04-06  8:02                     ` Csdncannon
2010-03-26  1:55           ` Benjamin Herrenschmidt
2010-03-26  2:04             ` Csdncannon
2010-03-25 22:00       ` Chris Friesen
2010-03-25 22:57         ` Benjamin Herrenschmidt
2010-03-25 23:37       ` Kumar Gala
2010-03-25 21:37 ` Segher Boessenkool
2010-04-10  3:14 ` Csdncannon
2010-04-22  0:44   ` Kim Phillips
2010-04-22  0:50     ` Benjamin Herrenschmidt
2010-04-22 23:27       ` Kim Phillips
2010-04-23 10:57     ` Csdncannon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).