From owner-freebsd-net@FreeBSD.ORG Tue Feb 1 21:43:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AD421065696; Tue, 1 Feb 2011 21:43:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2CFAB8FC17; Tue, 1 Feb 2011 21:43:58 +0000 (UTC) Received: by ywp6 with SMTP id 6so2857205ywp.13 for ; Tue, 01 Feb 2011 13:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0+Hq/tHMUWsidQ5/7U7H66rJj6c/S8697deFwQxCdUI=; b=TKfrQr3lptDQV8SAvqaOKn2Z4NPvvYjQAczIDB81V200ItKwksdbik7oK7TEN3DczY aLDIhpxQdlYLFoikDwQW+zw8DtYvjb7eFjJCIbBFkPiLIuRjgFbfYpldqaABXuxRt6kr xFqnyI9rGIDVVZcYl6mGAjSm8CdHFZdUoUpv8= 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=k+Xp4qZI+MeSbUKZVh2o9TYhXhV0AJhhnVSEcxHScYUmVzrimf9yQRFGwn6c22TlGG a4DPumwrBIwx/qP9SXh3NvYkxpnAIjIbp/1/u96flnwub734FyPwAL9aamockwLU0BMa soKsZdh3dkNuKAr7+nQmMUoDGlvqi+t2LqpcQ= MIME-Version: 1.0 Received: by 10.151.8.9 with SMTP id l9mr10326940ybi.79.1296596637310; Tue, 01 Feb 2011 13:43:57 -0800 (PST) Received: by 10.147.171.17 with HTTP; Tue, 1 Feb 2011 13:43:57 -0800 (PST) In-Reply-To: References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> Date: Tue, 1 Feb 2011 13:43:57 -0800 Message-ID: From: Jack Vogel To: Sean Bruno Content-Type: multipart/mixed; boundary=000e0cd4038cfbdee9049b3f6d45 X-Mailman-Approved-At: Wed, 02 Feb 2011 04:36:07 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , "freebsd-hardware@freebsd.org" , Ivan Voras , Jan Koum , Mike Tancsa Subject: Re: em driver, 82574L chip, and possibly ASPM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 21:43:59 -0000 --000e0cd4038cfbdee9049b3f6d45 Content-Type: text/plain; charset=ISO-8859-1 To those who are going to test, here is the if_em.c, based on head, with my changes, I have to leave for the afternoon, and have not had a chance to build this, but it should work. I will check back in the later evening. Any blatant problems Sean, feel free to fix them :) Jack On Tue, Feb 1, 2011 at 12:37 PM, Jack Vogel wrote: > Looks good, except I don't like code #if 0'd out, I'll make an if_em.c to > try and > send it shortly. > > Jack > > > > On Tue, Feb 1, 2011 at 12:19 PM, Sean Bruno wrote: > >> On Tue, 2011-02-01 at 12:05 -0800, Jack Vogel wrote: >> > At this point I'm open to any ideas, this sounds like a good one Sean, >> > thanks. >> > Mike, you want to test this ? >> > >> > Jack >> > >> > >> > On Tue, Feb 1, 2011 at 11:56 AM, Sean Bruno >> > wrote: >> > >> > On Fri, 2011-01-28 at 08:10 -0800, Mike Tancsa wrote: >> > > On 1/23/2011 10:21 AM, Mike Tancsa wrote: >> > > > On 1/21/2011 4:21 AM, Jan Koum wrote: >> > > > One other thing I noticed is that when the nic is in its >> > hung state, the >> > > > WOL option is gone ? >> > > > >> > > > e.g >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > >> options=19b >> > > > ether 00:15:17:ed:68:a4 >> > > > >> > > > vs >> > > > >> > > > >> > > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > > >> > > > >> > >> options=219b >> > > > ether 00:15:17:ed:68:a4 >> > > >> > > >> > > Another hang last night :( >> > > >> > > Whats really strange is that the WOL_MAGIC and TSO4 got >> > turned back on >> > > somehow ? I had explicitly turned it off, but when the NIC >> > was in its >> > > bad state >> > > >> > > em1: flags=8843 >> > metric 0 mtu 1500 >> > > >> > options=2198 >> > > >> > > ... its back on along with TSO? Not sure if its coincidence >> > or a side >> > > effect or what. For now, I have had to re-purpose this nic >> > to something >> > > else. >> > > >> > > debug info shows >> > > >> > > Jan 28 00:25:10 backup3 kernel: Interface is RUNNING and >> > INACTIVE >> > > Jan 28 00:25:10 backup3 kernel: em1: hw tdh = 625, hw tdt = >> > 625 >> > > Jan 28 00:25:10 backup3 kernel: em1: hw rdh = 903, hw rdt = >> > 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Queue Status = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: TX descriptors avail = >> > 1024 >> > > Jan 28 00:25:10 backup3 kernel: em1: Tx Descriptors avail >> > failure = 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX discarded packets = >> > 0 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Check = 903 >> > > Jan 28 00:25:10 backup3 kernel: em1: RX Next to Refresh = >> > 904 >> > > Jan 28 00:25:27 backup3 kernel: em1: link state changed to >> > DOWN >> > > Jan 28 00:25:30 backup3 kernel: em1: link state changed to >> > UP >> > > >> > > >> > > ---Mike >> > >> > >> > >> > I'm trying to get some more testing done regarding my >> > suggestions around >> > the OACTIVE assertions in the driver. More or less, it looks >> > like >> > intense periods of activity can push the driver into the >> > OACTIVE hold >> > off state and the logic isn't quite right in igb(4) or em(4) >> > to handle >> > it. >> > >> > I suspect that something like this modification to igb(4) may >> > be >> > required for em(4). >> > >> > Comments? >> > >> > Sean >> > >> >> >> Does the logic I've implemented look sane? >> >> Sean >> >> > --000e0cd4038cfbdee9049b3f6d45--