bill@alembic.UUCP (Bill Hatch) (04/30/89)
Subject: uport 386 fp problems About 6 months ago there were several news articles about floating point problems with microport V386 with and without the 80387 coprocessor. My specific problems (without 80387) were solved when microport/john p. shipped me an engineering update to the dos merge kernel in december. I purchased a hardware fix to the 80387 problem (erratum 21) from Ironwood Electronics. However, in the process of reinstalling the 80387, I accidently burned out the chip. Therefore I was unable to test the Ironwood fix. (Note: the hardware fix from Bell Technologies was not compatable with my ALR 80386/220). We tested uport 3.0e on a compaq 386/20 portable (with 80387) and there was no problem as long as only one process was using floating point operations. If 2 processes used floating point, then the os crashed. 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: 1. Has anyone installed the Ironwood hardware fix; and did it fix the problem? On what hardware configuration and what brand/release of 80386 Unix? Also the Bell Technologies hardware fix ? Does anyone have Ironwood's address or phone - i lost these in a disk crash last month. 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 ? 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.) Our busines depends heavily on floating point intensive applications. I have been successful in persuading the management to try V386 Unix on 2 projects as a replacement for individual 8086/8087 DOS clunkers. Thus, I will be very grateful for any information in response to the above questions and comments on related issues. bill hatch uunet!bts!bill Computational Engineering 14504 Greenview Drive Suite 500 Laurel, Maryland 20708 Phone (301)470-3839 FAX (301)776-5451 HOME: (301)441-1675
rick@pcrat.UUCP (Rick Richardson) (05/01/89)
In article <3452@alembic.UUCP> bill@alembic.UUCP (Bill Hatch) writes: >We tested uport 3.0e on a compaq 386/20 portable (with 80387) >and there was no problem as long as only one process was using >floating point operations. If 2 processes used floating point, >then the os crashed. I had a similar problem with a 287 coproc and 386/ix 1.0.6, except that the FP-using processes would just core dump. >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.) Well, all I can say is that my problem with the 287 disappeared when I upgraded to 386/ix 2.0 (SVR3.2). I assume there is now a software fix for the hardware bug which is now part of 3.2. I don't know if this fix works for 387 coprocs or not. -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
plocher%sally@Sun.COM (John Plocher) (05/02/89)
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 :-) -John Plocher