From owner-freebsd-stable Wed Mar 6 15: 2:29 2002 Delivered-To: freebsd-stable@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 516EA37B404 for ; Wed, 6 Mar 2002 15:02:27 -0800 (PST) Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 6 Mar 2002 23:02:26 +0000 (GMT) To: Matthew Dillon Cc: "Jan L. Peterson" , freebsd-stable@FreeBSD.ORG Subject: Re: crashes on 4.5-RELEASE In-Reply-To: Your message of "Wed, 06 Mar 2002 14:51:22 PST." <200203062251.g26MpM258927@apollo.backplane.com> Date: Wed, 06 Mar 2002 23:02:26 +0000 From: Ian Dowse Message-ID: <200203062302.aa66019@salmon.maths.tcd.ie> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200203062251.g26MpM258927@apollo.backplane.com>, Matthew Dillon wri tes: > > I wonder if a TCP nfs mount would cause the problem to occur more > often. Then you wouldn't need an IPFW rule.... a simple TCP stall > in a heavily loaded environment would be enough to cause the output > buffer to grow to a considerable size. Yes, that's certainly possible. Can someone who has a crash dump handy run netstat -m -N kernel.X -M vmcore.X to get the mbuf stats? I think with TCP the buildup would be much slower, as a (as far as I remember) retransmits are limited. In -CURRENT (which is the only place I have seen the IPFW/NFS mbuf exhaustion) I think sosend() was returning EPERM, but the mbufs were still building up. That may be a new bug somewhere. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message