Date: Tue, 29 Dec 2009 01:00:11 GMT From: Marius Strobl <marius@alchemy.franken.de> To: freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/142102: FreeBSD 8.0 kernel panics on sparc64 when accessing NFS Message-ID: <200912290100.nBT10Bsg048172@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR sparc64/142102; it has been noted by GNATS. From: Marius Strobl <marius@alchemy.franken.de> To: Manuel Tobias Schiller <mala@hinterbergen.de> Cc: Mark Linimon <linimon@lonesome.com>, FreeBSD-gnats-submit@FreeBSD.org Subject: Re: sparc64/142102: FreeBSD 8.0 kernel panics on sparc64 when accessing NFS Date: Tue, 29 Dec 2009 01:58:29 +0100 On Mon, Dec 28, 2009 at 10:06:02PM +0100, Manuel Tobias Schiller wrote: > On Mon, 28 Dec 2009 14:26:50 -0600 > Mark Linimon <linimon@lonesome.com> wrote: > > > Just to add a data point, the Netra T1s in the package build cluster do > > not show this problem, so I'm guessing that you are hitting an edge > > on large file transfers. We run them pretty hard. I think you guys are talking about different things; AFAIK the package build cluster nodes only act as NFS clients but this problem is about when using machines with strict alignment requirements as an NFS server. > > > > mcl > > > Hi Mark, Marius, > > thanks for the data point. In the meantime, I managed to test a kernel > with the "official" fix from PR 140797, and I still get the crash when > trying to write a moderately sized file (20 Megabytes) to NFS. According > to the backtrace below, it crashes in line 1355 of > /usr/src/sys/nfsserver/nfs_srvsubs.c. > > Since I'm using the fix from the original problem report and RELENG_8_0 > sources cvsupped on December 20, I guess that means we are either using > different source trees (i.e. there is something in the sources for the > kernels used on your machines that helps), or there is some other > difference which I have not been able to pinpoint yet. Maybe you could > clarify before I try hacking away or finding other differences... > > Thanks, > > Manuel > > > ---- backtrack of panic follows ---- > panic: trap: memory address not aligned > cpuid = 0 > KDB: stack backtrace: > panic() at panic+0x1c8 > trap() at trap+0x4d0 > -- memory address not aligned sfar=0xfffff800016d08aa sfsr=0x40029 > %o7=0xc0528934 -- nfsm_srvmtofh_xx() at nfsm_srvmtofh_xx+0x24 > fha_assign() at fha_assign+0x12c > svc_run_internal() at svc_run_internal+0x71c > svc_thread_start() at svc_thread_start+0x8 > fork_exit() at fork_exit+0x80 > fork_trampoline() at fork_trampoline+0x8 > Uptime: 2m1s > Dumping 512 MB (2 chunks) > chunk at 0: 268435456 bytes | > I'm using a more or less current HEAD but the NFS code hasn't changed that much since 8.0, at least it doesn't contain any other alignment fixes I'm aware of. I think I got what the problem is but I still haven't managed to reproduce it so far. Could you please test whether the following patch makes a difference? http://people.freebsd.org/~marius/fha_extract_info_realign.diff Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912290100.nBT10Bsg048172>