From owner-freebsd-smp  Fri Nov 29 09:43:33 1996
Return-Path: owner-smp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA25515
          for smp-outgoing; Fri, 29 Nov 1996 09:43:33 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA25509
          for <freebsd-smp@freebsd.org>; Fri, 29 Nov 1996 09:43:25 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id BAA19182;
          Sat, 30 Nov 1996 01:42:01 +0800 (WST)
Message-Id: <199611291742.BAA19182@spinner.DIALix.COM>
X-Mailer: exmh version 1.6.9 8/22/96
To: Erich Boleyn <erich@uruk.org>
cc: Nate Williams <nate@mt.sri.com>, Steve Passe <smp@csn.net>,
        freebsd-smp@freebsd.org
Subject: Re: Pentium CPU steppings 
In-reply-to: Your message of "Fri, 29 Nov 1996 08:46:59 PST."
             <E0vTW5b-000543-00@uruk.org> 
Date: Sat, 30 Nov 1996 01:42:00 +0800
From: Peter Wemm <peter@spinner.dialix.com>
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Erich Boleyn wrote:
> Uh...  you can't just look at the "step" number.  The "model" number is
> also quite relevant.  The "family" is the chip design (386, 486, Pentium,
> etc.), the "model" is the major revision, and the "step" is the stepping.
> The 3 numbers are pretty much strictly ordered for severity of changes.

Ahh yes, sorry, I'd forgotten about this since it's been a while since 
I've seen anything other 5/2/x.

> The fdiv bug occurs in model 1 chips with stepping less then 6 (I think,
> don't quote me).  A higher stepping in the same model, or any higher model
> with any stepping is fixed.

Hmm, weren't both the P5-60/66 and the early P5-90's affected?  I was 
under the impression that model "1" of the "5" family was the 5V 
non-clock-multiplied 60/66Mhz Pentiums?  And model "2" was the improved 
3.3V design with the clock multiplication and the on-chip local APIC?

Anyway, according to this C version of the Intel test assembler code, 
0x521 (P5-90 in my case) has the bug:
/* be sure to disable optimisation when compiling, eg: gcc -O0 ... */
main()
{
        double x = 4195835.0;
        double y = 3145727.0;
        double result = (x - (x / y) * y);

        printf("x = %f, y = %f, result = %f, FDIV %s\n", x, y, result,
                result < 1.0 ? "OK" : "BUG PRESENT");
}

peter@spinner[1:34am]~/fdiv-128> ./chk 
x = 4195835.000000, y = 3145727.000000, result = 256.000000, FDIV BUG 
PRESENT
peter@spinner[1:34am]~/fdiv-130> dmesg | grep Step
  Origin = "GenuineIntel"  Id = 0x521  Stepping=1

And on a newer P5-100 cpu:
peter@curie[4:35am]~-108> cc -O0 -o chk chk.c
peter@curie[4:35am]~-109> ./chk
x = 4195835.000000, y = 3145727.000000, result = 0.000000, FDIV OK
peter@curie[4:35am]~-110> dmesg | grep Step
  Origin = "GenuineIntel"  Id = 0x525  Stepping=5

Grumble.. It looks like the low steppings of "model 2" have it as well. 
Damn..

Hmm, I wonder if it's safe to test for this at the end of npx.c in the 
kernel?

Cheers,
-Peter