FP SUMMARY

[Bill Hatch]

Subject: FP SUMMARY

The following is a digest of news articles and e-mail that resulted
from my recent request for information on FP problems with uport
Unix and 80386/80387 machines.  I greatly appreciate the effort that
these correspondents have expended to relay their knowledge and
experience to me.  

Date: 	Mon, 1 May 89 19:27:34 EDT
From: Mike Borza <uunet!maccs!nusip>

This problem turned out to be an error in the design of the '386,
which was corrected in the `D' production run.  All current Intel
80386 chips have `DX' as the final two characters of the part
number (something like `i80386 DX').  You should insist that your
vendor supply you with components at this step level or later (I
know of none later than D).  With a `DX' part, there should be no
need for any add-on hardware to fix the problem.

It is interesting to note that once the problem was identified,
Intel shipped the remaning parts stamped "16 bit software only".
To the best of my knowledge, Intel has never made good on any
defective 386 they shipped, and I've heard that there's a multi-
million dollar lawsuit in the courts somewhere in the southern
States with regards to this.

>
>My company is in the process of purchasing several 80386 machines
>with 80387 coprocessors and sockets for a Wytek.  One of the
>machines is a Hewett Packard (Vector ?) and the others are by
>Wells American.  I would like
>to get some answers to the following questions:
>
>2. Is this strictly a Microport V386 problem or is it a hardware
>(80383 chip) problem present to disrupt all varieties of 80386
>Unix unless hardware remedies are applied ?

It was hardware, occuring only under protected virtual address mode
when two or more processes simultaneously accessed the floating point
coprocessor.  I believe that the Weitek was not affected by this problem
because the interface to the CPU is significantly different from that of
the '387.

>
>3. Has anyone managed to get any version of V386 unix working
>with an 80387 so that more than one process can do floating point
>operations on a "generic" AT386 machine?  (Our intention is to
>use our unix machines as multi-user software development machines.)
>
We use our machines as multiuser software development machines and 
engineering workstations.  Our applications are F.P. intensive tasks
pertaining to integrated circuit design, including analog circuit
simulation, process and device simulation, and I.C. layout.  Our goal
is to ultimately get to one 386 per engineer, but at present we have
one machine supporting 3 users and a second supporting 2 users.
While this can get slow, it is adequate given our limited resources
at present.

One machine has a 25 MHz 386 and 387, 10 MB of DRAM, and 340 MB of disk.
The other is a 20 MHz 386 with 387, 4 MB or RAM, and 90 MB of disk.
We're running ISC 386/ix with X-Windows, and we've ported SPICE (a
circuit simulator), the Vienna tools (finite difference and finite
boxes process and devices simulators), KIC (an I.C. layout editor),
and other tools to our environment.  In general, we're happy with
ISC, but find the price steep.

Date: 3 May 89 23:24:11 CDT (Wed)
From: uunet!brian386!news (Wm. Brian McCane)

>2. Is this strictly a Microport V386 problem or is it a hardware
>(80383 chip) problem present to disrupt all varieties of 80386
>Unix unless hardware remedies are applied ?
>
No, This is not Microport Specific. (Well not exactly)  There is a fix
supposedly for it included with all V386r3.2 Unices.  The fix was
supposed to come from AT&T and have been written by Intel.  If Microport
had ever succeeded in releasing 3.2, it should have worked.
>
>3. Has anyone managed to get any version of V386 unix working
>with an 80387 so that more than one process can do floating point
>operations on a "generic" AT386 machine?  (Our intention is to
>use our unix machines as multi-user software development machines.)
>
Strangely enough, I don't have any problems running 15 simultaneous
tasks processing data collected by real-time systems in the field, which
do a very large percentage of floating point on the data.  My "FIX" was
to use Greenhill's C Compiler, it seems to have the software fix
"builtin".  Also, the problem should not occur on newer versions of the
80387, according to j. plocher.
>

Date: Mon, 2 Jan 89 23:33:11 EST
From: Bill Hatch <alembic!bill>

If you have FP problems with the 80387 in place then you may be 
suffering from ERRATUM 21.  A hardware fix is available from

	Ironwood Electronics
	(614)431-7025

Ask for Paul Jasmin; he is very helpful.  I tried this fix on my ALR.
It did not work but I suspect that I fried my 80387 chip in all of
the chip pulling exercises I went through.
(Later note: YES I DID FRY THE 80307 )

Good Luck - If you end up pulling out any chips be VERY careful.  Both
the 80386 and 80387 are square and can thus be plugged in 3 wrong ways
and one right way.   

Later note: I highly recommend that you pay your local computer vendor
to do any chip pulling and reinstallation. To date I have destroyed 2
80387 chips and still do not have a system with working FP hardware.
In this area, Washington D. C. the typical installation charge for an
80387 is $45.  I recommend that you provide the dealer with a SIMPLE login where
the .profile executes a comprehensive FP test (big arrays, lots of
malloc() and free, and some large (200x200) matrix multiplies.  
The test programs and scripts should include spawning of multiple
FP intensive processes.

You should perform this fp test on any new machines
as part of the in-house acceptance testing.  When a machine is delivered,
run the FP test off a floppy DOS boot disk.  If it does not pass, then
the 2-4 hour effort to install Unix is saved.  Next run the FP test
as soon as the core Unix capabilities are installed. Again, if the
machine flunks, you have still not wasted a lot of time.

Date: 2 May 89 00:50:47 GMT
Reply-To: plocher at sun.UUCP (John Plocher)
Organization: Sun Microsystems, Mountain View

The Erratum-21 bug which many have written about is a 386/387 hardware
bug.  Microport 3.0e and DosMerge 1.1.x do NOT have code to work around
this bug.  ATT 3.2 Unix (and thus Everex, ISC, SCO, BT, et al) has a
software fix for this problem.

The other thing which has come up is the fact that on several machines
(compaq and compaq clones especially) the co-processor detection is done
differently than Intel recomends (and thus different from the method
Microport assumed would be used).  In V/386 2.2 (and prev) we used the
Intel algorithm only.  In 3.0e we added special support for non-standard
coproc detection.  DosMerge 1.1 was built from the V/386 2.2 fp modules,
and thus does not handle fp detection on the compaq.  This was changed in
the Merge 1.1.1 engineering refresh to use the 3.0e fp modules.

Lastly, there have always been severe problems with the floating point handling in
ALL the versions of AT&Ts Unix for the [23]86 processors.  This includes Bills
commments about multiple fp intensive processes and the like.  I have NO first
hand experience that 3.2 has fixed this problem, but then again, I'm not a fp
deamon either :-)

(Thanks, John, for continuing to supply us with valuable uport technical
information.  - bill)