From owner-freebsd-net Mon Feb 25 18:29:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d188.as14.nwbl0.wi.voyager.net [169.207.136.62]) by hub.freebsd.org (Postfix) with ESMTP id DCA2537B417 for ; Mon, 25 Feb 2002 18:29:27 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g1PKXkZM021729; Mon, 25 Feb 2002 20:33:46 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g1PKXin2021726; Mon, 25 Feb 2002 20:33:45 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 25 Feb 2002 20:33:44 +0000 (GMT) From: Mike Silbersack To: Yann GROSSEL Cc: freebsd-net@FreeBSD.ORG Subject: Re: dc TX underrun message In-Reply-To: <20020225113938.12bf08be.y.grossel@hexanet.fr> Message-ID: <20020225203050.U21168-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 25 Feb 2002, Yann GROSSEL wrote: > Hi, > > We have a new machine that is about to become a firewall. > > For now this machine is running but idle, that is, it has > no services running but sshd, and no default route. The > machine has been up for about 20 days, wihtout doing > anything. > > However 3 messages has been logged : > > Feb 5 14:30:18 blade /kernel: dc3: TX underrun -- increasing TX threshold > Feb 5 14:58:33 blade /kernel: dc3: TX underrun -- increasing TX threshold > Feb 19 09:38:39 blade /kernel: dc3: TX underrun -- increasing TX threshold > > What do these message mean ? Is there a hardware problem ? Don't worry too much about those messages; as far as I understand it, the default mode of the NIC is to start transmitting the packet as it is being DMA'd into the card. However, the default buffer size is too small, and the NIC gets ahead of the DMA transfer. Hence, the buffer is automatically being increased in size until the problem goes away. So, you've really only lost 4 packets to the problem, then it stabilized. You'll probably see the exact same behavior on every reboot. There have been patches to up the default buffer size and/or enable features to work around the problem on certain chipsets, but everything works well enough that I haven't been motivated to give them a serious look. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message