From owner-freebsd-current Thu Oct 28 18:47:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 400D3154D6 for ; Thu, 28 Oct 1999 18:47:30 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id VAA09814; Thu, 28 Oct 1999 21:47:27 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id VAA33250; Thu, 28 Oct 1999 21:46:57 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Oct 1999 21:46:56 -0400 (EDT) To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG Subject: Re: odd NFS behaviour with DU 4.F client In-Reply-To: <199910290103.SAA13818@apollo.backplane.com> References: <14360.50663.727201.679421@grasshopper.cs.duke.edu> <199910282225.PAA12530@apollo.backplane.com> <14360.60247.329457.247327@grasshopper.cs.duke.edu> <199910290103.SAA13818@apollo.backplane.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14360.64462.254136.673166@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > :Speaking of NFS changes, there was talk at one time about turning the > :nfsm macros into functions. Is this going to happen? > > No. The nfsm macros have goto's all over the place that jump outside > the macro, and also use local variables declared outside the macro. > Short of rewriting a fairly large hunk of the NFS code entirely it > aint gonna happen. Nobody is contemplating rewriting the code. Exactly why I wasn't going to try to do it myself ;-) But I could have sworn I read somewhere that somebody was planning it. Oh well. > You can use gdb to disassemble the code to locate the exact point where > the panic occured. It is definitely more difficult, but there isn't > much we can do about it. The rpc design tends to keep things aligned > and NFS packet elements tend to be sized such that alignment remains > intact, so if these panics can be tracked down the fixes should be > relatively easy to make. Unfortunately, we just don't see these sorts > of panics on Intel boxes all that much because IA32 allows misaligned > accesses. This means there are almost certainly alignment bugs in the > code. > > -Matt I'm all in favor of having all the developers have alphas so these things get caught early ;-) Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message