Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!uxc!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.sys.ibm.pc
Subject: Re: 80386 versus 80387
Message-ID: <45900232@uxe.cso.uiuc.edu>
Date: 14 May 89 14:47:00 GMT
References: <1427@uw-entropy.ms.washington.edu>
Lines: 40
Nf-ID: #R:uw-entropy.ms.washington.edu:1427:uxe.cso.uiuc.edu:45900232:000:1491
Nf-From: uxe.cso.uiuc.edu!mcdonald    May 14 09:47:00 1989



>I have heard that there is a sporadic nasty interaction between 80386's
>and 80387 numeric co-processors, owing to a design flaw in the 80386,
>and that it is not cleared up yet.

This appears to be the straight poop on this - I got a FAX of a
genuine Intel erratum sheet from the kind folks at Phar Lap or
MicroWay, I forget which.

There is a bug in the silicon of early 80386's that causes a total
machine hang at random times if the following things all are true:

1) You have a 80386 and 80387.

2) The 80386 is earlier than DX step (DX step 386's say "DX" right
   on top. The 386's with the "double sigma" ARE sick.

3) You run in either 386 native 32-bit mode or virtual 8086 mode.

4) Paging is enabled. Note that Windows 386 and Desqview 386 meet
   conditions 3 and 4, as do most programs especially written for native
   386 mode using a 386 runtime system on top of DOS.

5) Your motherboard is of an afflicted design. Certain boards seem
   to have timings that prevent the problem from occurring. IBM
   Model 80's are afflicted.

6) The phase of the moon is wrong. This is very important. It
   really doesn't happen often.

My Model 80 was indeed afflicted. A new motherboard with a DX chip
fixed the problem. IBM apparently didn't just want to replace the
chip itself. Microway and Phar Lap claim that a DX chip alone will
fix the problem, but I never tried this.

Note that the symptom of this bug is not wrong results, but rather
a totally hung machine.

Doug McDonald