From owner-freebsd-amd64@FreeBSD.ORG Fri Jun 4 19:30:14 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC9B716A4CE; Fri, 4 Jun 2004 19:30:13 -0700 (PDT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 333F843D3F; Fri, 4 Jun 2004 19:30:13 -0700 (PDT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.249.37) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA0021EC3F; Sat, 5 Jun 2004 12:30:07 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 940B341D0; Sat, 5 Jun 2004 12:31:27 +1000 (EST) Date: Sat, 5 Jun 2004 12:31:27 +1000 From: Tim Robbins To: David Schultz Message-ID: <20040605023127.GA26469@cat.robbins.dropbear.id.au> References: <20040602064846.GA6124@VARK.homeunix.com> <20040603002015.GA14544@cat.robbins.dropbear.id.au> <20040603015315.GA739@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040603015315.GA739@VARK.homeunix.com> User-Agent: Mutt/1.4.1i cc: amd64@FreeBSD.ORG Subject: Re: Initial FP exception flags incorrect on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 02:30:14 -0000 On Wed, Jun 02, 2004 at 06:53:15PM -0700, David Schultz wrote: > On Thu, Jun 03, 2004, Tim Robbins wrote: > > On Tue, Jun 01, 2004 at 11:48:46PM -0700, David Schultz wrote: > > > I discovered that new processes on amd64 have the inexact flag > > > raised by default, at least on sledge. However, all the sticky > > > flags should be clear initially. > > [...] > > > I don't have any amd64 hardware of my own to test kernel patches > > > on, but if I were to make a wild guess as to how to solve the > > > problem, it would be the following patch. I would appreciate it > > > if someone could address the problem, or at least let me know > > > whether my proposed fix works. > > > > > > Index: sys/amd64/amd64/fpu.c > > > =================================================================== > > > RCS file: /cvs/src/sys/amd64/amd64/fpu.c,v > > > retrieving revision 1.149 > > > diff -u -r1.149 fpu.c > > > --- fpu.c 5 Apr 2004 21:25:51 -0000 1.149 > > > +++ fpu.c 2 Jun 2004 06:08:34 -0000 > > > @@ -73,6 +73,7 @@ > > > #define fnstsw(addr) __asm __volatile("fnstsw %0" : "=m" (*(addr))) > > > #define fxrstor(addr) __asm("fxrstor %0" : : "m" (*(addr))) > > > #define fxsave(addr) __asm __volatile("fxsave %0" : "=m" (*(addr))) > > > +#define stmxcsr(addr) __asm("stmxcsr %0" : "=m" (*(addr))) > > > #define start_emulating() __asm("smsw %%ax; orb %0,%%al; lmsw %%ax" \ > > > : : "n" (CR0_TS) : "ax") > > > #define stop_emulating() __asm("clts") > > > @@ -119,6 +120,8 @@ > > > fninit(); > > > control = __INITIAL_FPUCW__; > > > fldcw(&control); > > > + control = __INITIAL_MXCSR__; > > > + stmxcsr(&control); > > > fxsave(&fpu_cleanstate); > > > start_emulating(); > > > fpu_cleanstate_ready = 1; > > > > This seems to cause a panic (trap 12) on startup. Shouldn't it be ldmxcsr > > instead? Changing that causes a different kind of panic (trap 9.) > > Oops, you're right. The other problem is probably that control is > a u_short, so garbage gets loaded into the upper 16 bits of the CSR. > Making 'control' a u_int should fix the problem, but the following > patch introduces a new variable to avoid relying on endianness > for the fldcw. Thanks, Tim! > > > Index: sys/amd64/amd64/fpu.c > =================================================================== > RCS file: /cvs/src/sys/amd64/amd64/fpu.c,v > retrieving revision 1.149 > diff -u -r1.149 fpu.c > --- sys/amd64/amd64/fpu.c 5 Apr 2004 21:25:51 -0000 1.149 > +++ sys/amd64/amd64/fpu.c 3 Jun 2004 01:48:23 -0000 > @@ -73,6 +73,7 @@ > #define fnstsw(addr) __asm __volatile("fnstsw %0" : "=m" (*(addr))) > #define fxrstor(addr) __asm("fxrstor %0" : : "m" (*(addr))) > #define fxsave(addr) __asm __volatile("fxsave %0" : "=m" (*(addr))) > +#define ldmxcsr(r) __asm __volatile("ldmxcsr %0" : : "m" (r)) > #define start_emulating() __asm("smsw %%ax; orb %0,%%al; lmsw %%ax" \ > : : "n" (CR0_TS) : "ax") > #define stop_emulating() __asm("clts") > @@ -111,6 +112,7 @@ > fpuinit(void) > { > register_t savecrit; > + u_int mxcsr; > u_short control; > > savecrit = intr_disable(); > @@ -119,6 +121,8 @@ > fninit(); > control = __INITIAL_FPUCW__; > fldcw(&control); > + mxcsr = __INITIAL_MXCSR__; > + ldmxcsr(mxcsr); > fxsave(&fpu_cleanstate); > start_emulating(); > fpu_cleanstate_ready = 1; Apologies for the late response -- the new patch no longer causes panics on startup, and gives the expected results with your test program (0x00.) It doesn't seem to break any applications, but I don't do anything numerically intensive (X, KDE, Mozilla, compiling.) Tim