Paul Gortmaker writes:
> It smells like policy in the kernel to me. What if a user wants to run NTP
> but wants the CMOS RTC time as an independent clock to do something else
> (possibly with the option of having a meaningful /etc/adjtime too) ?
NTP and adjtime are synomonous - NTP uses the adjt
Matthew Dharm wrote:
>
> On Sun, Dec 17, 2000 at 09:54:18PM +0100, [EMAIL PROTECTED] wrote:
>
> > Of course, messing with the cmos clock at all was a rather bad idea,
> > but that is a different discussion.
>
> True enough... but, the question is, how do we fix this? Make the logic
> more buf
On Tue, 19 Dec 2000, Russell King wrote:
> Oliver Xymoron writes:
> > On Mon, 18 Dec 2000, Russell King wrote:
> > > So, why don't we update the hours and be done with it? We would have to
> > > play the same game with the days of the month vs hours. Also, we don't
> > > know if the CMOS clock
Oliver Xymoron writes:
> On Mon, 18 Dec 2000, Russell King wrote:
> > So, why don't we update the hours and be done with it? We would have to
> > play the same game with the days of the month vs hours. Also, we don't
> > know if the CMOS clock is programmed for UTC time or not (the kernel's
> >
On Mon, 18 Dec 2000, Russell King wrote:
> Matthew Dharm writes:
> > Ahh... I think I see. While the math says "if the diference between the
> > real time and the cmos time is less than 30 min", it doesn't recognize that
> > the time difference between 2:59 and 3:00 is only 1 min.
>
> Which is i
Honestly, this is the best solution I've heard. It seems that the message
is somewhat bogus, anyway, seeing as how this message is somewhat "normal"
and just represents the occasional occurance of a fast cmos clock with
xntpd and running the code near the top of the hour.
Matt
On Mon, Dec 18, 2
On Sun, 17 Dec 2000, Matthew Dharm wrote:
> I was trying to figure out why I periodically get the message
>
> set_rtc_mmss: can't update from 0 to 59
>
> on my console. It appears that the kernel is attempting to update my CMOS
> clock for me, based on the more accurate data being provided by
From [EMAIL PROTECTED] Mon Dec 18 04:47:51 2000
> so if your cmos time is 0.001 sec ahead of your system time
> then around the hour you'll see
> set_rtc_mmss: can't update from 0 to 59
but, the question is, how do we fix this?
Put #if 0 ... #endif around the printk.
An
Matthew Dharm writes:
> Ahh... I think I see. While the math says "if the diference between the
> real time and the cmos time is less than 30 min", it doesn't recognize that
> the time difference between 2:59 and 3:00 is only 1 min.
Which is intentional.
> True enough... but, the question is,
On Sun, Dec 17, 2000 at 09:54:18PM +0100, [EMAIL PROTECTED] wrote:
> What architecture?
i386
> What kernel version?
2.4.0-test13-pre2, but this has been happening for a while.
> Are you in fact running xntpd?
Yes.
> > According to the notes in the code, this should work if my RTC
> > is less
What architecture?
What kernel version?
Are you in fact running xntpd?
> According to the notes in the code, this should work if my RTC
> is less than 15 minutes off... which I can guarantee it is.
Well, since you looked at the source:
For some randomly chosen kernel version and architecture it
11 matches
Mail list logo
