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 my 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. Accoring to hwclock, it's
less than a second off.
So, what's causing this message?
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Okay, this isn't funny anymore! Let me down! I'll tell Bill on you!!
-- Microsoft Salesman
User Friendly, 4/1/1998
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 does
if (abs(real_minutes - cmos_minutes) < 30) {
update_cmos()
} else {
printk("set_rtc_mmss: can't update from %d to %d\n",
cmos_minutes, real_minutes);
}
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
Of course, messing with the cmos clock at all was a rather bad idea,
but that is a different discussion.
Andries
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 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 does
>
> if (abs(real_minutes - cmos_minutes) < 30) {
> update_cmos()
> } else {
> printk("set_rtc_mmss: can't update from %d to %d\n",
> cmos_minutes, real_minutes);
> }
>
> 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
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.
Hrm.. the logic to get this right is always the type of thing that gets
me... that's why I usually calculate things the UNIX way -- seconds since
an epoch.
> 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 buff? Or change the algorithm to use something like minutes since the
epoch?
Matt
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
We can customize our colonels.
-- Tux
User Friendly, 12/1/1998
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, how do we fix this?
Why do you think it needs fixing?
Think about what happens when the current time according to the CMOS is
2:59:00 and Linux thinks its 3:01:20. We only write the minutes and
seconds, so if we did write, the CMOS clock then becomes 2:01:20.
Oops, we just lost an hour. Next time you reboot, you'll find the
time out by an hour or more depending on how many corrections of this
type have been done.
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
idea of time is UTC. Your CMOS may be programmed for EST for instance).
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
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.
Andries
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 my 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. Accoring to hwclock, it's
> less than a second off.
>
> So, what's causing this message?
Check the power supply cabling, I had those messages due to a faulty
contact on a Tyan S1590, after fixing the P8 and P9 (AT-style) power
plugs, those messages were gone.
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, 2000 at 02:10:32PM +0100, [email protected] wrote:
> 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.
>
> Andries
--
Matthew Dharm Home: [email protected]
Maintainer, Linux USB Mass Storage Driver
Oh BAY-bee.
-- Dust Puppy to Greg
User Friendly, 12/13/1997
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 intentional.
>
> > True enough... but, the question is, how do we fix this?
>
> Why do you think it needs fixing?
>
> Think about what happens when the current time according to the CMOS is
> 2:59:00 and Linux thinks its 3:01:20. We only write the minutes and
> seconds, so if we did write, the CMOS clock then becomes 2:01:20.
> Oops, we just lost an hour. Next time you reboot, you'll find the
> time out by an hour or more depending on how many corrections of this
> type have been done.
>
> 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
> idea of time is UTC. Your CMOS may be programmed for EST for instance).
Sounds like its still broken then - there are time zones which are not
even multiples of 60 minutes.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
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
> > idea of time is UTC. Your CMOS may be programmed for EST for instance).
>
> Sounds like its still broken then - there are time zones which are not
> even multiples of 60 minutes.
Correct; please examine the code and you will find the answer to this.
Specifically, look at the lines around the following comment:
/* correct for half hour time zone */
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
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 is programmed for UTC time or not (the kernel's
> > > idea of time is UTC. Your CMOS may be programmed for EST for instance).
> >
> > Sounds like its still broken then - there are time zones which are not
> > even multiples of 60 minutes.
>
> Correct; please examine the code and you will find the answer to this.
> Specifically, look at the lines around the following comment:
>
> /* correct for half hour time zone */
Uhh.. Kathmandu? Chatham Island? +5:45 and +13:45 (DST) respectively.
At any rate, the printk should go - do_timer_interrupt already expects the
"bug" its reporting.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
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 buff? Or change the algorithm to use something like minutes since the
> epoch?
Actually I agree 100% with Andries -- having the kernel write back its
time into the CMOS RTC every 11 minutes just because NTP is active seems
like a random heuristic that probably "seemed like a good idea at the time".
(Probably made more sense back when there were no other users of the RTC.)
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) ?
Can't the people who want the current behaviour simply have a crontab
that runs (hw)clock -[u]w from util-linux at whatever interval they want?
Then set_rtc_mmss magically goes away, the kernel doesn't need to know
UTC vs. local, and the timer interrupt gets smaller - a Good Thing(tm).
I'd delete set_rtc_mmss entirely, but I just #ifdef'd it out in case
I'm overlooking something...
Paul.
--- linux/arch/i386/kernel/time.c~ Mon Nov 20 04:16:25 2000
+++ linux/arch/i386/kernel/time.c Thu Dec 21 04:10:37 2000
@@ -28,6 +28,9 @@
* 1998-12-24 Copyright (C) 1998 Andrea Arcangeli
* Fixed a xtime SMP race (we need the xtime_lock rw spinlock to
* serialize accesses to xtime/lost_ticks).
+ * 2000-12-20 Paul Gortmaker
+ * Don't mess with the CMOS clock just because NTP is used. This
+ * gets rid of annoying "set_rtc_mmss: can't update ..." messages.
*/
#include <linux/errno.h>
@@ -304,7 +307,16 @@
write_unlock_irq(&xtime_lock);
}
+#ifdef INVALIDATE_ADJTIME
/*
+ * NOTE: This is NOT an externally exported interface for setting
+ * the time stored in the RTC. It is ONLY used internally to store
+ * the kernel time back into the RTC if the kernel time is externally
+ * synchronized. (Yes, this smells like policy in the kernel...)
+ * If you enable this then your /etc/adjtime value(s) are no longer
+ * valid. Conversely, non-zero /etc/adjtime values can result in this
+ * spewing the "set_rtc_mmss: cant update from N to M" messages.
+ *
* In order to set the CMOS clock precisely, set_rtc_mmss has to be
* called 500 ms after the second nowtime has started, because when
* nowtime is written into the registers of the CMOS clock, it will
@@ -374,6 +386,7 @@
/* last time the cmos clock got updated */
static long last_rtc_update;
+#endif
int timer_ack;
@@ -417,6 +430,7 @@
smp_local_timer_interrupt(regs);
#endif
+#ifdef INVALIDATE_ADJTIME
/*
* If we have an externally synchronized Linux clock, then update
* CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
@@ -431,6 +445,7 @@
else
last_rtc_update = xtime.tv_sec - 600; /* do it again in 60 s */
}
+#endif
#ifdef CONFIG_MCA
if( MCA_bus ) {
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
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 adjtimex call to adjust the
local clock. Therefore, when running NTP, leave adjtime well alone
(unless you want to break NTP). You either use NTP or adjtime, not both.
> Can't the people who want the current behaviour simply have a crontab
> that runs (hw)clock -[u]w from util-linux at whatever interval they want?
And how do you handle the situation where NTP hasn't synchronised, and
therefore the local hardware clock should not be updated? Sometimes
the hardware clock is higher precision than the kernels idea of time
(ok, not in cheap PCs).
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |