From owner-freebsd-current  Sat May 11 03:31:58 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id DAA02251
          for current-outgoing; Sat, 11 May 1996 03:31:58 -0700 (PDT)
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA02246
          for <current@freebsd.org>; Sat, 11 May 1996 03:31:53 -0700 (PDT)
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id DAA19743; Sat, 11 May 1996 03:31:23 -0700 (PDT)
Date: Sat, 11 May 1996 03:31:23 -0700 (PDT)
Message-Id: <199605111031.DAA19743@silvia.HIP.Berkeley.EDU>
To: bde@zeta.org.au
CC: bde@zeta.org.au, current@freebsd.org, nisha@cs.berkeley.edu
In-reply-to: <199605110914.TAA21036@godzilla.zeta.org.au> (message from Bruce Evans on Sat, 11 May 1996 19:14:07 +1000)
Subject: Re: some more on fast bcopy
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

 * It can't be interrupted, but it can go to sleep for handling a page
 * fault.  Then bad things may happen.

You mean they can get waken up in the wrong order and something
similar to what I said can happen?

 * This can probably be fixed by switching the FP context in cpu_switch().
 * 
 * It isn't even necessary to save the FP registers, at least in
 * non-interrupt handlers, if they aren't already in use.  In particular,
 * copyin() and copyout() are never called from interrupt handlers, so
 * it isn't necessary to preserve the kernel FP registers (they are
 * guaranteed to not be in use).  Only the user FP context needs to be
 * preserved.  This optimization is closely related to fixing the bug.
 * It should start out something like:

Cool cool.

 * 	if (intr_nesting_level > 0) {
 * 		/* Save reentrantly the same as now. */
 * 	} else {
 * 		if (npxproc != NULL) {
 * 			assert(npxproc == curproc);
 * 			fnsave(&curpcb->pcb_savefpu);
 * 			npxproc = NULL;
 * 		}
 :

Um, I assume you are talking about /sys/i386/i386/swtch.s, can you
somehow translate this into, say, assembly language? ;)  My x86
knowledge is not nearly enough for this kind of stuff....


 * It's normal for one stack frame to be missing for panics for fatal
 * traps.  I fixed this in rev.1.10 of exception.s but I think rev.1.14
 * broke it again.

I see.

Satoshi