From owner-freebsd-current  Fri May 10 21:26:57 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id VAA15371
          for current-outgoing; Fri, 10 May 1996 21:26:57 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA15359
          for <current@FreeBSD.ORG>; Fri, 10 May 1996 21:26:52 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id OAA11493; Sat, 11 May 1996 14:25:50 +1000
Date: Sat, 11 May 1996 14:25:50 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605110425.OAA11493@godzilla.zeta.org.au>
To: asami@cs.berkeley.edu, bde@zeta.org.au
Subject: Re: some more on fast bcopy
Cc: current@FreeBSD.ORG, nisha@cs.berkeley.edu
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> * I think this is caused by the FPU probe failing.  It only happens when
> * npxdna() returns 0, and npxdna() only returns 1 if the probe failed.
> * bcopy() is sure to be called at boot time before the npx0 probe, and
> * this might foul the probe.  There must be another bug for the crash to
> * be so long delayed.

>I've been saying bcopy() but the code is actually only called from
>copyin() and copyout(). ;)

Oops.  npxdna() is only relevant for user mode.  You must be getting a
trap of type T_DNA (device not available) in system mode.  This can't
happen :-).  `clts' make the coprocessor device available and nothing
should change the TS bit.

Bruce