Date: Wed, 4 Aug 1999 00:29:51 +1000 From: Bruce Evans <bde@zeta.org.au> To: peter@netplex.com.au, stalker@feerbsd.org Cc: frank@tinker.exit.com, jim@thehousleys.net, smp@FreeBSD.ORG Subject: Re: ASUS P2B-DS versus SMP. Message-ID: <199908031429.AAA04667@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>However, some OS's dont use the BIOS, so this hack doesn't work. Most >unixes are included. FreeBSD happens to do the right thing and maintain >the century byte, so FreeBSD is normally Y2K fundamentally compliant >regardless of whether the underlying bios is or not. IE: if you're running FreeBSD doesn't use or maintain the century byte, except in some cases when the nonstandard undocumented option USE_RTC_CENTURY is configured. This option should be deleted. There is some chance of conflicting with a BIOS century byte update and/or bumping the century byte twice at the end of 1999. >under FreeBSD at the Y2K rollover, everything will work as expected, unless Here's what will happen: - the rollover will normally occur only in the kernel time variables. - if settimeofday(2) or clock_settime(2) is called after the rollover, then the RTC will be updated. Then the century byte will only be updated if USE_RTC_CENTURY is configured. - otherwise, the RTC will not be changed, so the century byte will not be updated. There is some chance of adjkerntz doing a settimeofday() so that this case doesn't apply. - on reboot, or perhaps when a BIOS call is made, the BIOS may update the century byte. - on boot or powerup, the BIOS may update the century byte. - on boot, FreeBSD will ignore the century byte unless USE_RTC_CENTURY is configured. This will just work until about 2070, except: - some RTC's will mishandle the leap year on 28 Feb 1999. On systems with the RTC set to local time, there is a good chance of adjkerntz doing a settimeofday() which fixes the problem. Is this what is expected? :-) >you've got a really old system that doesn't have a century byte at all. (I >think the PC and PC/XT were the main class of machines that didn't have >this, the AT and beyond all had it as far as I know. Some older clones may >be missing it). All systems with an RTC have the RAM where the century byte is. The issue is whether the BIOS supports it, and whether year 00 is handled as a leap year. >So, the manufacturers came up with a new software workaround... On the >440BX/LX/whatever chipsets and higher, the chip can be programmed to >generate a SMI trap when accessing certain registers, which is NOT maskable >by software. THey elected to trap all accesses to the realtime clock and >cmos registers (it's done by a register window, so it's an all or nothing >deal). So, when (say) freebsd reads or writes the hardware realtime clock, >a SMI trap is generated. The processor stalls, dumps state, and begins >executing the bios in REAL mode to "detect" the y2k rollover and simulate >the century byte changing automatically. The y2k testers are fooled since >there is no trace of the Bios "patch" happening except that it appears >to take a rather long time to read/write the clock registers. Gak! >And this callout in SMI mode to the bios is what is usually the culprit for >screwing up the statclock in newer systems. How does it break the statclock? Handling statclock interrupts in the BIOS would do it. Well, it is not easy determine the statclock status without clearing any interrupt. The SMI handler might have to call or include a statclock handler just to make RTC interrupts work under DOS. >(Footnote, I just did some checking.. we actually don't quite do what I >suggested above, we in fact totally ignore the century byte. If the YY >value is < 70, we assume post-2000. Y2K compliant bioses will patch this >on boot anyway.) Right. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908031429.AAA04667>