lkml.org 
[lkml]   [1999]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: i386/RTC: old problem, new solution?
Hi Ulrich.

===8<=== CUT ===>8===

>> 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.

My understanding was that Linux reads the ROM BIOS clock and
initialises its system clock from that, in which case the BIOS
effectively initialises Linux's system clock.

>> 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>

LOL!!! That wouldnae surprise me though...

>> 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 case you want to look at it: LINUX reads the time from the
> hardware (=RTC) during boot. That's why the time is set.

Are you sure about this? I understood that it used the relevant ROM
BIOS call to read the BIOS clock before switching to protected mode,
and just used the value returned from that.

>> 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?

There are basically three cases here:

1. The RTC chip has a register that says whether DST is in use,
and that register is correctly set and reliable.

2. The RTC chip has a register that says whether DST is in use,
but that register is not reliably set.

3. The RTC chip does not have a register that says whether DST
is in use.

I believe Win9x assumes case (1), as it throws up a warning screen if
it has shifted the RTC in to or out of DST.

>> 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.

> BTW: Why is the utility named "hwclock" and the option named
> "--hctosys"? I always wished for "--hwtosys", or maybe call the
> program "hclock".

I believe `hwclock` stands for "hardware clock" and `--hctosys` stands
for "Hardware Clock TO SYStem clock"...

>>>>> 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.

Unfortunately, I think that's what kills the idea of doing this at
kernel level...

> I think you convinced me to do nothing about the issue. So let
> just the sun shine on my nose.

Resulting from yours and other emails in this thread, I've had a few
ideas that may result in a patch relating to this. Watch this space.

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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.059 / U:37.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site