PROBLEM: Linux updates RTC secretly when clock synchronizes.
Please CC replies etc to Ian Maclaine-cross <[email protected]>.
When /usr/sbin/ntpd synchronizes the Linux kernel (or system) clock
using the Network Time Protocol the kernel time is accurate to a few
milliseconds. Linux then sets the Real Time (or Hardware or CMOS)
Clock to this time at approximately 11 minute intervals. Typical RTCs
drift less than 10 s/day so rebooting causes only millisecond errors.
Linux currently does not record the 11 minute updates to a log file.
Clock programs (like hwclock) cannot correct RTC drift at boot without
knowing when the RTC was last set. If NTP service is available after a
long shutdown, ntpd may step the time. Worse after a longer shutdown
ntpd may drop out or even synchronize to the wrong time zone. The
workarounds are clumsy.
Please find following my small patch for linux/arch/i386/kernel/time.c
which adds a KERN_NOTICE of each 11 minute update to the RTC. This is
just for i386 machines at present. A script can search the logs for
the last set time of the RTC and update /etc/adjtime. Hwclock can
then correct the RTC for drift and set the kernel clock.
I patched Linux 2.2.19 and 2.4.12 then compiled, installed and
rebooted on Pentium MMX and AMD K6-III machines respectively. When the
kernel clock synchronized "...: Real Time Clock set at xxx s" appeared
in the kernel log every 661 s where "xxx" was the current system
time. Messages ceased whenever the clock was unsynchronized. Ntpd
produces typically four log lines in 661 s so the increase in log
volume is small for ntpd users and nothing for nonusers. The patch
added 11 bytes to the size of my compressed kernel.
diff -u --recursive linux.old/arch/i386/kernel/time.c linux/arch/i386/kernel/time.c
--- linux.old/arch/i386/kernel/time.c Mon Oct 29 16:37:19 2001
+++ linux/arch/i386/kernel/time.c Mon Oct 29 16:42:03 2001
@@ -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).
+ * 2001-10-28 Ian Maclaine-cross
+ * Added KERN_NOTICE of each ~11 minute update to RTC. If no time source
+ * on boot hwclock etc can correct RTC drift error with last logged time.
*/
#include <linux/errno.h>
@@ -435,8 +438,12 @@
xtime.tv_sec > last_rtc_update + 660 &&
xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
xtime.tv_usec <= 500000 + ((unsigned) tick) / 2) {
- if (set_rtc_mmss(xtime.tv_sec) == 0)
+ if (set_rtc_mmss(xtime.tv_sec) == 0) {
last_rtc_update = xtime.tv_sec;
+ printk(KERN_NOTICE
+ "Real Time Clock set at %d s\n",
+ last_rtc_update);
+ }
else
last_rtc_update = xtime.tv_sec - 600; /* do it again in 60 s */
}
--
Regards,
Ian Maclaine-cross ([email protected])
On Wed, Oct 31, 2001 at 11:33:12AM +1100, Ian Maclaine-cross wrote:
>
> PROBLEM: Linux updates RTC secretly when clock synchronizes.
>
> When /usr/sbin/ntpd synchronizes the Linux kernel (or system) clock
> using the Network Time Protocol the kernel time is accurate to a few
> milliseconds. Linux then sets the Real Time (or Hardware or CMOS)
> Clock to this time at approximately 11 minute intervals. Typical RTCs
> drift less than 10 s/day so rebooting causes only millisecond errors.
This is all in the manpage, see man hwclock. If you use ntpd,
you probably don't want hwclock to adjust, just set the time.
Kurt
On Wed, Oct 31, 2001 at 02:05:38AM +0100, Kurt Roeckx wrote:
> On Wed, Oct 31, 2001 at 11:33:12AM +1100, Ian Maclaine-cross wrote:
> >
> > PROBLEM: Linux updates RTC secretly when clock synchronizes.
> >
> > When /usr/sbin/ntpd synchronizes the Linux kernel (or system) clock
> > using the Network Time Protocol the kernel time is accurate to a few
> > milliseconds. Linux then sets the Real Time (or Hardware or CMOS)
> > Clock to this time at approximately 11 minute intervals. Typical RTCs
> > drift less than 10 s/day so rebooting causes only millisecond errors.
[snip]
>
>
> This is all in the manpage, see man hwclock. If you use ntpd,
> you probably don't want hwclock to adjust, just set the time.
>
> Kurt
>
When the machine reboots from a power interruption Internet connection
may be unavailable (usual here). Ntpd can start synchronized to an RTC
but time is inaccurate because hwclock has not adjusted it. When
Internet connection reestablishes ntpd notices the time conflict and
terminates. Human intervention or cron lines can run ntpdate and then
restart ntpd. This results in time of low quality.
There are lots of high quality and cost hardware solutions. The
solution in my first post was a very small kernel patch to add an
11 minute update log so hwclock etc could adjust the time. Any
comments on my patch?
--
Regards,
Ian Maclaine-cross ([email protected])
On Wed, Oct 31, 2001 at 01:55:07PM +1100, Ian Maclaine-cross wrote:
> On Wed, Oct 31, 2001 at 02:05:38AM +0100, Kurt Roeckx wrote:
> > On Wed, Oct 31, 2001 at 11:33:12AM +1100, Ian Maclaine-cross wrote:
> > >
> > > PROBLEM: Linux updates RTC secretly when clock synchronizes.
> > >
> > > When /usr/sbin/ntpd synchronizes the Linux kernel (or system) clock
> > > using the Network Time Protocol the kernel time is accurate to a few
> > > milliseconds. Linux then sets the Real Time (or Hardware or CMOS)
> > > Clock to this time at approximately 11 minute intervals. Typical RTCs
> > > drift less than 10 s/day so rebooting causes only millisecond errors.
>
> When the machine reboots from a power interruption Internet connection
> may be unavailable (usual here). Ntpd can start synchronized to an RTC
> but time is inaccurate because hwclock has not adjusted it. When
> Internet connection reestablishes ntpd notices the time conflict and
> terminates. Human intervention or cron lines can run ntpdate and then
> restart ntpd. This results in time of low quality.
I'm not really sure about this, but I think you need a *high*
offset, like in the order of an hour, before ntpd refused to
adjust. I know it happely does 5 minutes.
> There are lots of high quality and cost hardware solutions. The
> solution in my first post was a very small kernel patch to add an
> 11 minute update log so hwclock etc could adjust the time. Any
> comments on my patch?
Note that hwclock does not adjust the clock if the error is
smaller than 1 second, or it already wrote to the RTC is the past
23 hours.
It would only help if your box was down for more then a day. In
that case it probably also drifted for more then a second.
I don't know how to set up ntpd to synch to the RTC clock, but I
doubt it would take the drift it has into account.
Also note that in case the kernel writes the time to the RTC
clock, hwclock can't calculate the drift it has properly because
it is calculated the time it writes to the RTC.
What you probably want to do is disable the kernel writing the
time to the RTC, and let hwclock do write the time to the RTC so
it can calculate the drift properly, and adjust for it during
startup.
Ntpd will also adjust the frequency of the system clock, and you
should get a reasonable accurate time.
Btw: Last time I looked at it (util-linux-2.11h), the calculation
of the driftfactor in hwclock was still pretty inaccurate. I
once did send patch for it, but it doesn't seem to be included.
There also is an adjtime.patch included you could use.
Kurt
Hi Kurt.
>>>> PROBLEM: Linux updates RTC secretly when clock synchronizes.
>>>>
>>>> When /usr/sbin/ntpd synchronizes the Linux kernel (or system) clock
>>>> using the Network Time Protocol the kernel time is accurate to a
>>>> few milliseconds. Linux then sets the Real Time (or Hardware or
>>>> CMOS) Clock to this time at approximately 11 minute intervals.
>>>> Typical RTCs drift less than 10 s/day so rebooting causes only
>>>> millisecond errors.
>> When the machine reboots from a power interruption Internet
>> connection may be unavailable (usual here). Ntpd can start
>> synchronized to an RTC but time is inaccurate because hwclock has
>> not adjusted it. When Internet connection reestablishes ntpd notices
>> the time conflict and terminates. Human intervention or cron lines
>> can run ntpdate and then restart ntpd. This results in time of low
>> quality.
> I'm not really sure about this, but I think you need a *high*
> offset, like in the order of an hour, before ntpd refused to adjust.
> I know it happely does 5 minutes.
The offset needs to be sufficient to handle the case of the RTC being
set to local time and the boot and first ntp sync occurring on opposite
sides of a Daylight Savings Time change. A couple of timezones use a DST
offset of 90 minutes, so if it's less than that, there will be problems.
>> There are lots of high quality and cost hardware solutions. The
>> solution in my first post was a very small kernel patch to add an 11
>> minute update log so hwclock etc could adjust the time. Any comments
>> on my patch?
> Note that hwclock does not adjust the clock if the error is smaller
> than 1 second, or it already wrote to the RTC is the past 23 hours.
I knew about the "not less than 1 second" restriction, but not the "only
once a day" restriction. Can you confirm that the latter restriction is
indeed the case please?
Best wishes from Riley.
On Thu, Nov 01, 2001 at 12:52:19AM +0000, Riley Williams wrote:
>
> > Note that hwclock does not adjust the clock if the error is smaller
> > than 1 second, or it already wrote to the RTC is the past 23 hours.
>
> I knew about the "not less than 1 second" restriction, but not the "only
> once a day" restriction. Can you confirm that the latter restriction is
> indeed the case please?
Oh, I made a little mistake.
It doesn't recalculate the factor if it did in the last 23 hours,
too make it more accurate. The calculation isn't really
accurate, but gets more accurate the longer the period between
them.
In adjust_drift_factor():
} else if ((hclocktime - adjtime_p->last_calib_time) < 23 * 60 * 60) {
if (debug)
printf(_("Not adjusting drift factor because it has been less than a "
"day since the last calibration.\n"));
Kurt
--On Thursday, November 01, 2001 12:52 AM +0000 Riley Williams
<[email protected]> wrote:
> The offset needs to be sufficient to handle the case of the RTC being
> set to local time and the boot and first ntp sync occurring on opposite
> sides of a Daylight Savings Time change. A couple of timezones use a DST
> offset of 90 minutes, so if it's less than that, there will be problems.
There is a related problem, where if you are running something which
can suspend, like a laptop, but not using integrated apm to do it (for
instance a laptop which has a broken BIOS), then suspending 'freezes'
the system time, which is wrong on resume (as the power management
event appears to be invisible to Linux). Then this goes and blats
over the (correct) RTC time. If you then get a network connection up,
ntp won't adjust the time as it's too far out. What I wanted was
an option which did the copy the other way on a large offset - i.e.
keep the RTC in sync for smallish offsets, but if the offset is
wrong by more than 5 minutes (and RTC is in advance), copy RTC to
system time as the laptop probably suspended. There might of course
be a better hueristic to detect this (perhaps every time it does
the check see if it got out of sync by > the interval between
checks). Short of this, it would be useful to be able to turn /off/
futzing with the rtc.
--
Alex Bligh
Hi Alex.
>> The offset needs to be sufficient to handle the case of the RTC
>> being set to local time and the boot and first ntp sync occurring on
>> opposite sides of a Daylight Savings Time change. A couple of
>> timezones use a DST offset of 90 minutes, so if it's less than that,
>> there will be problems.
> There is a related problem, where if you are running something which
> can suspend, like a laptop, but not using integrated apm to do it
> (for instance a laptop which has a broken BIOS), then suspending
> 'freezes' the system time, which is wrong on resume (as the power
> management event appears to be invisible to Linux). Then this goes
> and blats over the (correct) RTC time. If you then get a network
> connection up, ntp won't adjust the time as it's too far out.
That sounds like a configuration error to me, and here's why.
1. One of the available reference clocks for xntpd is the local
RTC, type 1 in the list of reference clock types, and that
should ALWAYS be listed as one of the reference clocks to use,
but with a higher stratum than any other reference clock used.
2. My experience with the xntpd driver suggests that if no better
reference is available and the RTC is one of the listed clocks,
then it ALWAYS adjusts the time to match the RTC, irrespective
of the time difference between them.
3. AFAICT, if xntpd writes to the RTC, then it has achieved true
synchronisation to a reference clock other than the RTC.
It's for these reasons that I'm rather puzzled by the comments in this
thread so far.
> What I wanted was an option which did the copy the other way on a
> large offset - i.e. keep the RTC in sync for smallish offsets, but
> if the offset is wrong by more than 5 minutes (and RTC is in
> advance), copy RTC to system time as the laptop probably suspended.
If you have the RTC as one of your reference clocks, then this heuristic
is not required as xntpd (at least) does the right thing for you.
> There might of course be a better heuristic to detect this (perhaps
> every time it does the check see if it got out of sync by > the
> interval between checks).
Probably the 'heuristic' of ensuring that the RTC is one of the
reference clocks is sufficient.
> Short of this, it would be useful to be able to turn /off/ futzing
> with the RTC.
True.
Best wishes from Riley.
Riley,
> That sounds like a configuration error to me, and here's why.
>
> 1. One of the available reference clocks for xntpd is the local
> RTC, type 1 in the list of reference clock types, and that
> should ALWAYS be listed as one of the reference clocks to use,
> but with a higher stratum than any other reference clock used.
Well, perhaps that's a difference between xntpd and ntpd - I am
using the latter, version 4.1.0, from Debian testing. Manpage
doesn't mention RTC, ntpdc doesn't seem to find it. I may
well be out of sync with ntpd (pun fully intended) as I haven't
looked at it for a while, but...
> 2. My experience with the xntpd driver suggests that if no better
> reference is available and the RTC is one of the listed clocks,
> then it ALWAYS adjusts the time to match the RTC, irrespective
> of the time difference between them.
... you are assuming that the RTC doesn't get adjusted first (to
match the system clock)!
> 3. AFAICT, if xntpd writes to the RTC, then it has achieved true
> synchronisation to a reference clock other than the RTC.
I thought the original poster was claiming that the /kernel/
wrote to the RTC, which would explain the behaviour I'm seeing.
An alternative explanation I suppose is simply that nothing
is writing to the RTC (not ntpd, not anything) except for
the final clock command as the machine shuts down. Very simply
the symptom is that both clocks are correct, I suspend the
machine (without APM in the kernel), I resume it, reboot
it, and now both clocks are wrong.
> If you have the RTC as one of your reference clocks, then this heuristic
> is not required as xntpd (at least) does the right thing for you.
OK I will go read the manpage even harder.
--
Alex Bligh
Hi Alex.
>> That sounds like a configuration error to me, and here's why.
>>
>> 1. One of the available reference clocks for xntpd is the local
>> RTC, type 1 in the list of reference clock types, and that
>> should ALWAYS be listed as one of the reference clocks to use,
>> but with a higher stratum than any other reference clock used.
> Well, perhaps that's a difference between xntpd and ntpd - I am
> using the latter, version 4.1.0, from Debian testing.
I'm currently on RedHat 6.2 on the system in question, and I have the
xntp3-5.93-14.i386.rpm package installed. I can only comment on that as
a result.
> Manpage doesn't mention RTC, ntpdc doesn't seem to find it. I may
> well be out of sync with ntpd (pun fully intended) as I haven't
> looked at it for a while, but...
The following is the start of my /etc/ntp.conf file, so perhaps you can
compare it to yours and advise if it looks anywhere near similar...
===8<=== CUT ===>8===
# Remote systems I am authorised to synchronise to.
#
server ntp4.cs.strath.ac.uk
#
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 10. Since the server line does not have the prefer keyword, this
# driver is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
===8<=== CUT ===>8===
The lines starting with '#' are comments describing the reasons for the
choices in question, and this is the only interesting part of the
configuration file as far as this discussion is concerned.
The first server line specifies the clock source to be used when I'm
online, this one being at the University of Strathclyde in Scotland, and
is one that I have obtained permission to use. As nothing else is given,
it stands at stratum 2 (as obtained on request from the timeserver
itself).
The second server line specifies 127.127.1.0 which is the address that
ntp associates with the local RTC clock. The fudge line that follows
specifies that this is to stand at stratum 10, and thus that it is
considerably less reliable than the first server line. It therefore gets
ignored when the first listed server is available, and is only used if
nothing better can be contacted.
>> 2. My experience with the xntpd driver suggests that if no better
>> reference is available and the RTC is one of the listed clocks,
>> then it ALWAYS adjusts the time to match the RTC, irrespective
>> of the time difference between them.
> ... you are assuming that the RTC doesn't get adjusted first (to
> match the system clock)!
If it does, what adjusts it?
>> 3. AFAICT, if xntpd writes to the RTC, then it has achieved true
>> synchronisation to a reference clock other than the RTC.
> I thought the original poster was claiming that the /kernel/
> wrote to the RTC, which would explain the behaviour I'm seeing.
The kernel itself never writes to the RTC, and that is one of Linus's
decisions with which I am in 100% agreeance (and one thing I hate about
Windows). In fact, the kernel itself also doesn't read from the RTC
either, but leaves that to userspace.
> An alternative explanation I suppose is simply that nothing is
> writing to the RTC (not ntpd, not anything) except for the final
> clock command as the machine shuts down. Very simply the symptom is
> that both clocks are correct, I suspend the machine (without APM in
> the kernel), I resume it, reboot it, and now both clocks are wrong.
That's possible. However, I'd start by grep'ing your bootup and shutdown
scripts for lines containing the word 'clock' either on its own or as
part of a longer word, where those lines are not comments. If you have a
RedHat distribution, then...
Q> find /etc -type f | xargs fgrep clock /dev/null | fgrep -v ':#'
...will give you a list of possibilities. Go through these and check
what each one is doing, and if any are SETTING the RTC, then comment
them out. Let me know whether that cures your problem. The reason for
this is that the standard RTC setting programmes are `clock` and
`hwclock` and either can be told to copy the current system time into
the RTC.
>> If you have the RTC as one of your reference clocks, then this
>> heuristic is not required as xntpd (at least) does the right thing
>> for you.
> OK I will go read the manpage even harder.
If it's not the above, please advise what you find.
Best wishes from Riley.
Riley,
> server 127.127.1.0 # local clock
> fudge 127.127.1.0 stratum 10
'attempt to configure invalid address 127.127.1.0'; guess
ntpd (as opposed to xntpd) doesn't support it.
>> ... you are assuming that the RTC doesn't get adjusted first (to
>> match the system clock)!
>
> If it does, what adjusts it?
I got confused by the kernel /reading/ the CMOS clock,
and the symptoms the original reporter suggested (see
subject line). My symptoms came from non-APM driven
suspend (hence high time offset, no clock/hwclock
invocation) and writing back system clock to cmos clock
on shutdown, AND ntp not adjusting if the date difference
is greater than some small value AND ntpdate not being
able to get to any time server including the CMOS clock
when it was run; sigh...
>>> 3. AFAICT, if xntpd writes to the RTC, then it has achieved true
>>> synchronisation to a reference clock other than the RTC.
>
>> I thought the original poster was claiming that the /kernel/
>> wrote to the RTC, which would explain the behaviour I'm seeing.
>
> The kernel itself never writes to the RTC, and that is one of Linus's
> decisions with which I am in 100% agreeance (and one thing I hate about
> Windows). In fact, the kernel itself also doesn't read from the RTC
> either, but leaves that to userspace.
The kernel does read from the rtc to support /dev/rtc, and in
the apm code. AIUI that's why the kernel needs to know
via config whether your RTC is in UTC (else that could
be done in userspace too). You are probably correct that
it doesn't write to it.
> please advise what you find.
Summary:
1. ntpd (as opposed to xntpd) doesn't seem to support the rtc,
as a clock source, at least not in the same way.
2. suspending your laptop in a manner other than using apm
doesn't do good things to the RTC when you later shut
the machine down, with standard scripts.
3. Check your ntpdate on init is doing what you think it's
doing.
--
Alex Bligh
On Sat, Nov 03, 2001 at 06:35:44PM +0000, Riley Williams wrote:
> server 127.127.1.0 # local clock
> fudge 127.127.1.0 stratum 10
>
> The second server line specifies 127.127.1.0 which is the address that
> ntp associates with the local RTC clock.
>From refclock_local:
* This is a hack to allow a machine to use its own system clock as a
* reference clock
This just calls gettimeofday() indirectly.
It's the system clock, not the RTC. Afaik, there is no support
for the RTC clock.
> >> 2. My experience with the xntpd driver suggests that if no better
> >> reference is available and the RTC is one of the listed clocks,
> >> then it ALWAYS adjusts the time to match the RTC, irrespective
> >> of the time difference between them.
>
> > ... you are assuming that the RTC doesn't get adjusted first (to
> > match the system clock)!
>
> If it does, what adjusts it?
ntpd asks the kernel to write the time to the RTC. I think it
does that from the moment it's sycnhed. If it would be reading
and writing to the RTC, you could have a problem.
> >> 3. AFAICT, if xntpd writes to the RTC, then it has achieved true
> >> synchronisation to a reference clock other than the RTC.
>
> > I thought the original poster was claiming that the /kernel/
> > wrote to the RTC, which would explain the behaviour I'm seeing.
>
> The kernel itself never writes to the RTC, and that is one of Linus's
> decisions with which I am in 100% agreeance (and one thing I hate about
> Windows). In fact, the kernel itself also doesn't read from the RTC
> either, but leaves that to userspace.
The kernel does write to the RTC if told to do so, every 11
minutes. This is broken because it doesn't even know what hour
it should be writing, so it doesn't write it.
In arch/i386/kernel/time.c/do_timer_interrupt():
/*
* If we have an externally synchronized Linux clock, then update
* CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
* called as close as possible to 500 ms before the new second starts.
*/
if ((time_status & STA_UNSYNC) == 0 &&
xtime.tv_sec > last_rtc_update + 660 &&
xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
xtime.tv_usec <= 500000 + ((unsigned) tick) / 2) {
if (set_rtc_mmss(xtime.tv_sec) == 0)
last_rtc_update = xtime.tv_sec;
else
last_rtc_update = xtime.tv_sec - 600; /* do it again in
60 s */
}
Kurt
Hi!
> PROBLEM: Linux updates RTC secretly when clock synchronizes.
>
> Please CC replies etc to Ian Maclaine-cross <[email protected]>.
>
> When /usr/sbin/ntpd synchronizes the Linux kernel (or system) clock
> using the Network Time Protocol the kernel time is accurate to a few
> milliseconds. Linux then sets the Real Time (or Hardware or CMOS)
> Clock to this time at approximately 11 minute intervals. Typical RTCs
> drift less than 10 s/day so rebooting causes only millisecond errors.
>
> Linux currently does not record the 11 minute updates to a log file.
> Clock programs (like hwclock) cannot correct RTC drift at boot without
> knowing when the RTC was last set. If NTP service is available after a
> long shutdown, ntpd may step the time. Worse after a longer shutdown
> ntpd may drop out or even synchronize to the wrong time zone. The
> workarounds are clumsy.
>
> Please find following my small patch for linux/arch/i386/kernel/time.c
> which adds a KERN_NOTICE of each 11 minute update to the RTC. This is
> just for i386 machines at present. A script can search the logs for
> the last set time of the RTC and update /etc/adjtime. Hwclock can
> then correct the RTC for drift and set the kernel clock.
That seems as very wrong solution.
What about just making kernel only _read_ system clock, and never set it?
That looks way cleaner to me.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi Pavel.
>> PROBLEM: Linux updates RTC secretly when clock synchronizes.
>>
>> Please CC replies etc to Ian Maclaine-cross <[email protected]>.
>>
>> When /usr/sbin/ntpd synchronizes the Linux kernel (or system) clock
>> using the Network Time Protocol the kernel time is accurate to a few
>> milliseconds. Linux then sets the Real Time (or Hardware or CMOS)
>> Clock to this time at approximately 11 minute intervals. Typical
>> RTCs drift less than 10 s/day so rebooting causes only millisecond
>> errors.
>>
>> Linux currently does not record the 11 minute updates to a log file.
>> Clock programs (like hwclock) cannot correct RTC drift at boot time
>> without knowing when the RTC was last set. If NTP service is available
>> after a long shutdown, ntpd may step the time. Worse after a longer
>> shutdown ntpd may drop out or even synchronize to the wrong timezone.
>> The workarounds are clumsy.
>>
>> Please find following my small patch for
>> linux/arch/i386/kernel/time.c which adds a KERN_NOTICE of each 11
>> minute update to the RTC. This is just for i386 machines at present.
>> A script can search the logs for the last set time of the RTC and
>> update /etc/adjtime. Hwclock can then correct the RTC for drift and
>> set the kernel clock.
> That seems as very wrong solution.
> What about just making kernel only _read_ system clock, and never
> set it? That looks way cleaner to me.
It is cleaner. However, I feel that the RTC code should printk (at least
as KERN_DEBUG if not as KERN_NOTICE) whenever the RTC is written to.
It's too important a subsystem to be left hidden like it currently is.
Best wishes from Riley.
Hi Pavel,
On Fri, Nov 02, 2001 at 12:16:03PM +0000, Pavel Machek wrote:
> Hi!
>
> > PROBLEM: Linux updates RTC secretly when clock synchronizes.
> >
> > Please CC replies etc to Ian Maclaine-cross <[email protected]>.
> >
> > When /usr/sbin/ntpd synchronizes the Linux kernel (or system) clock
> > using the Network Time Protocol the kernel time is accurate to a few
> > milliseconds. Linux then sets the Real Time (or Hardware or CMOS)
> > Clock to this time at approximately 11 minute intervals. Typical RTCs
> > drift less than 10 s/day so rebooting causes only millisecond errors.
> >
> > Linux currently does not record the 11 minute updates to a log file.
> > Clock programs (like hwclock) cannot correct RTC drift at boot without
> > knowing when the RTC was last set. If NTP service is available after a
> > long shutdown, ntpd may step the time. Worse after a longer shutdown
> > ntpd may drop out or even synchronize to the wrong time zone. The
> > workarounds are clumsy.
> >
> > Please find following my small patch for linux/arch/i386/kernel/time.c
> > which adds a KERN_NOTICE of each 11 minute update to the RTC. This is
> > just for i386 machines at present. A script can search the logs for
> > the last set time of the RTC and update /etc/adjtime. Hwclock can
> > then correct the RTC for drift and set the kernel clock.
>
> That seems as very wrong solution.
>
> What about just making kernel only _read_ system clock, and never set it?
> That looks way cleaner to me.
QUESTION: What results in best timekeeping by the RTC, constant
updates or logging the offset?
ANSWER:
The Linux kernel code for the 11 minute update in
arch/i386/kernel/time.c has an RTC setting error of +-0.005 s. The
adjtimex source suggests an RTC reading error of +-0.000025 s.
Accurate RTC timekeeping also requires an accurate value of average
drift rate for typical use. Measuring this requires timing over a long
unset period such as one month.
Logging the offset is more accurate per reading and allows
more accurate measurement of drift than 11 minute updates.
END ANSWER.
RTC accuracy supports optionalizing the 11 minute update.
Other reasons to optionalize the 11 minute update which various people
suggest:
1. The kernel should not dictate OS policy;
2. Simplifies programming with /dev/rtc;
3. Improves performance of /dev/rtc;
4. Slightly reduced kernel size;
5. Slightly faster timer_interrupt;
6. Easier to use utilities like hwclock.
I agree with you, Pavel. Commenting out the 11 minute update
code is a better solution. :)
> Pavel
> --
> Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
> details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
>
--
Regards,
Ian Maclaine-cross ([email protected])
Hi!
> > That seems as very wrong solution.
>
> > What about just making kernel only _read_ system clock, and never
> > set it? That looks way cleaner to me.
>
> It is cleaner. However, I feel that the RTC code should printk (at least
> as KERN_DEBUG if not as KERN_NOTICE) whenever the RTC is written to.
> It's too important a subsystem to be left hidden like it currently is.
This can be as well done in userland, enforced by whoever does rtc
writes, no?
[I poropose kernel not to do any writes, so it is only userland
left. And having printk() in kernel or syslog() in hwclock seems
pretty much equivalent, with later prefered as it magically works on
older kernels.]
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi!
> I agree with you, Pavel. Commenting out the 11 minute update
> code is a better solution. :)
Are you going to try to push patch trhough linus?
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi Pavel.
>>> That seems as very wrong solution.
>>>
>>> What about just making kernel only _read_ system clock, and
>>> never set it? That looks way cleaner to me.
>> It is cleaner. However, I feel that the RTC code should printk (at
>> least as KERN_DEBUG if not as KERN_NOTICE) whenever the RTC is
>> written to. It's too important a subsystem to be left hidden like
>> it currently is.
> This can be as well done in userland, enforced by whoever does rtc
> writes, no?
If some idiot writes a hwclock replacement that doesn't do logging, and
sets the rtc to the output from /dev/random, how does the kernel enforce
that it must log this to /var/log/messages other than by doing the
printk() itself?
> I propose kernel not to do any writes, so it is only userland left.
> And having printk() in kernel or syslog() in hwclock seems pretty
> much equivalent, with later prefered as it magically works on older
> kernels.
I think we're talking at cross-purposes here, so here's my proposal,
which I feel is the only one that actually makes sense:
1. The /dev/rtc driver in the kernel is the ONLY code that can
actually read or write to the RTC registers.
Alternatively, this could be replaced with a sysctl() if that
is preferred. The important thing is that there is only ONE way
of performing this write.
2. The kernel makes no internal reference to the /dev/rtc driver,
and it is left to userland tools to sync to the RTC on boot,
and at other times as required.
3. Whenever the /dev/rtc driver writes to ANY of the RTC registers
(whether to set the time, the alarm, or anything else), it logs
this fact using printk at level KERN_DEBUG. The SYSLOG utility
can be configured to ignore KERN_DEBUG messages, or to deal with
them in any other way desired.
If I've demangling your comments correctly, then you've basically said
the same as I've said above. If not, can you please advise how you feel
this proposal should be altered.
Best wishes from Riley.
Hi!
> >> The offset needs to be sufficient to handle the case of the RTC
> >> being set to local time and the boot and first ntp sync occurring on
> >> opposite sides of a Daylight Savings Time change. A couple of
> >> timezones use a DST offset of 90 minutes, so if it's less than that,
> >> there will be problems.
>
> > There is a related problem, where if you are running something which
> > can suspend, like a laptop, but not using integrated apm to do it
> > (for instance a laptop which has a broken BIOS), then suspending
> > 'freezes' the system time, which is wrong on resume (as the power
> > management event appears to be invisible to Linux). Then this goes
> > and blats over the (correct) RTC time. If you then get a network
> > connection up, ntp won't adjust the time as it's too far out.
>
> That sounds like a configuration error to me, and here's why.
>
> 1. One of the available reference clocks for xntpd is the local
> RTC, type 1 in the list of reference clock types, and that
> should ALWAYS be listed as one of the reference clocks to use,
> but with a higher stratum than any other reference clock used.
>
> 2. My experience with the xntpd driver suggests that if no better
> reference is available and the RTC is one of the listed clocks,
> then it ALWAYS adjusts the time to match the RTC, irrespective
> of the time difference between them.
This sounds racy. What if kernel is faster and destroys RTC just after
resume and before xntpd ca run?
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
> >> 3. AFAICT, if xntpd writes to the RTC, then it has achieved true
> >> synchronisation to a reference clock other than the RTC.
>
> > I thought the original poster was claiming that the /kernel/
> > wrote to the RTC, which would explain the behaviour I'm seeing.
>
> The kernel itself never writes to the RTC, and that is one of Linus's
> decisions with which I am in 100% agreeance (and one thing I hate about
> Windows). In fact, the kernel itself also doesn't read from the RTC
> either, but leaves that to userspace.
Wrong two times.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Wed, Nov 07, 2001 at 02:01:37AM +0100, Kurt Roeckx wrote:
> On Wed, Nov 07, 2001 at 12:44:21AM -0000, Alex Bligh - linux-kernel wrote:
> > --On Wednesday, 07 November, 2001 12:00 AM +0000 Riley Williams
> > <[email protected]> wrote:
> >
> > > 2. The kernel makes no internal reference to the /dev/rtc driver,
> > > and it is left to userland tools to sync to the RTC on boot,
> > > and at other times as required.
> >
> > I think the kernel should set the machine time to the RTC time
> > as an initializer on boot. Other than that, I agree.
>
> Which is something you do from userspace.
One problem with that approach is the things in kernel that need to be
initialised to a random value, such that on two consecutive boots, the
values are different. Currently, that's NFS XIDs. As Linux currently
stands, running on some embedded machines where there is no real time
clock, you can hit the possibility of file corruption if you happen to
reboot the machine twice in within two minutes - non-Linux NFS servers
could well be longer.
With your proposed change, you'd be inflicting that pain on all NFS root
machines, even ones with RTCs, so may I suggest that if you're thinking
about removing the RTC stuff that you also think of a way of solving this
problem at the same time?
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Hi!
On Tue, Nov 06, 2001 at 11:18:46AM +0100, Pavel Machek wrote:
[snip]
> > I agree with you, Pavel. Commenting out the 11 minute update
> > code is a better solution. :)
>
> Are you going to try to push patch trhough linus?
Yes, I will prepare a patch for the 2.5 series. Thanks to all for
their contributions.
Please find following a short, crude and preliminary, 2.4.12 i386
patch which I am now testing on my AMD K6-III machine. Reasons for
commenting out the 11 minute update code are in my previous
linux-kernel email. My patched compressed kernel is 156 bytes smaller.
It has been running normally with clock synchronized to NTP for two
days and has left the RTC to drift freely.
diff -u --recursive linux.old/arch/i386/kernel/time.c linux/arch/i386/kernel/time.c
--- linux.old/arch/i386/kernel/time.c Tue Sep 18 16:03:09 2001
+++ linux/arch/i386/kernel/time.c Tue Nov 6 21:03:46 2001
@@ -313,6 +313,8 @@
write_unlock_irq(&xtime_lock);
}
+#ifdef UPDATE_RTC
+
/*
* 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
@@ -384,6 +386,8 @@
/* last time the cmos clock got updated */
static long last_rtc_update;
+#endif
+
int timer_ack;
/*
@@ -426,6 +430,8 @@
smp_local_timer_interrupt(regs);
#endif
+#ifdef UPDATE_RTC
+
/*
* If we have an externally synchronized Linux clock, then update
* CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
@@ -440,6 +446,7 @@
else
last_rtc_update = xtime.tv_sec - 600; /* do it again in 60 s */
}
+#endif
#ifdef CONFIG_MCA
if( MCA_bus ) {
--
Regards,
Ian Maclaine-cross ([email protected])
Hi!
> >> least as KERN_DEBUG if not as KERN_NOTICE) whenever the RTC is
> >> written to. It's too important a subsystem to be left hidden like
> >> it currently is.
>
> > This can be as well done in userland, enforced by whoever does rtc
> > writes, no?
>
> If some idiot writes a hwclock replacement that doesn't do logging, and
Then it is *his* problem. That's not excuse for putting it into kernel.
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi Pavel.
>>>> least as KERN_DEBUG if not as KERN_NOTICE) whenever the RTC is
>>>> written to. It's too important a subsystem to be left hidden like
>>>> it currently is.
>>> This can be as well done in userland, enforced by whoever does rtc
>>> writes, no?
>> If some idiot writes a hwclock replacement that doesn't do logging...
> Then it is *his* problem. That's no excuse for putting it into kernel.
So you believe viruses are a good thing to have? Sorry, I have to
disagree with you.
Take the position of a sysadmin who can't understand why the system
clock on his computer keeps getting randomly changed under Linux, and
has verified using another operating system that it isn't a hardware
problem, then ask yourself what said sysadmin would expect from the
kernel to help him/her track the problem down. Would said sysadmin
prefer to be told...
1. "Look in the system log - you'll get a message every time any
program writes to the RTC."
2. "Sorry, you'll have to go through every piece of software on
your system and find the one that's updating the system clock
that shouldn't be."
According to your comments, you prefer (2). I most definitely prefer (1).
Best wishes from Riley.
Hi!
> >>>> least as KERN_DEBUG if not as KERN_NOTICE) whenever the RTC is
> >>>> written to. It's too important a subsystem to be left hidden like
> >>>> it currently is.
>
> >>> This can be as well done in userland, enforced by whoever does rtc
> >>> writes, no?
>
> >> If some idiot writes a hwclock replacement that doesn't do logging...
>
> > Then it is *his* problem. That's no excuse for putting it into kernel.
>
> So you believe viruses are a good thing to have? Sorry, I have to
> disagree with you.
> Take the position of a sysadmin who can't understand why the system
> clock on his computer keeps getting randomly changed under Linux, and
> has verified using another operating system that it isn't a hardware
> problem, then ask yourself what said sysadmin would expect from the
> kernel to help him/her track the problem down. Would said sysadmin
> prefer to be told...
>
> 1. "Look in the system log - you'll get a message every time any
> program writes to the RTC."
>
> 2. "Sorry, you'll have to go through every piece of software on
> your system and find the one that's updating the system clock
> that shouldn't be."
>
> According to your comments, you prefer (2). I most definitely prefer
> (1).
Hmm, and if some malicious software insmods kernel module to work
around your printk()?
We are talking root only here. If sofware with uid 0 is malicious, you
have big problems.
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi Pavel.
>> Take the position of a sysadmin who can't understand why the system
>> clock on his computer keeps getting randomly changed under Linux,
>> and has verified using another operating system that it isn't a
>> hardware problem, then ask yourself what said sysadmin would expect
>> from the kernel to help him/her track the problem down. Would said
>> sysadmin prefer to be told...
>>
>> 1. "Look in the system log - you'll get a message every time any
>> program writes to the RTC."
>>
>> 2. "Sorry, you'll have to go through every piece of software on
>> your system and find the one that's updating the system clock
>> that shouldn't be."
>>
>> According to your comments, you prefer (2).
>>
>> I most definitely prefer (1).
> Hmm, and if some malicious software insmods kernel module to work
> around your printk()?
...it gets "Port busy" when it tries to access the RTC ports that the
RTC driver built into the kernel already has opened exclusively. At
least, that's my understanding of the situation at present.
> We are talking root only here.
Are we?
Unless I've misunderstood the arguments so far, the aim is to take the
RTC driver out of the kernel altogether and replace it with a usermode
driver to do the same thing. As I see it, that opens up far too many
problems to be seriously considered, not least the fact that setting
the RTC is not necessarily a root-only operation.
> If sofware with uid 0 is malicious, you have big problems.
True, but that's not what people appear to be talking about.
Best wishes from Riley.
Hi!
> >> According to your comments, you prefer (2).
> >>
> >> I most definitely prefer (1).
>
> > Hmm, and if some malicious software insmods kernel module to work
> > around your printk()?
>
> ...it gets "Port busy" when it tries to access the RTC ports that the
> RTC driver built into the kernel already has opened exclusively. At
> least, that's my understanding of the situation at present.
It does not work that way. Userland does iopl(0), and then it just
bangs any port it wants to.
> > We are talking root only here.
>
> Are we?
>
> Unless I've misunderstood the arguments so far, the aim is to take the
> RTC driver out of the kernel altogether and replace it with a usermode
> driver to do the same thing. As I see it, that opens up far too many
No. Aim is to leave /dev/rtc in kernel, but make kernel never write to
RTC at its own will.
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi Pavel.
>>>> According to your comments, you prefer (2).
>>>> I most definitely prefer (1).
>>> Hmm, and if some malicious software insmods kernel module to
>>> work around your printk()?
>> ...it gets "Port busy" when it tries to access the RTC ports that the
>> RTC driver built into the kernel already has opened exclusively. At
>> least, that's my understanding of the situation at present.
> It does not work that way. Userland does iopl(0), and then it just
> bangs any port it wants to.
If any user can do that, then Linux is borken solid.
Just out of curiosity, what is wrong with the idea of having the kernel
at iopl(0), any kernel modules at either iopl(1) or iopl(2) and apps at
iopl(3) ??? There is obviously something, but I've no idea what.
>>> We are talking root only here.
>> Are we?
>>
>> Unless I've misunderstood the arguments so far, the aim is to take
>> the RTC driver out of the kernel altogether and replace it with a
>> usermode driver to do the same thing. As I see it, that opens up far
>> too many
> No. Aim is to leave /dev/rtc in kernel, but make kernel never write
> to RTC at its own will.
I've no problem with that at all, but the bulk of the comments I've seen
in this thread have been very clear about taking /dev/rtc out of the
kernel and into a userspace daemon, with the kernel just providing
access to the relevant ports to the first app to claim them.
Best wishes from Riley.
On Fri, Nov 09, 2001 at 10:54:10PM +0000, Riley Williams wrote:
> Hi Pavel.
>
> >>>> According to your comments, you prefer (2).
> >>>> I most definitely prefer (1).
>
> >>> Hmm, and if some malicious software insmods kernel module to
> >>> work around your printk()?
>
> >> ...it gets "Port busy" when it tries to access the RTC ports that the
> >> RTC driver built into the kernel already has opened exclusively. At
> >> least, that's my understanding of the situation at present.
>
> > It does not work that way. Userland does iopl(0), and then it just
> > bangs any port it wants to.
>
> If any user can do that, then Linux is borken solid.
>
> Just out of curiosity, what is wrong with the idea of having the kernel
> at iopl(0), any kernel modules at either iopl(1) or iopl(2) and apps at
> iopl(3) ??? There is obviously something, but I've no idea what.
Kernel stuff (kernel, modules) run at iopl(0). Only root programs can request
iopl(0) for itself, otherwise all hell would break loose (eg, user 'nobody'
writing to the hdd etc...)
--
Mark Zealey
[email protected]
[email protected]
UL++++>$ G!>(GCM/GCS/GS/GM) dpu? s:-@ a16! C++++>$ P++++>+++++$ L+++>+++++$
!E---? W+++>$ N- !o? !w--- O? !M? !V? !PS !PE--@ PGP+? r++ !t---?@ !X---?
!R- b+ !tv b+ DI+ D+? G+++ e>+++++ !h++* r!-- y--
(http://www.geekcode.com)
Hi!
> >> ...it gets "Port busy" when it tries to access the RTC ports that the
> >> RTC driver built into the kernel already has opened exclusively. At
> >> least, that's my understanding of the situation at present.
>
> > It does not work that way. Userland does iopl(0), and then it just
~~~~~~~
sorry, this was meant
to be iopl(3).
> > bangs any port it wants to.
>
> If any user can do that, then Linux is borken solid.
Only root can do that.
> Just out of curiosity, what is wrong with the idea of having the kernel
> at iopl(0), any kernel modules at either iopl(1) or iopl(2) and apps at
> iopl(3) ??? There is obviously something, but I've no idea what.
It ... just is not that way. Kernel + modules run at ring 0, userland
at ring 3.
> >>> We are talking root only here.
>
> >> Are we?
> >>
> >> Unless I've misunderstood the arguments so far, the aim is to take
> >> the RTC driver out of the kernel altogether and replace it with a
> >> usermode driver to do the same thing. As I see it, that opens up far
> >> too many
>
> > No. Aim is to leave /dev/rtc in kernel, but make kernel never write
> > to RTC at its own will.
>
> I've no problem with that at all, but the bulk of the comments I've seen
> in this thread have been very clear about taking /dev/rtc out of the
> kernel and into a userspace daemon, with the kernel just providing
> access to the relevant ports to the first app to claim them.
I do not think so.
The person who tries to kill /dev/rtc from kernel is going to have
some problems with me.
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi Pavel.
>> If any user can do that, then Linux is borken solid.
> Only root can do that.
Good.
>> Just out of curiosity, what is wrong with the idea of having the
>> kernel at iopl(0), any kernel modules at either iopl(1) or iopl(2)
>> and apps at iopl(3) ??? There is obviously something, but I've no
>> idea what.
> It ... just is not that way. Kernel + modules run at ring 0,
> userland at ring 3.
I know that much. I was just curious whether there was any particular
reason why it was that way.
Somebody suggested that it was because of "scheduling hooplas" causing a
serious loss of performance if modules were moved to ring 1. I've no
idea whether such is the case
>>> No. Aim is to leave /dev/rtc in kernel, but make kernel never write
>>> to RTC at its own will.
>> I've no problem with that at all, but the bulk of the comments I've
>> seen in this thread have been very clear about taking /dev/rtc out
>> of the kernel and into a userspace daemon, with the kernel just
>> providing access to the relevant ports to the first app to claim
>> them.
> I do not think so.
>
> The person who tries to kill /dev/rtc from kernel is going to have
> some problems with me.
They've been getting problems from me - I just checked, and the main
suggestion appears to be to replace /dev/rtc with a sysctl call. I can't
see the point in that myself, and /dev/rtc makes far more sense to me.
I will add that I personally see no problem with the kernel reading RTC
on boot to set the syste clock, although some of the correspondents
appear to have problems with that idea as well.
Best wishes from Riley.
Hi!
> >> Just out of curiosity, what is wrong with the idea of having the
> >> kernel at iopl(0), any kernel modules at either iopl(1) or iopl(2)
> >> and apps at iopl(3) ??? There is obviously something, but I've no
> >> idea what.
>
> > It ... just is not that way. Kernel + modules run at ring 0,
> > userland at ring 3.
>
> I know that much. I was just curious whether there was any particular
> reason why it was that way.
>
> Somebody suggested that it was because of "scheduling hooplas" causing a
> serious loss of performance if modules were moved to ring 1. I've no
> idea whether such is the case
Yep, it would be slower that way, and it would be nightmare to implement.
> >>> No. Aim is to leave /dev/rtc in kernel, but make kernel never write
> >>> to RTC at its own will.
>
> >> I've no problem with that at all, but the bulk of the comments I've
> >> seen in this thread have been very clear about taking /dev/rtc out
> >> of the kernel and into a userspace daemon, with the kernel just
> >> providing access to the relevant ports to the first app to claim
> >> them.
>
> > I do not think so.
> >
> > The person who tries to kill /dev/rtc from kernel is going to have
> > some problems with me.
>
> They've been getting problems from me - I just checked, and the main
> suggestion appears to be to replace /dev/rtc with a sysctl call. I can't
> see the point in that myself, and /dev/rtc makes far more sense to me.
>
> I will add that I personally see no problem with the kernel reading RTC
> on boot to set the syste clock, although some of the correspondents
> appear to have problems with that idea as well.
So we agree with each other. Good.
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Riley Williams <[email protected]> writes:
> Hi Pavel.
>
> > It ... just is not that way. Kernel + modules run at ring 0,
> > userland at ring 3.
>
> I know that much. I was just curious whether there was any particular
> reason why it was that way.
Well, Unix has historically run on systems with at most two processor
privilege levels, "user" and "supervisor"; ie, you're either in user
or kernel mode.
ix86 is one of the few Linux platforms that offers more than two
levels, so having modules run in an in-between level would be a
portability headache as well as a lot of work.
Certainly not impossible, but you'd need to create task gates or
whatever they're called at every point where modules called into the
kernel (and vice versa as well I think). Might be a serious
performance hit...
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
--On Wednesday, 07 November, 2001 12:00 AM +0000 Riley Williams
<[email protected]> wrote:
> 2. The kernel makes no internal reference to the /dev/rtc driver,
> and it is left to userland tools to sync to the RTC on boot,
> and at other times as required.
I think the kernel should set the machine time to the RTC time
as an initializer on boot. Other than that, I agree.
--
Alex Bligh
On Wed, Nov 07, 2001 at 12:44:21AM -0000, Alex Bligh - linux-kernel wrote:
>
>
> --On Wednesday, 07 November, 2001 12:00 AM +0000 Riley Williams
> <[email protected]> wrote:
>
> > 2. The kernel makes no internal reference to the /dev/rtc driver,
> > and it is left to userland tools to sync to the RTC on boot,
> > and at other times as required.
>
> I think the kernel should set the machine time to the RTC time
> as an initializer on boot. Other than that, I agree.
Which is something you do from userspace.
Kurt
>> > 2. The kernel makes no internal reference to the /dev/rtc driver,
>> > and it is left to userland tools to sync to the RTC on boot,
>> > and at other times as required.
>>
>> I think the kernel should set the machine time to the RTC time
>> as an initializer on boot. Other than that, I agree.
>
> Which is something you do from userspace.
You have to initialize (once, on boot) this to
something. I don't really see the point of initializing
it to zero and putting the atime/mtime on a few entries
back to 1970, when we have the value there already.
We /know/ we have to use the RTC values for things
like apm suspend, for instance - I don't want my 'make'
to be broken through races with userspace time functions -
so if we are prepared to read RTC on resume, we should be
prepared to read RTC on boot.
--
Alex Bligh