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 <a...@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 >
timebase.c
Description: Binary data
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
