From: Gabriel Paubert <paubert@iram.es>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Wolfgang Denk <wd@denx.de>, Richard Zidlicky <rz@linux-m68k.org>,
Linux/PPC Development <linuxppc-dev@lists.linuxppc.org>
Subject: Re: set_rtc_time() cleanup / normalization
Date: Tue, 13 May 2003 12:21:45 +0200 [thread overview]
Message-ID: <20030513102145.GA3997@iram.es> (raw)
In-Reply-To: <Pine.GSO.4.21.0305131051420.20323-100000@vervain.sonytel.be>
On Tue, May 13, 2003 at 10:53:28AM +0200, Geert Uytterhoeven wrote:
>
> On Tue, 13 May 2003, Gabriel Paubert wrote:
> > On Tue, May 13, 2003 at 09:52:22AM +0200, Geert Uytterhoeven wrote:
> > > On Mon, 12 May 2003, Wolfgang Denk wrote:
> > > > I would like to find out if there is some consensus about the use of
> > > > set_rtc_time() in the timer interrupt handler.
> > >
> > > On m68k, we removed that part because it confused NTP. Richard Zidlicky can
> > > probably tell more about that.
> >
> > I certainly would like to know the details of this. I believe it may
> > be fixing the symptom rather than the cause (an NTP bug).
>
> As far as I remember, NTP estimates the error of your RTC and uses that
> estimation to correct your time if no NTP server is available, but the
> estimation step fails if the kernel messes with the RTC behind NTP's back.
In this case NTP should never clear the STA_UNSYNC flag shen it
synchronized to the local clock (driver 127.127.0.0 IIRC) . The state
change from 0x41 to 0x01 should never happen for the kernel side of
the status flags, this would avoid creating the loop.
Regards,
Gabriel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-05-13 10:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-12 21:17 set_rtc_time() cleanup / normalization Wolfgang Denk
2003-05-13 0:16 ` Dan Malek
2003-05-13 7:52 ` Geert Uytterhoeven
2003-05-13 8:18 ` Gabriel Paubert
[not found] ` <Pine.GSO.4.21.0305131051420.20323-100000@vervain.sonytel.be>
2003-05-13 10:21 ` Gabriel Paubert [this message]
2003-05-13 13:35 ` Wolfgang Denk
2003-05-13 12:03 ` Richard Zidlicky
2003-05-13 23:05 ` Paul Mackerras
2003-05-13 23:33 ` Eugene Surovegin
2003-05-14 0:08 ` Wolfgang Denk
[not found] ` <5.1.0.14.2.20030513171616.037f6800@mail.ebshome.net>
2003-05-14 3:47 ` Matt Porter
[not found] ` <5.1.0.14.2.20030513214040.02a6e6d0@mail.ebshome.net>
[not found] ` <3EC1DB1F.8000408@embeddededge.com>
2003-05-14 6:41 ` Eugene Surovegin
2003-05-14 6:47 ` Wolfgang Denk
2003-05-14 8:32 ` Benjamin Herrenschmidt
2003-05-14 15:57 ` Gabriel Paubert
2003-05-14 16:41 ` Eugene Surovegin
2003-05-14 15:50 ` Gabriel Paubert
2003-05-14 15:43 ` Gabriel Paubert
2003-05-14 16:28 ` Dan Malek
2003-05-15 18:04 ` Gabriel Paubert
2003-05-15 18:21 ` Wolfgang Denk
[not found] ` <20030515184412.GA22327@iram.es>
2003-05-15 19:37 ` Benjamin Herrenschmidt
[not found] <20030514230638.GB1687@linux-m68k.org>
[not found] ` <Pine.GSO.4.21.0305151031410.13683-100000@vervain.sonytel.be>
2003-05-15 10:45 ` Gabriel Paubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030513102145.GA3997@iram.es \
--to=paubert@iram.es \
--cc=geert@linux-m68k.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=rz@linux-m68k.org \
--cc=wd@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.