>>> maybe the problem running RTC in non-UTC time is known to you,
>>> including its implications. Basically the kernel lacks two
>>> things when booting:
>>> 1) time zone
>>> 2) Whether RTC runs UTC or local time
>> Certainly on my setup, the kernel never even attempts to read
>> the RTC itself and that's left to a userspace program (hwclock)
>> that gets run from the boot scripts with the relevant
>> parameters. The said program also makes use of a SymLink that
>> tells it what the local timezone is, so has all the information
>> needed to RE-initialise the system clock to match what the
>> hardware clock claims is the case.
> The user space utility concept has a problem: What will be the
> kernel boot time, and what is the time when the filesystems are
> mounted or checked?
That's not quite what I understood your original email to be referring
to. Let's go for gold here and look at the boot procedure:
1. Reset button is pressed, and the ROM BIOS gets control.
2. Amongst the tasks taken by ALL of the ROM BIOS's that I've
come across is to set the system's idea of the time from
the RTC if an RTC is found. Therefore, the system clock is
set BEFORE the kernel even gets a look in.
Granted, the ROM BIOS has no idea of timezones, but there's
precious little we can do about that.
3. When the ROM BIOS has finished whatever else it has been
told to do, it looks at the various drives, and ends up
loading the kernel image into memory via whatever procedure
the user has selected. It then executes the image so loaded
into memory.
It is at THIS stage in the proceedings that we first get an
opportunity to do something, and we already noted that the
RTC has previously been read and assigned to the system time.
4. If the RTC stores the time in UTC, or the local time happens
to coincide with UTC, then the kernel has nothing further to
do, since it always stores the system time in UTC anyway. In
that case, finish here.
5. If the RTC stores local time and that local time differs from
UTC, the kernel needs to tweak the system clock to reflect
this difference as it keeps the system time in UTC internally.
So, if there is a problem, then it only strikes when the RTC stores
local time and that differs from UTC, in which case the kernel will
appear to suffer a timewarp at the point in the boot procedure where
the userspace tool sets the system clock to match the RTC when
corrected for the relevant timezone...
> Also a use space utility may cause a time warp on every boot.
Let's analyse this:
Case 1: The RTC stores the time in UTC.
No timewarp can occur since this is what the kernel
assumes prior to running any userspace tools.
Case 2: The RTC stores local time, but that happens to coincide
with UTC. An example is the UK in winter time (GMT).
Again, no timewarp can occur since, whilst this isn't
what the kernel assumes, the fact that the time offset
is zero prevents any problems.
Case 3: The RTC stores local time, which differs from UTC.
Examples are the UK in summer time (BST), and most
other countries at any time of the year.
In this case, the system will start up assuming that the
local time stored in the RTC is UTC, and will continue
in that state until the point at which the command that
corrects that is run.
So only case 3 can cause a problem, and even then, it doesn't affect
the RTC unless the wrong command is given.
1. If the RTC stores time in UTC, the correct command is:
hwclock --utc --hctosys
2. If the RTC stores time in local time, the correct command is:
hwclock --hctosys
Note that in the second case, the omission of the --utc option implies
that the RTC stores the time in local time.
>>> My solution would be:
>>> 1) Add a kernel parameter like RTC=UTC|local
>>> 2) Add a kernel parameter like TZ=+0200 (numeric notation
>>> used in EMail)
>> Both are already part of the hwclock program.
In the context you've set this, note that in many countries, the
timezone CHANGES between summer and winter time, something which a
userspace program can easily deal with (and hwclock deals with it
nicely), but which is nigh on impossible to deal with otherwise.
>>> 3) Enhance routines that set the system time to update the
>>> RTC as well
>> Your wording is ambiguous, so I'll deal with both possible meanings:
>> a. There are various programs available to synchronise the system
>> clock with some external time standard. I use rdate as part of
>> my dial up script, and a friend of mine uses a program that
>> synchronises his system clock with that broadcast on teletext.
> I mean: settimeofday() and related functions should also set the
> RTC immediately. That's what the average user expects the
> program to do. Confusion arises if not.
>> b. The hwclock program also has the ability to set the RTC from
>> the system clock.
> Maybe let's name a popular example: When installing SuSE Linux,
> there's no way to set the system time (other than escaping to a
> shell and calling "date -s"), and the timezone is zero during
> installation. The RTC is asumed to be UTC. After installation,
> the system time warps. (You can see it when checking the
> installation times with "rpm -qi"). If things were just fine, we
> would not have such problems.
There's two possible problems your comments could be referring to, as
follows:
A. The times recorded during Linux installation. This is NOT a
kernel problem, and can be solved simply by having the relevant
distribution ask for the current timezone early on, and set the
local timezone from that, then use the same information to set
the on-disk timezone information at the end of installation.
B. The fact that syslog messages produced before hwclock runs get
labelled with the wrong time if the RTC stores details in local
time. This could easily be a kernel problem.
Note that one possible solution to item (B) above would be to have
whatever syscall gets used to set the system time tweak the timestamps
of all messages still waiting to be offloaded, and don't start up
syslogd and klogd until after the time gets initially set.
>> The combination of those two means that it is already possible
>> to both synchronise the RTC with an external time standard and
>> to ensure that the kernel is itself so synchronised.
> I think I know what you are talking about ;-)
This wasn't quite what you were referring to originally though...
>>> I some people can convince me that it's a good idea, I might
>>> develop a patch...
>> Unfortunately, it's already been dealt with in userspace, so any
>> kernel patch you developed would be unlikely to be applied anyway.
> Aha.
However, a patch to deal with the problem mentioned in item (B) above
might just stand a chance of getting into the kernel, although as
that's not my decision, I can't guarantee it...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/