Ben
Attached is the previous failing one.
Thanks
Gino2010/3/26 Benjamin Herrenschmidt <b...@kernel.crashing.org> > On Fri, 2010-03-26 at 09:11 +0800, Csdncannon wrote: > > 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. > > > Thanks > > Gino > > > > 2010/3/26 Benjamin Herrenschmidt <b...@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 <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
