From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pw0-f42.google.com (mail-pw0-f42.google.com [209.85.160.42]) by ozlabs.org (Postfix) with ESMTP id 8D9B1B7D1F for ; Fri, 23 Apr 2010 20:57:57 +1000 (EST) Received: by pwi8 with SMTP id 8so6308275pwi.15 for ; Fri, 23 Apr 2010 03:57:56 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20100421194419.3edf2c80.kim.phillips@freescale.com> References: <43c137a81003241941p84cba56y3e02e40cb22623e2@mail.gmail.com> <20100421194419.3edf2c80.kim.phillips@freescale.com> Date: Fri, 23 Apr 2010 18:57:55 +0800 Message-ID: Subject: Re: Continual reading from the PowerPc time base register is not stable From: Csdncannon To: Kim Phillips Content-Type: multipart/alternative; boundary=000e0cd1b2eeaf660f0484e54c70 Cc: linuxppc-dev@ozlabs.org, zhouminggang@hotmail.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --000e0cd1b2eeaf660f0484e54c70 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 > 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 the earli= er > > > value from the log =93log_timebase=94. While the kernel depends on th= e > 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 o= f > the > > > jiffies. And this timebase problem will bring to the instability of t= he > > > 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 > --000e0cd1b2eeaf660f0484e54c70 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Kim
=A0=A0=A0=A0=A0 The isync is not needed, when I only added the lo= ng long cast, the problem can never reproduced.

=A0=A0=A0=A0=A0 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 some= times, and even after killing our software application, the gettime still f= ailed, if I didn't run our software application after Linux started, th= e gettime never fail . I checked out that there is no NTP damone nor cron t= asks running behind, but our software application has the mechanism like NT= P to synchronize time with other boards in our system, the problem is I can= not figure out why gettime still failed after killing our software applicat= ion. Maybe there is a timer running for this proprietary NTP implementation= , even after killing software application?

Thanks
Gino

2010/4/22 Kim Phillips= <kim.ph= illips@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 <csdnc= annon@gmail.com>
>
> > =A0 =A0 =A0 =A0 =A0In my program, the value of the 64-bit time ba= se register is read
> > out, and you will find the later value is even smaller than the e= arlier
> > value from the log =93log_timebase=94. While the kernel depends o= n the accuracy
> > of the timebase for the compensation of the lost PIT interrupt, t= he negative
> > value between two continual timebase reading will bring to the ju= mp of the
> > jiffies. And this timebase problem will bring to the instability = of the
> > gettimeofday system call.
> >
> > =A0 =A0 =A0 =A0 =A0Do you have any idea about this problem, thank= s 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

--000e0cd1b2eeaf660f0484e54c70--