Date: Sat, 8 Apr 1995 22:56:47 +1000 From: Bruce Evans <bde@zeta.org.au> To: gwk@cray.com Cc: current@FreeBSD.org Subject: Re: 80387 hangs system at divide by zero Message-ID: <199504081256.WAA27527@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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: Some npx bugs were introduced on 950103 and fixed on 950217 and 950223, so the January and February snapshots have more npx bugs than usual. >it hangs where the driver forces a divide by zero in order to learn >which type of exception reporting the hardware uses. 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 It's nice to know that `disable npx0' works. >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. Oops. >The 2.0-RELEASE didn't hang during boot, but I assume it also hung >when I divided by zero in a program. At least I could force a lock up It's surprising that it didn't hang during the boot given the other problems that you reported. The probe tries harder to avoid hanging because there is no possibility of ^C'ing out of it, but I don't know of any cases where it does better. >Did you know about this problem? Is IRQ13 exception reporting broken >in the current versions? Some buggy i387 (in)compatibles and/or motherboards are reported to lock up the whole system (interrupts stop working; I think this is an i387 bug); others are reported to only stop IRQ13 working (I think this is a motherboard problem). FreeBSD makes no attempt to handle either problem. Linux handles the second problem using a timeout, so an i387 error only wastes an average of 1/2 a clock tick. The bugs in the Jan/Feb snapshots are only indirectly related to this. >I have a 40 MHz Intel 80386 noname system with a ULSI '387. This Some ULSI '387's are reported to have the first problem :-(. >problem is not too darn important to me, I can currently live with >disabling the '387, and hopefully I can upgrade to some sort of '486 >later this year... :-) ...just thought you might be interested. If >you want me to try anything specific just let me know. Most people seem to have upgraded already, judging by the low number of bug reports for the old SNAPs (only 2 or 3) :-). Please try the divide by zero in an application under a current snapshot, or under 2.0, or even under Linux. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504081256.WAA27527>