Date: Tue, 03 Aug 1999 22:45:26 +0800 From: Peter Wemm <peter@netplex.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: stalker@feerbsd.org, frank@tinker.exit.com, jim@thehousleys.net, smp@FreeBSD.ORG Subject: Re: ASUS P2B-DS versus SMP. Message-ID: <19990803144526.B05431C1E@overcee.netplex.com.au> In-Reply-To: Your message of "Wed, 04 Aug 1999 00:29:51 %2B1000." <199908031429.AAA04667@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > >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. Well, 00 (century prefix 20) is a leap year, the next three 00's are not leap years. > >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. I've heard rumors that it resets the rtc 128hz interrupt or somehow disables it if a 128Hz interrupt happens while in SMI mode. > >(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. I wonder though, should we always write the century back, regardless of the USE_RTC_CENTURY option? If that's not safe (ie: maybe the bios uses century offset by 19, ie: 00 century = 1900, 01 = 2000, etc), then perhaps read the century at startup and change (ie: increment) it at rollover. So, 00 will change to 01, or 19 will change to 20, whatever. > Bruce Cheers, -Peter 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?19990803144526.B05431C1E>