ULSI vs Cyrix 387's

[David G. Hough on validgh]

Article: 68 of gnu.misc.discuss
From: fpmacrash.cts.com (Frank Maclachlan)
Newsgroups: comp.org.eff.talk,comp.os.mach,comp.unix.bsd,gnu.misc.discuss,misc.int-property,alt.suit.att-bsdi
Subject: 386BSD lockups caused by ULSI 387 coprocessor
Summary: ULSI 387 coprocessor can lock up!
Date: 10 Sep 92 03:21:41 GMT
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA

Ever since I upgraded the motherboard in my 386BSD 0.1 system from
a 386/20, 64 kb cache, w/ 4 mb of memory, no 387 to an OPTi chipset
based 386/40 w/ 64 kb cache, ULSI 387 coprocessor, and 16 mb of ram,
I experienced occasional lockups.  The system would simply freeze
and I had to hit the reset button to recover.  These lockups were
traced to my ULSI 387 math coprocessor.  I wrote a simple test program
which computed sin(5.0) in an infinite loop; this would lock up an
otherwise idle system after 4,000 to 150,000 iterations.  I then
modified npxprobe() in /sys/i386/isa/npx.c to not find the 387 and
the problem went away.

I called ULSI and was told that they were aware of the problem (they
had seen it on an SCO Unix system).  It seems that the ULSI part gets
into a state where its BUSY output to the 386 is permanently asserted
and the system locks up.  The person I talked to suggested that I ex-
change the ULSI 387 for a Cyrix equivalent.  I called my vendor and
got an RMA to return the ULSI part in exchange for a Cyrix 387.