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.