> Hi Ulrich.
>
> >>> 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.
The "system clock" is a collection of variables in the kernel,
maintained by the kernel. I hope you agree. As The BIOS starts before
Linux is in RAM, the BIOS can't set the time for Linux. I hope you
also agree.
>
> Granted, the ROM BIOS has no idea of timezones, but there's
> precious little we can do about that.
<soapbox>
Well, Microsoft does not know about timezones, so why should a BIOS
care to allow setting one? WE can do little about that, but i wonder
why you can read the serial number of your CPU via DMI, and you can
read the temperature of your mainboard, but you can't read the
timezone.
Maybe the BIOS developers are captured in a darf cellar and they
don't ever meet reality.
</soapbox>
>
> 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.
In cae you want to look at it: LINUX reads the time from the hardware
(=RTC) during boot. That's why the time is set.
>
> 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.
Agreed.
>
> 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.
Agreed.
>
> 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...
Agreed.
>
> > 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.
DST makes things harder: How can you know (after powering the system
up) whether the RTC is already time-corrected or not?
>
> 1. If the RTC stores time in UTC, the correct command is:
>
> hwclock --utc --hctosys
BTW: Why is the utility named "hwclock" and the option "--hctosys"? I
always wished for "--hwtosys", or maybe call the program "hclock".
>
> 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.
A problem.
>
> >>> 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...
I think you convinced me to do nothing about the issue. So let just
the sun shine on my nose.
Regards,
Ulrich
-
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/