From owner-freebsd-bugs  Tue Feb 21 11:56:41 1995
Return-Path: bugs-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id LAA14424 for bugs-outgoing; Tue, 21 Feb 1995 11:56:41 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id LAA14417 for <freebsd-bugs@FreeBSD.org>; Tue, 21 Feb 1995 11:56:32 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA21626; Wed, 22 Feb 1995 06:51:31 +1100
Date: Wed, 22 Feb 1995 06:51:31 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199502211951.GAA21626@godzilla.zeta.org.au>
To: freebsd-bugs@FreeBSD.org, seb@erix.ericsson.se
Subject: Re: npxprobe1() machine freezes
Sender: bugs-owner@FreeBSD.org
Precedence: bulk

>The probing for npx0 causes my machine to completely lock up. The
>cause seems to be the fnop() that has been added in npxprobe1() (in
>i386/isa/npx.c) since 2.0-RELEASE. (I am running 950210-SNAP now). It
>works just fine if you comment out the fnop(). My machine is an old
>386 (Chips&Technologies chipset, AMI BIOS, and no math co-processor).
                                                OK

Oops, I misread your problem report.  Only a similar problem in
npxintr() has been fixed.

The problem seems to be that npxprobe1() tries several FPU instructions
to see if there is an FPU, and fnop() is not among the ones that are
safe to try.

Bruce