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