From owner-freebsd-stable@FreeBSD.ORG Thu Apr 8 19:17:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D67106564A for ; Thu, 8 Apr 2010 19:17:02 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 53B178FC0C for ; Thu, 8 Apr 2010 19:17:01 +0000 (UTC) Received: by wwb24 with SMTP id 24so488451wwb.13 for ; Thu, 08 Apr 2010 12:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=i8qB7KEKZNiJTw17FTElLKCWasbf3pqT5OBxq4by8zc=; b=U7U7bmfL46jxp+zjEiAHd2WD0HVIT45fvJCwV/4VgwG1W09rhluR1e2nwDEIC+ny0s bgvlOnTDRKKKM888CjI8bMabBXJzTF4QRWZbCDEJl/UHlKYMRUGdn1lNd8nPRVbU4zv0 23HriKKgBLT6BRAYqeTc+psKIyZCfCES5YmLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=icRaaAs2fQnTB//+cvo7VJWg2CWpM6X+ZIHuG1rlM0I0WRXAibPqdtAe3SC1ns02MV /fSnSc45vIMwpj2oScYNXq5t/dQpCNcEjL9LkwZJcDfRrYJhJDK0XocYEuBjgGyhckIv 5txAuoHcx3ssBqaWFz1ySSsrXaHQeRXbf5ABY= MIME-Version: 1.0 Received: by 10.216.11.8 with HTTP; Thu, 8 Apr 2010 12:17:01 -0700 (PDT) In-Reply-To: <20100408183900.GJ5734@michelle.cdnetworks.com> References: <201004081313.o38DD4JM041821@lava.sentex.ca> <7.1.0.9.0.20100408091756.10652be0@sentex.net> <201004081446.o38EkU7h042296@lava.sentex.ca> <20100408181741.GI5734@michelle.cdnetworks.com> <20100408183900.GJ5734@michelle.cdnetworks.com> Date: Thu, 8 Apr 2010 12:17:01 -0700 Received: by 10.216.172.5 with SMTP id s5mr287055wel.30.1270754221210; Thu, 08 Apr 2010 12:17:01 -0700 (PDT) Message-ID: From: Jack Vogel To: pyunyh@gmail.com, Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: em driver regression 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: Thu, 08 Apr 2010 19:17:03 -0000 Try the code I just checked in, it puts in the CRC stripping, but also tweaks the TX code, this may resolve the watchdogs. Let me know. Cheers, Jack On Thu, Apr 8, 2010 at 11:39 AM, Pyun YongHyeon wrote: > On Thu, Apr 08, 2010 at 11:27:10AM -0700, Jack Vogel wrote: > > You know, I'm wondering if the so-called ALTQ fix, which makes the TX > > start always queue is causing the problem on that side? > > > > I'm not sure because I didn't configure ALTQ so it might be NOP for > non-ALTQ case. > > > Jack > > > > > > On Thu, Apr 8, 2010 at 11:22 AM, Jack Vogel wrote: > > > > > > > > > > > On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon > wrote: > > > > > >> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote: > > >> > > > >> > OK, some more data... It seems dhclient is getting upset as well > > >> > since the updated driver > > >> > > > >> > Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to > > >> > 255.255.255.255 port 67 interval 6 > > >> > Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with > > >> > bytes received 332. > > >> > Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data > > >> > after udp payload. > > >> > Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1 > > >> > Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to > > >> > 255.255.255.255 port 67 > > >> > Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with > > >> > bytes received 332. > > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >> > > >> Try this patch. It should fix the issue. It seems Jack forgot to > > >> strip CRC bytes as old em(4) didn't strip it, probably to > > >> workaround silicon bug of old em(4) controllers. > > >> > > >> > > > Actually it did strip it, but its buried in the code in an obscure way, > > > that's > > > what I just realized by looking at the old code. having the hardware > strip > > > will be easier I think. > > > > > > > > >> It seems there are also TX issues here. The system load is too high > > >> and sometimes system is not responsive while TX is in progress. > > >> Because I initiated TCP bulk transfers, TSO should reduce CPU load > > >> a lot but it didn't so I guess it could also be related watchdog > > >> timeouts you've seen. I'll see what can be done. > > >> > > > > > > Will look at that as well. > > > > > > Thanks! > > > > > > Jack > > > > > > >