Skip site navigation (1)Skip section navigation (2)
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>