I have a sparc64 machine which I recently upgraded to 8.0-RC3. It was previously running 6.3. I export the /home directory from it (with -alldirs set) and mount a subdirectory on a FreeBSD 7.2/i386 client machine. Attempting to ls(1) the directory on the client causes the sparc64 server to panic. I have a core kgdb(1) doesn't appear to run under sparc64. I enabled KDB and here is some output from it (unfortunately hand copied since I don't have a serial console set up). panic: trap: memory address not aligned cpuid = 1 KDB: stack backtrace: panic() at 0xc022a968 = panic+0x1c8 trap() at 0xc04fc230 = trap+0x4d0 -- memory address not aligned sfar=0xe6d7b424 sfsr=0x40029 %o7=0xc0402e4c -- fha_assign() at 0xc0402e60 = fha_assign+0x140 svc_run_internal at 0xc0427d5c = svc_run_internal+0x71c svc_thread_start at 0xc04281a8 = svc_thread_start+0x8 fork_exit at 0xc01f82e0 = fork_exit+0x80 fork_trampoline at 0xc00711e8 = fork_trampoline+0x8 Note that this may affect other architectures which care about memory alignment, but I'm putting it under sparc64 only for the moment. How-To-Repeat: /etc/exports on the sparc64 8.0-RC3 server: /home -alldirs -maproot=0 -network 10.0.0.0 -mask 255.255.255.0 On the client machine: > mount -t nfs sol:/home/glewis/sparc64 /home/glewis/sparc64 > ls ~glewis/sparc64 Note that I have the core.txt.0 and vmcore.0 from the the earlier attempt at using kgdb if they would be helpful. Since this is also easy to reproduce, I can provide additional data from KDB if it would be helpful and/or try out patches.
Responsible Changed From-To: freebsd-sparc64->freebsd-fs Over to maintainer(s).
Could you please test whether r199274/r199284 fix this problem? http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 @@ -206,7 +206,7 @@ if (error) goto out; - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); /* Content ourselves with zero offset for all but reads. */ if (procnum != NFSPROC_READ)
On Mon, Nov 23, 2009 at 08:49:13PM +0100, Marius Strobl wrote: > Could you please test whether r199274/r199284 fix this problem? > > http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u > > --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 > +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 > @@ -206,7 +206,7 @@ > if (error) > goto out; > > - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); > + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); > > /* Content ourselves with zero offset for all but reads. */ > if (procnum != NFSPROC_READ) Thanks Marius! I'll give it a try as soon as I can and let you know. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org
G'day Marius, On Mon, Nov 23, 2009 at 08:49:13PM +0100, Marius Strobl wrote: > Could you please test whether r199274/r199284 fix this problem? > > http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u > > --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 > +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 > @@ -206,7 +206,7 @@ > if (error) > goto out; > > - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); > + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); > > /* Content ourselves with zero offset for all but reads. */ > if (procnum != NFSPROC_READ) Yes, this fixes it! Thanks. Sorry for not finding that myself. I realise it may be too late to get this into the release. It might be worth an ERRATA notice if so. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org
On Tue, Nov 24, 2009 at 09:53:56PM -0800, Greg Lewis wrote: > G'day Marius, > > On Mon, Nov 23, 2009 at 08:49:13PM +0100, Marius Strobl wrote: > > Could you please test whether r199274/r199284 fix this problem? > > > > http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u > > > > --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 > > +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 > > @@ -206,7 +206,7 @@ > > if (error) > > goto out; > > > > - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); > > + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); > > > > /* Content ourselves with zero offset for all but reads. */ > > if (procnum != NFSPROC_READ) > > Yes, this fixes it! Thanks. Sorry for not finding that myself. > > I realise it may be too late to get this into the release. It might be > worth an ERRATA notice if so. > Marcel, do you have any such plans? Marius
No, no plans. I only wanted to go as far as putting in in -stable -- which I did. FYI -- Marcel (Mobile) On Nov 25, 2009, at 11:28 AM, Marius Strobl <marius@alchemy.franken.de> wrote: > On Tue, Nov 24, 2009 at 09:53:56PM -0800, Greg Lewis wrote: >> G'day Marius, >> >> On Mon, Nov 23, 2009 at 08:49:13PM +0100, Marius Strobl wrote: >>> Could you please test whether r199274/r199284 fix this problem? >>> >>> http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u >>> >>> --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 >>> +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 >>> @@ -206,7 +206,7 @@ >>> if (error) >>> goto out; >>> >>> - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); >>> + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); >>> >>> /* Content ourselves with zero offset for all but reads. */ >>> if (procnum != NFSPROC_READ) >> >> Yes, this fixes it! Thanks. Sorry for not finding that myself. >> >> I realise it may be too late to get this into the release. It >> might be >> worth an ERRATA notice if so. >> > > Marcel, do you have any such plans? > > Marius >
State Changed From-To: open->closed Close; this was fixed in r199274/r199284 for HEAD and in r199733 for stable/8. It was also submitted to re@ for consideration as an 8.0 erratum. This is pretty much all that can be done about this PR from a committer point of view.