Re: Continual reading from the PowerPc time base register is not stable

[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
>