Messages in this thread | | | Date | Thu, 20 May 1999 01:18:23 +0100 (GMT) | From | Riley Williams <> | Subject | Re: i386/RTC: old problem, new solution? |
| |
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.
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/
| |