Date: Sat, 5 Oct 2002 17:48:24 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Peter Wemm <peter@wemm.org>, "Brian F. Feldman" <green@FreeBSD.ORG>, German Tischler <tanis@gaspode.franken.de>, freebsd-current@FreeBSD.ORG, Daniel Eischen <deischen@FreeBSD.ORG>, Jonathan Mini <mini@FreeBSD.ORG> Subject: Re: SSE Message-ID: <Pine.GSO.4.10.10210051744170.28837-100000@pcnet1.pcnet.com> In-Reply-To: <15775.21658.385069.581909@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10210051744170.28837-100000>