From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 24 11:08:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDBE810656A8 for ; Mon, 24 Aug 2009 11:08:01 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0788FC24 for ; Mon, 24 Aug 2009 11:08:01 +0000 (UTC) Received: from [195.4.92.13] (helo=3.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MfXP5-0004uW-MP; Mon, 24 Aug 2009 13:07:59 +0200 Received: from td106.t.pppool.de ([89.55.209.6]:33080 helo=ernst.jennejohn.org) by 3.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1MfXP5-0004Ce-4K; Mon, 24 Aug 2009 13:07:59 +0200 Date: Mon, 24 Aug 2009 13:07:57 +0200 From: Gary Jennejohn To: yuri@rawbw.com Message-ID: <20090824130757.560757fa@ernst.jennejohn.org> In-Reply-To: <4A92554F.1040506@rawbw.com> References: <4A92554F.1040506@rawbw.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: 149285::1251112079-00002DCE-ECFCB365/0-0/0-0 Cc: freebsd-hackers@freebsd.org Subject: Re: ral0 interface hangs with the message "No buffer space available" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 11:08:01 -0000 On Mon, 24 Aug 2009 01:54:39 -0700 Yuri wrote: > Almost every time when I leave system to download a large file I get ral > device inoperable after a while. > Pinging the other peer causes these messages: > > > ping 192.168.0.1 > PING 192.168.0.1 (192.168.0.1): 56 data bytes > ping: sendto: No buffer space available > ping: sendto: No buffer space available > > I don't believe that TCP buffer is legitimately filled up to the max > because after I bring it down and back up it works fine for a long > while. So why didn't this data go through before down/up? > > If TCP connections are slow buffers shouldn't just fill up: system can > and should be preventing this letting apps to hold data streams. > > Something isn't quite right. > > Why would network device hang in a steady download scenaio? > > 7.2-STABLE > The buffers aren't full, it's the send queue used by whichever driver it is which you are using. The down/up frees it up because all queued transmits are discarded. This should never happen in normal operation. You haven't really provided any useful information to allow further analysis. --- Gary Jennejohn