From owner-freebsd-net@FreeBSD.ORG Sun May 22 12:47:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93DC616A41C for ; Sun, 22 May 2005 12:47:07 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 522A343D49 for ; Sun, 22 May 2005 12:47:07 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 256FB346EF; Sun, 22 May 2005 06:47:06 -0600 (MDT) Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08550-02; Sun, 22 May 2005 06:47:05 -0600 (MDT) Received: from trust.cs.utah.edu (trust.cs.utah.edu [155.98.65.28]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id CA070346D9; Sun, 22 May 2005 06:47:05 -0600 (MDT) Received: by trust.cs.utah.edu (Postfix, from userid 4969) id AB5763F68; Sun, 22 May 2005 06:47:05 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by trust.cs.utah.edu (Postfix) with ESMTP id 9D89E3F62; Sun, 22 May 2005 06:47:05 -0600 (MDT) Date: Sun, 22 May 2005 06:47:05 -0600 (MDT) From: Vaibhave Agarwal To: Bruce Evans In-Reply-To: <20050522220248.D3215@epsplex.bde.org> Message-ID: References: <20050521031625.77340.qmail@web53907.mail.yahoo.com> <20050522220248.D3215@epsplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at cs.utah.edu Cc: freebsd-net@freebsd.org Subject: Re: npxintr from nowhere X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 12:47:07 -0000 > If you have a system newer than a 486SX, then npx interrupts shouldn't > be used for anything except to probe that not using them works. Can i disable the FPU, by commenting it out in the kernel config file?? > It > is barely possible that a bug in turning off npx interrupts after the > probe results in one being delivered much later (there have been bugs > in this area). I have enclosed part of my code in splimp() and splx(). Is that possible, that it queues the npx interrupt and deliver it later?? If this is the case, what shall I do?? > > If it was a real npx interrupt, then the address of the FP instruction > that caused it should be in the FPU state in the kernel dump. The kernel dump, shows that a line which has a "CALL" to a particular function caused the FPU interrupt, which is so wierd and the function also doesnt have any FP instruction. How can a CALL to a fuction cause the FPU interrupt, when the argument to the function are two valid pointers ? And the kernel has called that function at least 1000 times, before it gave an interrupt. thanks a lot bruce -vaibhave