Ben
       Attached is the previous failing one.

Thanks
Gino

2010/3/26 Benjamin Herrenschmidt [off-list ref]

On Fri, 2010-03-26 at 09:11 +0800, Csdncannon wrote:

quoted

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.

quoted

Thanks
Gino

2010/3/26 Benjamin Herrenschmidt [off-list ref]
        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 [off-list ref]
        >         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
        >