From owner-freebsd-current Thu Oct 28 18: 3:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 35D9F14EF3 for ; Thu, 28 Oct 1999 18:03:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA13818; Thu, 28 Oct 1999 18:03:20 -0700 (PDT) (envelope-from dillon) Date: Thu, 28 Oct 1999 18:03:20 -0700 (PDT) From: Matthew Dillon Message-Id: <199910290103.SAA13818@apollo.backplane.com> To: Andrew Gallatin Cc: freebsd-current@FreeBSD.ORG Subject: Re: odd NFS behaviour with DU 4.F client References: <14360.50663.727201.679421@grasshopper.cs.duke.edu> <199910282225.PAA12530@apollo.backplane.com> <14360.60247.329457.247327@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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. :I ask because I've seen occasional unaligned access panics on :FreeBSD/alpha in the client side code. I've only seen them on a :really lossy link (basically a misconfigured duplex on a 100Mb link). :They tend to be in nfs_request (nfs/nfs_socket.c:110) or nfs_readrpc :(nfs/nfs_vnops.c:1093). These are both calls to nfs macros that would :be a lot easier to debug if they weren't macros ;-) : :Thanks, : :Drew :------------------------------------------------------------------------------ :Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message