Re: Continual reading from the PowerPc time base register is not stable

[Csdncannon <csdncannon@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

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 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?

Thanks
Gino

2010/4/22 Kim Phillips <kim.phillips@freescale.com>

> On Sat, 10 Apr 2010 11:14:09 +0800
> Csdncannon <csdncannon@gmail.com> wrote:
>
> > Sorry, I attached the wrong log, this attachment is the right one.
> >
> > 2010/3/25 Csdncannon <csdncannon@gmail.com>
> >
> > >          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.
>
> Hi, has this been resolved yet?
>
> 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 the last couple of hours, still unable to
> reproduce the issue.
>
> Can you please answer the "custom board or FSL reference board"
> question, try duplicating with a newer kernel version, discuss other
> time sources that may be running on your system (RTC_DRV, ntp service),
> post a .config, ...
>
> Kim
>

[-- Attachment #2: Type: text/html, Size: 2991 bytes --]