mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Gortmaker <p_gortmaker@yahoo.com>
To: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
Cc: Andries.Brouwer@cwi.nl, linux-kernel@vger.kernel.org
Subject: Re: set_rtc_mmss: can't update from 0 to 59
Date: Thu, 21 Dec 2000 04:28:47 -0500	[thread overview]
Message-ID: <3A41CD4F.1259FB08@yahoo.com> (raw)
In-Reply-To: <UTC200012172054.VAA173604.aeb@aak.cwi.nl> <20001217194737.C11947@one-eyed-alien.net>

Matthew Dharm wrote:
> 
> On Sun, Dec 17, 2000 at 09:54:18PM +0100, Andries.Brouwer@cwi.nl 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-12-21 10:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-17 20:54 Andries.Brouwer
2000-12-18  3:47 ` Matthew Dharm
2000-12-18  8:46   ` Russell King
2000-12-19 21:13     ` Oliver Xymoron
2000-12-19 22:25       ` Russell King
2000-12-19 22:53         ` Oliver Xymoron
2000-12-21  9:28   ` Paul Gortmaker [this message]
2000-12-21 10:07     ` Russell King
  -- strict thread matches above, loose matches on Subject: below --
2000-12-18 13:10 Andries.Brouwer
2000-12-18 16:48 ` Matthew Dharm
2000-12-17 20:32 Matthew Dharm
2000-12-18 13:11 ` Matthias Andree

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=3A41CD4F.1259FB08@yahoo.com \
    --to=p_gortmaker@yahoo.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdharm-kernel@one-eyed-alien.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®