Re: CMOS, daylight saving time and dual-boot
On Mon, 29 Oct 2007, Eugene Grosbein wrote: Suppose, the machine does not have global connectivity at all (and it has no local source of exact time) or just at the boot time. It still needs to adjust local time, right? Your post posited a problem with ntpd not being able to synch the time because it was an hour off. The fact that the DST problem caused the ntp problem isn't really relevant. It seems to me as DST problem really, not NTP problem. I don't think I properly stated my actual point, which is that the issue you're describing is an edge case, and we have about 1k more important things that need developer time. If you choose to spend some of your time fixing this problem I'm sure we'd all be interested in your results. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CMOS, daylight saving time and dual-boot
Doug Barton wrote: Suppose, the machine does not have global connectivity at all (and it has no local source of exact time) or just at the boot time. It still needs to adjust local time, right? Your post posited a problem with ntpd not being able to synch the time because it was an hour off. The fact that the DST problem caused the ntp problem isn't really relevant. It seems to me as DST problem really, not NTP problem. I don't think I properly stated my actual point, which is that the issue you're describing is an edge case, and we have about 1k more important things that need developer time. If you choose to spend some of your time fixing this problem I'm sure we'd all be interested in your results. I did some investigations about the issue. It seems there are two things to be done to fix this: 1) Choose a place to keep DST flag that was actual at the moment of last shutdown. It may be CMOS bit or on-disk file. On-disk file is less suitable for diskless stations but they can't run Windows anyway and should keep its CMOS times in UTC. OTOH, CMOS flag may be shared between several OS'es. 2) Teach 'adjkerntz -i' to respect the flag whenever it resides and adjust machdep.adjkerntz as needed. Both tasks are pretty simple and require just an accurate implementation. I'll try to find time for this. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CMOS, daylight saving time and dual-boot
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CMOS, daylight saving time and dual-boot
On Sun, Oct 28, 2007 at 06:08:26PM +0700, Eugene Grosbein wrote: 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 :-) As long as every OS that you are going to run agrees on the bit and its meaning -- Peter pgpksQObtZJ0o.pgp Description: PGP signature
Re: CMOS, daylight saving time and dual-boot
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 pgpsuNB1LD4Xr.pgp Description: PGP signature
Re: CMOS, daylight saving time and dual-boot
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CMOS, daylight saving time and dual-boot
On Mon, Oct 29, 2007 at 02:17:44AM +1100, Ian Smith 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. Yes, really much later :-) Perhaps running that once on boot, just in case, might help in such circumstances? I'll test this. By the way, I cannot set local date to '02:59:00 summer time', it sets '02:59:00 winter time' :-( E.g., date 200710280222.39 sets time in KRAST timezone (local time is GMT+8 in summer) and date 200710280222.40 sets it so timezone changes to KRAT. How could I set it to 200710280259 KRAST? 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. I don't think so, it seems that Windows keeps it's own flag to know if it should adjust local time for daylight savings. As you noted, FreeBSD always clears CMOS bit and that has no affect on Windows behavour. 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) The same in CURRENT. It seems we could use this bit as storage flag :-) I think about diskless stations that has no other storage for this. Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CMOS, daylight saving time and dual-boot
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CMOS, daylight saving time and dual-boot
If you're in the US, you're a week early for the changeover -- your timezone files need to be corrected. See: http://articles.techrepublic.com.com/5100-10877_11-6163042.html Eugene Grosbein wrote: On Mon, Oct 29, 2007 at 02:17:44AM +1100, Ian Smith 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. Yes, really much later :-) Perhaps running that once on boot, just in case, might help in such circumstances? I'll test this. By the way, I cannot set local date to '02:59:00 summer time', it sets '02:59:00 winter time' :-( E.g., date 200710280222.39 sets time in KRAST timezone (local time is GMT+8 in summer) and date 200710280222.40 sets it so timezone changes to KRAT. How could I set it to 200710280259 KRAST? 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. I don't think so, it seems that Windows keeps it's own flag to know if it should adjust local time for daylight savings. As you noted, FreeBSD always clears CMOS bit and that has no affect on Windows behavour. 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) The same in CURRENT. It seems we could use this bit as storage flag :-) I think about diskless stations that has no other storage for this. Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mike Lempriere- Home: [EMAIL PROTECTED] Phone: 206-780-2146 Cellphone: 206-200-5902; text pager: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CMOS, daylight saving time and dual-boot
On Sun, Oct 28, 2007 at 09:53:56AM -0700, Mike Lempriere wrote: If you're in the US, you're a week early for the changeover -- your timezone files need to be corrected. No, I'm not. I'm in Russia. Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CMOS, daylight saving time and dual-boot
On Sun, Oct 28, 2007 at 10:02:11AM -0700, Doug Barton 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. Suppose, the machine does not have global connectivity at all (and it has no local source of exact time) or just at the boot time. It still needs to adjust local time, right? It seems to me as DST problem really, not NTP problem. Eugene ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
