From owner-freebsd-current  Sat Apr  8 06:03:09 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id GAA14055
          for current-outgoing; Sat, 8 Apr 1995 06:03:09 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA14038
          for <current@freebsd.org>; Sat, 8 Apr 1995 06:02:17 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id WAA27527; Sat, 8 Apr 1995 22:56:47 +1000
Date: Sat, 8 Apr 1995 22:56:47 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199504081256.WAA27527@godzilla.zeta.org.au>
To: gwk@cray.com
Subject: Re: 80387 hangs system at divide by zero
Cc: current@FreeBSD.org
Sender: current-owner@FreeBSD.org
Precedence: bulk

>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