bill@alembic.UUCP (Bill Hatch) (05/07/89)
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@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)