Date: Sun, 22 May 2005 06:47:05 -0600 (MDT) From: Vaibhave Agarwal <vaibhave@cs.utah.edu> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-net@freebsd.org Subject: Re: npxintr from nowhere Message-ID: <Pine.LNX.4.61.0505220633280.27158@trust.cs.utah.edu> In-Reply-To: <20050522220248.D3215@epsplex.bde.org> References: <20050521031625.77340.qmail@web53907.mail.yahoo.com> <Pine.LNX.4.61.0505220152010.22164@trust.cs.utah.edu> <20050522220248.D3215@epsplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.61.0505220633280.27158>