From owner-freebsd-current Sat Oct 5 14:49:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2562B37B401; Sat, 5 Oct 2002 14:49:51 -0700 (PDT) Received: from mail.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE2343E3B; Sat, 5 Oct 2002 14:49:50 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id g95LmOb1029212; Sat, 5 Oct 2002 17:48:24 -0400 (EDT) Date: Sat, 5 Oct 2002 17:48:24 -0400 (EDT) From: Daniel Eischen To: Andrew Gallatin Cc: Peter Wemm , "Brian F. Feldman" , German Tischler , freebsd-current@FreeBSD.ORG, Daniel Eischen , Jonathan Mini Subject: Re: SSE In-Reply-To: <15775.21658.385069.581909@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 5 Oct 2002, Andrew Gallatin wrote: > Daniel Eischen writes: > > > > On further reflection, this DEFINITELY has to do with the work done on > > > > npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the > > > > fpu state that it's attempting to restore is corrupt (i.e.: the control word > > > > is incorrect), so something is not being initialized somewhere that it used > > > > to be, or is being initialized incorrectly. > > > > > > The last few commits to machdep.c bother me, rev 1.539 in particular. > > > > > > If you are in a position to be able to quickly test it, it would be great > > > to know if backing out the last few changes fixes this, and which change in > > > particular. > > > > There have been two commits since 1.539; what version of machdep.c > > is being used? > > 1.539 works. 1.540 crashes. The failure mode is: Bruce and I had a miscommunication over the setting of a flag. It turns out that we can't easily restore the FPU state from the PCB if the one in the ucontext is bad, anyways. Try the following patch: Index: i386/i386/machdep.c =================================================================== RCS file: /opt/d/CVS/src/sys/i386/i386/machdep.c,v retrieving revision 1.541 diff -u -r1.541 machdep.c --- i386/i386/machdep.c 5 Oct 2002 14:36:14 -0000 1.541 +++ i386/i386/machdep.c 5 Oct 2002 20:10:53 -0000 @@ -2222,12 +2222,17 @@ } else { /* * There is no valid FPU state in *mcp, so use the saved - * state in the PCB if there is one. XXX the test for - * whether there is one seems to be quite broken. We - * forcibly drop the state in sendsig(). + * state in the PCB if there is one. XXX We can't easily + * check to see if the state in the PCB is valid or not; + * there could have been nested signals, and for other + * reasons. For now, we'll just leave the FPU state unchanged. */ - if ((td->td_pcb->pcb_flags & PCB_NPXINITDONE) != 0) +#if 0 + if ((td->td_pcb->pcb_flags & PCB_NPXINITDONE) == 0) npxsetregs(td, &td->td_pcb->pcb_save); +#else + ; /* in case no compat is defined. */ +#endif #endif #if !defined(COMPAT_FREEBSD4) && !defined(COMPAT_43) return (EINVAL); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message