sparc64/142102: FreeBSD 8.0 kernel panics on sparc64 when accessing NFS

[Marius Strobl]

The following reply was made to PR sparc64/142102; it has been noted by GNATS.

From: Marius Strobl <marius at alchemy.franken.de>
To: Manuel Tobias Schiller <mala at hinterbergen.de>
Cc: Mark Linimon <linimon at lonesome.com>, FreeBSD-gnats-submit at FreeBSD.org
Subject: Re: sparc64/142102: FreeBSD 8.0 kernel panics on sparc64 when accessing NFS
Date: Wed, 30 Dec 2009 02:08:01 +0100

 On Wed, Dec 30, 2009 at 01:25:55AM +0100, Manuel Tobias Schiller wrote:
 > On Tue, 29 Dec 2009 19:53:58 +0100
 > Marius Strobl <marius at alchemy.franken.de> wrote:
 > > Oh, sorry, I had a bug in there, the svc code used a stale
 > > pointer to the mbuf with this. Could you please re-fetch
 > > and try again? I can't guarantee that this fixes the hang
 > > you experienced but at least in theory just re-aligning
 > > the data can't make the issue with the unaligned access
 > > any worse. Using the LOM or by breaking into the kernel
 > > by sending a break you should be able to power-cycle/
 > > reboot the machine without removing the power cord should
 > > it hang again though.
 > > What NFS client and with which mount options are you
 > > using to trigger is problem?
 > > 
 > > Marius
 > 
 > I managed to compile and test a kernel with your updated patch, and things
 > seem to work. I'll try to stress-test it over the night by copying a few
 > tens of gigabytes over and report back with the results. Also, if I'm
 > reading your patch correctly, we should be able to do without the bcopy
 > hack from PR 140797, so I'll recompile a kernel without it and try if that
 > works as well.
 
 I don't think so; nfs_realign() only guarantees 4-byte alignment
 as required by XDR and assumed by nfsm_srvmtofh_xx() further down
 the road but nfsfh_t needs 8-byte alignment.
 
 > 
 > Thanks a lot for all your help and your patience!
 > 
 
 Well, thanks a lot for testing so far!
 
 Marius