Apr 2010 11:14:09 +0800
> Csdncannon wrote:
>
> > Sorry, I attached the wrong log, this attachment is the right one.
> >
> > 2010/3/25 Csdncannon
> >
> > > In my program, the value of the 64-bit time base register is
> read
> > > ou
Sorry, I attached the wrong log, this attachment is the right one.
2010/3/25 Csdncannon
> 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 t
Hi guys
In fact my problem is gettimeofday cannot return right value
sometimes, and this will bring instability to our system software. You can
find a law from the log that there is a 17592 seconds' shift every time
error occurs.
2010/3/26 Csdncannon
> Yes, the missin
Yes, the missing 64-bit conversion is the key problem, I will try removing
isync later.
Thanks for your support.
2010/3/26 Segher Boessenkool
> > Yes indeed. Could you post the relevant piece if disassembly from
> > your original binary (the one that has the problem)? Or send me the
> > bina
Ben
Attached is the previous failing one.
Thanks
Gino
2010/3/26 Benjamin Herrenschmidt
> 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 happe
I enabled the printing of all values. There is bigger gap between two
reading, it seems isync bring to performance drop.
Could you elaborate what does "closer that 64 tick together" mean?
You can see the attached log, the 0x40 is not always set.
Thanks
Gino
2010/3/26 Segher Boessenkool
> > Aft
midt
> 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 FreeS
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
> > > ear
