From owner-freebsd-current  Wed May 15 07:03:51 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA19682
          for current-outgoing; Wed, 15 May 1996 07:03:51 -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 HAA19670
          for <current@freebsd.org>; Wed, 15 May 1996 07:03:43 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id XAA22996; Wed, 15 May 1996 23:58:45 +1000
Date: Wed, 15 May 1996 23:58:45 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605151358.XAA22996@godzilla.zeta.org.au>
To: asami@cs.berkeley.edu, bde@zeta.org.au
Subject: Re: some more on fast bcopy
Cc: ccd@stampede.cs.berkeley.edu, current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>Okay, I implemented this (I think) with the help of gcc -S, but I
>still get "FPU not available" panics intermittently (often during
>"make install"s).  Here's the diff, can you please check and see if
>something's wrong?

It should work better with a kernel mode trap handler for "FPU not
available" :-).  Add a T_DNA case for kernel mode in trap() by copying
the first 5 lines from the user mode T_DNA case (`break;' if npxdna()
doesn't handle the panic (this "can't happen")).  When you get everything
working, add some tests and flags to restore the panic if an T_DNA
trap occurs unexpectedly (set a flag FP_KERNEL_USING_FP in pcb->pcbflags
while the kernel is using FP in fastmove() or elsewhere, and `break;'
for the kernel T_DNA case if this flag isn't set).

Also, the `intr_nesting_level > 0' case needs to preserve the TS bit.
This case probably hasn't been executed yet (it will be executed when
bcopy() uses fastmove() and an interrupt handler calls bcopy()).

Bruce