Date: Thu, 04 May 2000 21:41:47 +0200 From: Gary Jennejohn <garyj@peedub.muc.de> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: NFS, rl0 and Alpha Message-ID: <200005041941.VAA36623@peedub.muc.de> In-Reply-To: Your message of "Wed, 03 May 2000 23:00:26 %2B0200." <200005032100.OAA64943@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon writes: >:Thanks, but there is code in rl_rxeof() to align to a 32 bit boundary. >:If that weren't the case than I would expect the Alpha to panic with >:other IP applications, not just NFS. >: >:I don't know, NFS must be doing something weird. >: >:--- >:Gary Jennejohn / garyj@muc.de gj@freebsd.org > > NFS will realign the data payload for misaligned packets. > > I agree it sounds like an issue in the NFS code somewhere. Something > that is slipping through unnoticed. If someone can get a crash dump > and do a stack backtrace, or even a simple DDB 'trace', it should be > opssible to track the problem down. OK. Unfortunately, gdb core dumps when I try to analyze a crash dump with a debugging kernel :( Even worse, gdb core dumps when I try to run a debugging gdb in gdb to find out why gdb is core dumping when I try to debug a kernel with symbols :(( Wonderful. I've managed to produce 5 crash dumps so far. Trace in ddb shows that the kernel is panicing in various places, so Matt's thesis that it will be easy to pinpoint is apparently shot full of holes :( I've tried various combinations of nfs mounting with tcp, nfsv2, nfsv3, w=1024 and r=1024. Using TCP mounts makes the panic happen less quickly, but as soon as I `ls' a "big" directory the kernel panics. "Big" seems to be more than 10 or 15 entries. Anyway, here's some of the output from a trace in ddb: panic() at panic+0x100 trap() at trap+0x610 XentUna() at XentUna+0x200 [here a list of various locations in the nfs code from various panics] nfs_readdirrpc() at nfs_readdirrpc+0x10ec nfs_readdirrpc() at nfs_readdirrpc+0x12bc nfs_request() at nfs_request+0x79c nfs3_access_otw() at nfs3_access_otw+0x744 nfs_lookup() at [I didn't write down the offset] _GLOBAL_OFFSET_TABLE_ Looking at a disassembly of e.g. nfs_readdirrpc tells me nothing at all. The Alpha's assembly is highly non-transparent. Trying to figure where the corresponding line in the C-code is located is pretty much impossible without debugging symbols - but see above. Looks like I'll have to live without NFS. At least cvsup works so I can keep my src and ports up to date. BTW I'm not using any off-the-wall options to compile the kernel. Just -O -pipe. --- Gary Jennejohn / garyj@muc.de gj@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005041941.VAA36623>