Date: Tue, 03 Aug 1999 21:12:36 +0800 From: Peter Wemm <peter@netplex.com.au> To: stalker <stalker@feerbsd.org> Cc: "James E. Housley" <jim@thehousleys.net>, frank@tinker.exit.com, smp@FreeBSD.ORG Subject: Re: ASUS P2B-DS versus SMP. Message-ID: <19990803131236.108C41C1E@overcee.netplex.com.au> In-Reply-To: Your message of "Tue, 03 Aug 1999 01:21:14 MST." <Pine.BSF.4.10.9908030120170.51740-100000@is.lamefree.com>
next in thread | previous in thread | raw e-mail | index | archive | help
stalker wrote: > FYI to all p2b-d(s) owners, asus has posted the release of the version > 1010 bios to their website.. http://www.asus.com.tw/ > > It says somethin in the release notes about a y2k fix.. It's that y2k fix that tends to cause all the trouble. As I understand it, something like this happens.. The clock chips have a bunch of counters and a chunk of battery backed up ram. The first few registers correspond to the counters, and the remainder of the address registers correspond to those ram cells. And there's the kicker.. The clocks generally have 2 digit year counters and the century byte is normally in a RAM cell, and the bios does the manual rollover of the centory byte when the end of century happens and the year counter rolls over. (This is the first phase of the y2k fix btw, most original bioses didn't detect the YY year rollover and neglected to update the century.) 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 under FreeBSD at the Y2K rollover, everything will work as expected, unless 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). Anyway, it seems certain Y2K compliancy software checkers were not satisfied with this and decided to test the clock chip directly with the bios interrupts disabled, and therefore disabling the software workaround. Since it's not easy to do this in hardware, most systems did it in software. Normally the first 16 addresses in the clock are counters and the rest are RAM. The century byte is at offset 0x32 (50th byte) and well away from the hardware registers and right in the middle of RAM, and therefore a pest to convert it to a register/counter/whatever. 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. And this callout in SMI mode to the bios is what is usually the culprit for screwing up the statclock in newer systems. We do not need the workaround. If you have the option, turn *OFF* the Y2K fixes in your bios - they give you the option for a reason - it's DAMN SLOW! and you most definately need to turn it off after Jan 1 2000. The other thing we can do (luoqi has posted patches) is disable this hack in the BX chipset and get the bios out of our damn hair. (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.) > stalks > > On Mon, 2 Aug 1999, James E. Housley wrote: > > > Frank Mayhar wrote: > > > > > > Well, I went out and bought another PII 400 for my box, flashed my BIOS t o > > > 1.009, installed the processor, and built 3.2-stable for SMP. I experien ced > > > the same clock problems others have seen. I took a suggestion I saw in > > > -hackers and flashed back to 1.006. Sure enough, the problems went away. > > > > > > I would strongly urge anyone with one of these motherboards who is trying to > > > do SMP to contact ASUS (at tsd@asus.com) and report the problem. Maybe w e > > > can actually either get the BIOS fixed, or see what FreeBSD is doing wron g, > > > if anything. (I sent my email to them this morning.) > > > -- > > > > Following multiple suggestions I got stats running on my ASUS P2B-D 3.x-Sta ble BIOS 1.008 by enabling APM in the bios and adding the following to my k ernel. It didn't work until I added the flag 0x0020 > > > > # > > # Notes on APM > > # The flags takes the following meaning for apm0: > > # 0x0020 Statclock is broken. > > # 0x0011 Limit APM protocol to 1.1 or 1.0 > > # 0x0010 Limit APM protocol to 1.0 > > # > > device apm0 at isa? flags 0x0020 > > > > Jim. > > --- > > James E. Housley PGP: 1024/03983B4D > > System Supply, Inc. 2C 3F 3A 0D A8 D8 C3 13 > > Pager: pagejim@notepage.com 7C F0 B5 BF 27 8B 92 FE Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au 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?19990803131236.108C41C1E>