From owner-freebsd-stable@FreeBSD.ORG Sat Mar 6 20:21:33 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76D031065673 for ; Sat, 6 Mar 2010 20:21:33 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0688FC15 for ; Sat, 6 Mar 2010 20:21:33 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta12.emeryville.ca.mail.comcast.net with comcast id pumb1d0090FhH24ACwMZAC; Sat, 06 Mar 2010 20:21:33 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.emeryville.ca.mail.comcast.net with comcast id pwMZ1d0023S48mS8UwMZlW; Sat, 06 Mar 2010 20:21:33 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AE9481E3035; Sat, 6 Mar 2010 12:21:31 -0800 (PST) Date: Sat, 6 Mar 2010 12:21:31 -0800 From: Jeremy Chadwick To: Nick Rogers Message-ID: <20100306202131.GA23232@icarus.home.lan> References: <147432021003051648x1a1417dfp3c778922ea2c571f@mail.gmail.com> <2a41acea1003051718r241ac3e9w6ceb37bde0128b43@mail.gmail.com> <20100306180029.GA99452@voi.aagh.net> <2a41acea1003061039s41dda598v563edf76d609c4f0@mail.gmail.com> <147432021003061208n64ebd9c9lb168cdfa520e94a3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <147432021003061208n64ebd9c9lb168cdfa520e94a3@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org, Jack Vogel Subject: Re: em(4) interface hangs under 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 20:21:33 -0000 On Sat, Mar 06, 2010 at 12:08:22PM -0800, Nick Rogers wrote: > Yes, this was the first em(4) problem I ran into when upgrading from > 7.2-RELEASE to 8.0-RELEASE. Yourself and others on another thread eventually > recommended turning off TSO and what not. I never had a chance to thoroughly > test this solution on this particular hardware because we had already > switched to a different set of interfaces (on-motherboard bge(4)). We also > had that ALTQ problem popup on em which I'm sure you remember, which > prevented me from going back to the em interfaces for a while. I've re-read your ALTQ post (Subject "em(4) + ALTQ broken") and I noticed you didn't provide any details regarding *how* you're using ALTQ on your systems (specifically, no pf.conf directives provided). We use pf and ALTQ on all our RELENG_7 and RELENG_8 systems, exclusively using em(4), without any problems. I should note that we only utilise the ALTQ pieces of pf.conf on RELENG_7, but ALTQ is included in our RELENG_8 systems' kernels. The ALTQ feature we use is "bandwidth" for rate-limiting certain IPs bound to em(4) interfaces. We've used this successfully at both 100mbit and 1000mbit interface rates. I can provide specific details of the systems (pciconf -lvc from them, including OS release + etc.) if you'd like to compare. I'm almost certain the NIC model you use differs from ours, including the fact that our NICs are PCIe-bound, and do use MSI + TSO + all forms of checksum offloading. Why I care: upgrading our RELENG_7 machine which uses ALTQ directives is on my to-do list, and if this feature is somehow broken under RELENG_8, I need to know in advance so I can use ipfw + dummynet instead. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |