[comp.unix.microport] uport V386 fp

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