Hi Kim<br>      The isync is not needed, when I only added the long long cast, the problem can never reproduced.<br><br>      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 software application, the gettime still failed, if I didn't run our software application after Linux started, the gettime never fail . I checked out that there is no NTP damone nor cron tasks running behind, but our software application has the mechanism like NTP to synchronize time with other boards in our system, the problem is I cannot figure out why gettime still failed after killing our software application. Maybe there is a timer running for this proprietary NTP implementation, even after killing software application?<br>
<br>Thanks<br>Gino<br><br><div class="gmail_quote">2010/4/22 Kim Phillips <span dir="ltr"><<a href="mailto:kim.phillips@freescale.com">kim.phillips@freescale.com</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><div></div><div class="h5">On Sat, 10 Apr 2010 11:14:09 +0800<br>
Csdncannon <<a href="mailto:csdncannon@gmail.com">csdncannon@gmail.com</a>> wrote:<br>
<br>
> Sorry, I attached the wrong log, this attachment is the right one.<br>
><br>
> 2010/3/25 Csdncannon <<a href="mailto:csdncannon@gmail.com">csdncannon@gmail.com</a>><br>
><br>
> >          In my program, the value of the 64-bit time base register is read<br>
> > out, and you will find the later value is even smaller than the earlier<br>
> > value from the log “log_timebase”. While the kernel depends on the accuracy<br>
> > of the timebase for the compensation of the lost PIT interrupt, the negative<br>
> > value between two continual timebase reading will bring to the jump of the<br>
> > jiffies. And this timebase problem will bring to the instability of the<br>
> > 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>
</div></div>Hi, has this been resolved yet?<br>
<br>
I took an 8377 rdb board, and let it run timebase.c (with the isync &<br>
long long casts) all weekend, and have failed to reproduce the issue.<br>
That was on linux 2.6.33, and I've got another machine running the same<br>
thing under 2.6.28 for the last couple of hours, still unable to<br>
reproduce the issue.<br>
<br>
Can you please answer the "custom board or FSL reference board"<br>
question, try duplicating with a newer kernel version, discuss other<br>
time sources that may be running on your system (RTC_DRV, ntp service),<br>
post a .config, ...<br>
<font color="#888888"><br>
Kim<br>
</font></blockquote></div><br>