On Thu, 8 Jul 1999, Peter Wemm wrote:

> Alfred Perlstein wrote:
> > On Wed, 7 Jul 1999, Peter Wemm wrote:
> > 
> > > > attempting to compile xscreensaver has triggered it twice in a row
> > > > /usr/ports is mounted off "server" (a freebsd -current box) and
> > > > doing the make will kill the machine.
> > > > 
> > > > Once I figure out where the heck I have the console redirected
> > > > I'll have something more substantial.
> > > 
> > > You have a block size of 32K, I'll bet it's 'Bad nfs svc reply' in
> > > nfs_syscalls.c.  This is triggered when the READDIRPLUS op generates
> > > an oversized reply and it triggers the sanity check.
> > 
> > odd, shouldn't it know not to violate its own sanity checks?  Just
> > throttle down the requests, or spit out an error?
> 
> Well, I still am having trouble getting my head around what's going on.
> In a nutshell, the code goes to a fair bit of trouble to not generate a
> packet that violates the protocols, and yet it still does, by a long shot.
> I'm setting up to try and reproduce this so I can catch it live rather than
> long afterwards.

odd.

> > > Change it to 16K and I think it'll work.  Otherwise change the panic to a
> > > printf(), but that is sweeping the problem under the carpet and might just
> > > give the client indigestion.  It does stop the server crashing though.
> > 
> > I'll try that, thanks, set my -r and -w to 16k.  Um something odd
> > though, from the code:
> > 
> > if (siz <= 0 || siz > NFS_MAXPACKET) {
> >   printf("mbuf siz=%d\n",siz);
> >   panic("Bad nfs svc reply");
> > }
> > 
> > then earlier:
> > nfsproto.h:#define      NFS_MAXPKTHDR   404
> > nfsproto.h:#define NFS_MAXPACKET        (NFS_MAXPKTHDR + NFS_MAXDATA)
> > nfsproto.h:#define      NFS_MAXDATA     32768
> > 
> > isn't 32k within the safe limits, or sometimes when building the RPC
> > reply it can just get too big?
> 
> It's running over by at least 250 bytes or so.  ie: 32K + 680, which is
> more than 32K + 404.  I have not got the protocol maps handy so I'm not yet
> sure if the limits are wrong, or the request is wrong, or the readdirplus
> code is wrong.  In any case, *something* is wrong. :-)

oy vey. :)

> 
> > Oh, one more thing, I'm getting "device busy" even when using -f
> > during my unmount of wedged nfs mounts, all I needed to do was
> > kill -9 a shell sitting in that dir, but shouldn't that be
> > unnessesary?
> 
> Umm.. what were you unmounting?  server:/mount or the /localmount?  There
> are some well known problems with trying to unmount /localmount for a
> wedged mount - the damn code stat's it and hangs itself.  Trying to fix
> this and yet accomodate all the other tweaks for handling symlinks
> (ie: /dev/cdrom -> /dev/cd0a) etc style hacks got me rather confused last
> time.
> 
> Also, the VM has changed a bit over the last few months, deadfs may not be
> finding all the hooks into the VFS that might be still there.

unmounting a hung nfs mount:

client% mount
/dev/da0s1a on / (local, soft-updates, writes: sync 10 async 9392)
...
server:/vol/extra/ports on /usr/ports
server:/vol/extra/ncvs on /home/ncvs
client% umount -f /home/ncvs
Device busy.
client%

-Alfred




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to