Date: Sat, 8 Apr 1995 11:14:52 -0600 From: nate@sneezy.sri.com (Nate Williams) To: gwk@cray.com Cc: bugs@FreeBSD.org Subject: Re: 80387 hangs system at divide by zero Message-ID: <199504081714.LAA22992@trout.sri.MT.net> In-Reply-To: <9504081147.AA03909@racer.dkrz.de>
index | next in thread | previous in thread | raw e-mail
Georg-W. Koltermann writes: > I am having a problem on my system with post 2.0 snapshots (some > snapshot in January and now 950210-SNAP). My system hangs in the npx > probe routine during bootup. Only the reset switch can wake it up > again. I inserted printf's in the code and could isolate the place: > it hangs where the driver forces a divide by zero in order to learn > which type of exception reporting the hardware uses. Ahh, you have a buggy chip. :( Can you see if your system hangs under DOS with the same thing, cause if it does it's time to replace your buggy hardware. It would be very difficult and extremely slow to check every divide to make sure they didn't do a divide/zero, so working around such an obvious hardware bug is not worth it in terms of performance or in terms of programmer time to do it. > The system boots > up normally when I either boot the kernel with the -c option and > 'disable npx0' (that's what I usually do so that I can work at all) or > when I skip the divide by zero code in the npx driver, hard coding > IRQ13 exception reporting at that point. In the latter case the > system will hang when I later start a program which divides by zero. You're best bet is to disable use of your 387 chip and rely on the FP emulator code. It's a short-term solution into you can get a working 387 chips, but I guess it's better than a hanging system > I have a 40 MHz Intel 80386 noname system with a ULSI '387. Ack, that's why. The ULSI chips are known rogues who should be taken out and shot with a high-powered rifle. (I'm from Montana can't you tell :) Natehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504081714.LAA22992>