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.<br><br>We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit.<br>
<br><br>Thanks<br>Gino<br><br><div class="gmail_quote">
2010/3/25 Arnd Bergmann <span dir="ltr"><<a href="mailto:arnd@arndb.de" target="_blank">arnd@arndb.de</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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