Hi! I have dual-boot machine with 7.0-BETA1 and Windows that keeps CMOS time local (there is /etc/wall_cmos_clock also). It was tuned off yesterday evening and turned back on today, loading FreeBSD. Meantime the switch from Summer Time to Standard Time has ocurred. There is 'ntpd_enable="YES"' in /etc/rc.conf. Nothing in a system reacted on the end of Summer Time period, so ntpd just complained about 3600 seconds exceeded sanity limit and bailed out (documented behavour). There is Status Register B at the offset 0x0b in the ISA Compatible CMOS, its least significant bit should keep Daylight Saving flag (on/off). Is it used in modern hardware? Does FreeBSD use it? It is supposed to use it? Eugene Grosbein
On Sun, Oct 28, 2007 at 09:35:08PM +1100, Peter Jeremy wrote:> Based on a quick check, it doesn't look like adjkerntz(8) can handle > your situation. In the absence of any independent time source, it's > actually very difficult to handle this situation. In theory, it would > be possible to note that the last system shutdown (or last time the > RTC was set) and determine whether there's been a DST transition in > the period between then and now and adjust the RTC appropriately (I > believe Windows does this). The problem is that, unless this record > is kept within the RTC and all OSs co-operate in its meaning, each > OS will independently adjust the RTC when it is next rebooted (and > I believe multi-boot PCs run into this problem).It would be possible to utilize a bit in the CMOS at boot time to decide if BIOS time set to Summer time and clear it appropriately, in theory :-) Eugene
On Sun, Oct 28, 2007 at 03:39:55PM +0700, Eugene Grosbein wrote:>It was tuned off yesterday evening and turned back on today, >loading FreeBSD. Meantime the switch from Summer Time to Standard Time >has ocurred.And we've just switched to Summer time. Based on a quick check, it doesn't look like adjkerntz(8) can handle your situation. In the absence of any independent time source, it's actually very difficult to handle this situation. In theory, it would be possible to note that the last system shutdown (or last time the RTC was set) and determine whether there's been a DST transition in the period between then and now and adjust the RTC appropriately (I believe Windows does this). The problem is that, unless this record is kept within the RTC and all OSs co-operate in its meaning, each OS will independently adjust the RTC when it is next rebooted (and I believe multi-boot PCs run into this problem). Overall, the only sane approach is to keep the RTC in UTC and compensate for DST in each OS. Unfortunately, this isn't possible due to historical decisions made by Microsoft.> There is 'ntpd_enable="YES"' in /etc/rc.conf. >Nothing in a system reacted on the end of Summer Time period, >so ntpd just complained about 3600 seconds exceeded sanity limit >and bailed out (documented behavour).If you enable ntpdate, that should work around the problem because ntpdate doesn't have the 1000 second sanity limit.>There is Status Register B at the offset 0x0b in the ISA Compatible CMOS, >its least significant bit should keep Daylight Saving flag (on/off). >Is it used in modern hardware? Does FreeBSD use it? It is supposed to use it?FreeBSD doesn't use it - Status Register B is updated in a couple of spots in /sys/i386/isa/clock.c to only have the 24hr bit set. I'm not sure what modern Windows expects but the DST rules embedded in the MC146818 are now accurate for only a fairly small part of the world. -- Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20071028/dec4ce51/attachment.pgp
On Sun, 28 Oct 2007, Eugene Grosbein wrote: > I have dual-boot machine with 7.0-BETA1 and Windows > that keeps CMOS time local (there is /etc/wall_cmos_clock also). > > It was tuned off yesterday evening and turned back on today, > loading FreeBSD. Meantime the switch from Summer Time to Standard Time > has ocurred. There is 'ntpd_enable="YES"' in /etc/rc.conf. > Nothing in a system reacted on the end of Summer Time period, > so ntpd just complained about 3600 seconds exceeded sanity limit > and bailed out (documented behavour). With standard /etc/crontab, adjkerntz -a (which catches DST changes) is only run between midnight and 5am, and presumably your 'today' started after then. Perhaps running that once on boot, just in case, might help in such circumstances? I've done that without ntpd running, but ntpd -qg once on booting should handle such surprise 3600s shifts better? > There is Status Register B at the offset 0x0b in the ISA Compatible > CMOS its least significant bit should keep Daylight Saving flag > (on/off). The bit appears to be DST enable, rather than storage of current state? Windows date setting has a check box that I suspect reflects this bit. You may find that windows will shift CMOS another hour when next booted too, or at least that's what I recall W98 doing to me a couple of times when I happened to boot it some time during some 6 month period :) > Is it used in modern hardware? Does FreeBSD use it? It is supposed to > use it? /sys/isa/rtc.h has #define RTCSB_DST 0x01 /* USA Daylight Savings Time enable */ but it's not referenced in /sys/i386/isa/clock.c (great bedtime reading) which is the only place that updates the RTC, AFAIK. If I'm reading it right, FreeBSD clears this bit during clock initialisation. (5.5-STABLE here; I haven't checked if this code has changed since) Cheers, Ian
On Sun, 28 Oct 2007, Eugene Grosbein wrote:> It was tuned off yesterday evening and turned back on today, > loading FreeBSD. Meantime the switch from Summer Time to Standard Time > has ocurred. There is 'ntpd_enable="YES"' in /etc/rc.conf. > Nothing in a system reacted on the end of Summer Time period, > so ntpd just complained about 3600 seconds exceeded sanity limit > and bailed out (documented behavour).Right. You're looking at this as a DST problem, when in reality it's just a "clock is too far off for ntpd to sync normally" problem. You want to have a more general solution for that problem in any case. Adding ntpd_sync_on_start to /etc/rc.conf is one way to accomplish that, there are others of course. Doug -- This .signature sanitized for your protection