*BSD News Article 10921


Return to BSD News archive

Received: by minnie.vk1xwt.ampr.org with NNTP
	id AA966 ; Wed, 10 Feb 93 15:09:26 EST
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!sdd.hp.com!usc!howland.reston.ans.net!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!csus.edu!netcom.com!alm
From: alm@netcom.com (Andrew Moore)
Subject: Re: GCC 2.3.3 + kernels
Message-ID: <1993Feb8.193438.4845@netcom.com>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <1l5h8tINN218b@obelix.uni-muenster.de>
Date: Mon, 8 Feb 1993 19:34:38 GMT
Lines: 38

In article <1l5h8tINN218b@obelix.uni-muenster.de> fraune@math.uni-muenster.de writes:
> Additionally, my 386 hung on heavy systemload (did this with the original 386bsd-0.1-kernel as well as with the patchkit 0.1 and 0.2 kernels. After 
>forcing 386bsd to use the NPX-emulator instead of my (ULSI-)387 anything 
>works fine. Did other users experience similar problems with the ULSI-NPX ?

I don't know if the following still holds:


From: fpm@crash.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!
Keywords: 387,ULSI,lockup
Message-ID: <1992Sep09.202141.9124@crash>
Date: 10 Sep 92 03:21:41 GMT
References: <1992Sep8.135040.5243@pegasus.com> <BRUNER.92Sep8172455@sp15.csrd.uiuc.edu> <1992Sep10.015507.27974@fcom.cc.utah.edu>
Followup-To: comp.unix.bsd
Distribution: na
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Lines: 22

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.