Hi Kim
The isync is not needed, when I only added the long long cast, the
problem can never reproduced.
And I found after Linux started, I ran the "gettime" test code in the
background, if I ran our software application, the gettime could fail
sometimes, and even after killing our soft
On Thu, 22 Apr 2010 10:50:16 +1000
Benjamin Herrenschmidt wrote:
> On Wed, 2010-04-21 at 19:44 -0500, Kim Phillips wrote:
> > I took an 8377 rdb board, and let it run timebase.c (with the isync &
> > long long casts) all weekend, and have failed to reproduce the issue.
> > That was on linux 2.6.3
On Wed, 2010-04-21 at 19:44 -0500, Kim Phillips wrote:
> I took an 8377 rdb board, and let it run timebase.c (with the isync &
> long long casts) all weekend, and have failed to reproduce the issue.
> That was on linux 2.6.33, and I've got another machine running the
> same
> thing under 2.6.28 for
On Sat, 10 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
> > out, and you will find the later value is even smaller than th
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 the kernel de
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 missing 64-bit conversion
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
> Yes indeed. Could you post the relevant piece if disassembly from
> your original binary (the one that has the problem)? Or send me the
> binary (not to the mailing list), I'll do it then.
Ah scratch that. I compiled your original code (after fixing the
compile errors -- there is no such type
[please do not top-post]
>> Do you now ever get two consecutive time readings that are closer
>> that 64 tick together? If not, it's simply hiding the problem.
>>
>> Do you ever now read a value that does not have the bit with value
>> 0x40 set?
> I enabled the printing of all values. There is b
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 happen(I tested for several minutes).
> > B
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
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
> After trying the new code with "isync" and unsigned long long convertion,
> this problem doesn't happen(I tested for several minutes).
Do you now ever get two consecutive time readings that are closer
that 64 tick together? If not, it's simply hiding the problem.
Do you ever now read a value t
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?
Thanks
Gino
2010/3/26 Benjamin Herrenschmidt
> On Thu,
On Mar 25, 2010, at 10:00 AM, 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.
>
>
> Thanks
>
On Thu, 2010-03-25 at 16:00 -0600, Chris Friesen wrote:
> Shouldn't "upper" be cast to 64-bit before shifting?
Yup but that doesn't explain his results. I think Segher nailed it to a
stuck bit tho, so I would blame defective HW or HW used outside of
normal operating conditions (maybe the TB is sou
On 03/25/2010 09:00 AM, 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.
volatile unsigned long
> 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.
> Do you have any idea about this problem, thanks for your any
> advice. Attached is the code and log
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 despi
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
> On Thursday 25 March 2010, Benja
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_time
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
22 matches
Mail list logo
