Messages in this thread | | | Date | Tue, 6 Nov 2001 09:57:33 +0000 | From | Pavel Machek <> | Subject | Re: PROBLEM: Linux updates RTC secretly when clock synchronizes |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |