From root@rainbow.deep.forest.od.ua  Mon Jul  8 11:23:00 2002
Return-Path: <root@rainbow.deep.forest.od.ua>
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 97FCD37B400
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  8 Jul 2002 11:23:00 -0700 (PDT)
Received: from Guest.Forest.Od.UA (Guest.Forest.Od.UA [195.138.73.220])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CCC5C43E31
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  8 Jul 2002 11:22:51 -0700 (PDT)
	(envelope-from root@rainbow.deep.forest.od.ua)
Received: (from uucp@localhost)
	by Guest.Forest.Od.UA (8.11.3/8.11.3) with UUCP id g68DanY83652
	for FreeBSD-gnats-submit@freebsd.org; Mon, 8 Jul 2002 16:36:49 +0300 (EEST)
	(envelope-from root@rainbow.deep.forest.od.ua)
Received: from Rainbow.Deep.Forest (localhost.Deep.Forest [127.0.0.1])
	by Rainbow.Deep.Forest (8.12.4/8.12.4) with ESMTP id g68IJK8a021204
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 8 Jul 2002 21:19:20 +0300 (EEST)
	(envelope-from root@rainbow.deep.forest)
Received: (from root@localhost)
	by Rainbow.Deep.Forest (8.12.4/8.12.4/Submit) id g68IJKKD021203;
	Mon, 8 Jul 2002 21:19:20 +0300 (EEST)
	(envelope-from root)
Message-Id: <200207081819.g68IJKKD021203@Rainbow.Deep.Forest>
Date: Mon, 8 Jul 2002 21:19:20 +0300 (EEST)
From: unicorn@forest.od.ua
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: crash, whith floating ops in kernel mode
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         40354
>Category:       i386
>Synopsis:       crash, whith floating ops in kernel mode
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 08 11:30:01 PDT 2002
>Closed-Date:    Sun Jul 14 04:32:55 PDT 2002
>Last-Modified:  Sun Jul 14 04:32:55 PDT 2002
>Originator:     unicorn
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD Rainbow.Deep.Forest 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Sun Jun 23 22:13:00 EEST 2002 root@Rainbow.Deep.Forest:/www/src/sys/i386/compile/RAINBOW i386

>Description:
	npx dna handler tries to modify curpcb even if it does not exist (yet).
	it couses page fault in kernel mode.
>How-To-Repeat:
	do some floating point operations before the first process created.
>Fix:

Index: npx.c
===================================================================
RCS file: /mnt/ncvs/src/sys/i386/isa/npx.c,v
retrieving revision 1.129
diff -u -r1.129 npx.c
--- npx.c	27 Mar 2002 05:39:20 -0000	1.129
+++ npx.c	8 Jul 2002 18:08:06 -0000
@@ -826,21 +826,27 @@
 	 */
 	PCPU_SET(fpcurthread, curthread);
 
-	exstat = GET_FPU_EXSW_PTR(PCPU_GET(curpcb));
-	*exstat = 0;
-	/*
-	 * The following frstor may cause an IRQ13 when the state being
-	 * restored has a pending error.  The error will appear to have been
-	 * triggered by the current (npx) user instruction even when that
-	 * instruction is a no-wait instruction that should not trigger an
-	 * error (e.g., fnclex).  On at least one 486 system all of the
-	 * no-wait instructions are broken the same as frstor, so our
-	 * treatment does not amplify the breakage.  On at least one
-	 * 386/Cyrix 387 system, fnclex works correctly while frstor and
-	 * fnsave are broken, so our treatment breaks fnclex if it is the
-	 * first FPU instruction after a context switch.
-	 */
-	fpurstor(&PCPU_GET(curpcb)->pcb_save);
+	if(PCPU_GET(curpcb) == NULL)
+	    printf("npxdna: Oops! No curpcb!\n");
+	else {
+	    exstat = GET_FPU_EXSW_PTR(PCPU_GET(curpcb));
+	    *exstat = 0;
+
+	    /*
+	     * The following frstor may cause an IRQ13 when the state being
+	     * restored has a pending error.  The error will appear to have been
+	     * triggered by the current (npx) user instruction even when that
+	     * instruction is a no-wait instruction that should not trigger an
+	     * error (e.g., fnclex).  On at least one 486 system all of the
+	     * no-wait instructions are broken the same as frstor, so our
+	     * treatment does not amplify the breakage.  On at least one
+	     * 386/Cyrix 387 system, fnclex works correctly while frstor and
+	     * fnsave are broken, so our treatment breaks fnclex if it is the
+	     * first FPU instruction after a context switch.
+	     */
+	    fpurstor(&PCPU_GET(curpcb)->pcb_save);
+	}
+    
 	intr_restore(s);
 
 	return (1);


>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: unicorn@forest.od.ua
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: i386/40354: crash, whith floating ops in kernel mode
Date: Tue, 9 Jul 2002 09:38:38 +1000 (EST)

 On Mon, 8 Jul 2002 unicorn@forest.od.ua wrote:
 
 > >Description:
 > 	npx dna handler tries to modify curpcb even if it does not exist (yet).
 > 	it couses page fault in kernel mode.
 
 curpcb is supposed to always exist if the npx dna handler is called.
 
 > >How-To-Repeat:
 > 	do some floating point operations before the first process created.
 
 Don't do that.  Normal floating point operations are only supported
 for user processes (*).  The kernel does some FP initializations, but
 it is supposed to be careful to call stop_emulating() before it does
 them so that an npx dna exception doesn't occur.
 
 (*) FP is close to working or working in kernel processes, but this
 is not supported.  FP is used in i586_bcopy() and i586_bzero(), but
 these are broken and not used in -current.
 
 Bruce
 

From: =?koi8-r?B?wsXM2cog2tfF0tg=?= <unicorn@rainbow.deep.forest.od.ua>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: i386/40354: crash, whith floating ops in kernel mode
Date: Tue, 9 Jul 2002 12:44:39 +0300 (EEST)

 Hi,
 
 On Tue, 9 Jul 2002, Bruce Evans wrote:
 
 | > >How-To-Repeat:
 | > 	do some floating point operations before the first process created.
 |
 | Don't do that.  Normal floating point operations are only supported
 | for user processes (*).  The kernel does some FP initializations, but
 | it is supposed to be careful to call stop_emulating() before it does
 | them so that an npx dna exception doesn't occur.
 Thanks. That was execly what I expect to hear. (: The driver which causes
 npx dne was ported by me and I tend to change all maths to fixed point
 arithmetics in near future. The patch I've send was a quick hack to see if
 driver realy works. But after argue with my coleeg (who think that FP is
 normal in kernel mode and patch realy fix some problem) we decide to submit
 it and see who was right.
 
 
State-Changed-From-To: open->closed 
State-Changed-By: mini 
State-Changed-When: Sun Jul 14 04:30:23 PDT 2002 
State-Changed-Why:  
Floating-point operations are not supported in the kernel, and this fix would 
not help move further in that direction. Also, the submitter has agreed that 
this change is incorrect. There is no further action here. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=40354 
>Unformatted:
