Date: Tue, 12 Oct 2004 21:31:45 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mikhail Teterin <Mikhail.Teterin@murex.com> Cc: bde@zeta.org.au Subject: Re: panic in ffs (Re: hangs in nbufkv) Message-ID: <200410130431.i9D4VjPJ094849@apollo.backplane.com> References: <416AE7D7.3030502@murex.com> <200410112038.i9BKcCWt051290@apollo.backplane.com> <416C1B10.7030103@murex.com> <200410121818.i9CIIGRx092072@apollo.backplane.com> <416C2502.5040505@murex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:I don't know, how, but the bug seems triggered by upping the
:net.inet.udp.maxdgram from 9216 (default) to 16384 (to match the NFS
:client's wsize). Once I do that, the machine will either panic or just
:hang a few minutes into the heavy NFS writing (Sybase database dumps
:from a Solaris server). Happened twice already...
:
: -mi
:
:P.S. Thanks for prompt responses and advice, BTW!
Interesting. That's getting a bit outside the realm I can help
with. NFS and the network stack have been issues in FreeBSD
recently so its probably something related. I do seem to
recall that NFS takes a callback from the network protocol
stack for input processing.
One thing I would do is to try using a TCP NFS mount instead
of a UDP NFS mount. It might work better simply due to
exercising a different part of the network code. The buffer
cache has some NFS specific stuff in it, but unless it has
been completely ripped up there shouldn't be anything that
would actually crash the machine. My bets are on the
network stack's interaction with NFS rather then NFS's
interaction with the buffer cache.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410130431.i9D4VjPJ094849>