From owner-freebsd-hardware@FreeBSD.ORG Tue Feb 1 19:56:49 2011 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66E231065679; Tue, 1 Feb 2011 19:56:49 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9D68FC25; Tue, 1 Feb 2011 19:56:48 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p11JuU9U033130; Tue, 1 Feb 2011 11:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=yahoo-inc.com; s=cobra; t=1296590191; bh=WHTIhaRlpqT+nb1zqSWBS5Ncmjpc1u9WWJt7kbZTzPI=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version; b=Pv+2IW3l353HQgSgworStVGfSSe3jo/PzzmLvlbVBVRTwujGVkYbw+1H0bGbAWq/H JaXXR7JfsEWOlBBjNN4zKsUoUNSFkE8IuH7ZQ1/e44SiqZkKiz8WOHHYOjm3Ti/jdt dJiXhmpkDJOhGSZfSBk9nAWd0K2CFbtezFLkln1g= From: Sean Bruno To: Mike Tancsa In-Reply-To: <4D42EA74.4090807@sentex.net> References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> Content-Type: multipart/mixed; boundary="=-jFCXdpagJIiUUJVyJJjK" Date: Tue, 01 Feb 2011 11:56:30 -0800 Message-ID: <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Cc: "freebsd-net@freebsd.org" , Ivan Voras , Jack Vogel , Jan Koum , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:56:49 -0000 --=-jFCXdpagJIiUUJVyJJjK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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 --=-jFCXdpagJIiUUJVyJJjK Content-Disposition: attachment; filename="if_igb.diff_oactive" Content-Type: text/x-patch; name="if_igb.diff_oactive"; charset="UTF-8" Content-Transfer-Encoding: 7bit --- p4/freebsd_7/src/sys/dev/e1000/if_igb.c 2010-12-23 11:06:17.127417000 -0800 +++ p4/ybsd_7/src/sys/dev/e1000/if_igb.c 2010-12-23 11:28:50.476993000 -0800 @@ -784,10 +784,14 @@ return; /* Call cleanup if number of TX descriptors low */ +#if 0 if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD) igb_txeof(txr); +#endif while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { + if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD) + igb_txeof(txr); if (txr->tx_avail <= IGB_TX_OP_THRESHOLD) { ifp->if_drv_flags |= IFF_DRV_OACTIVE; break; @@ -1162,10 +1166,10 @@ IGB_TX_LOCK(txr); if (igb_txeof(txr)) more = TRUE; - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - igb_start_locked(txr, ifp); + /*if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) Pointless as igb_start_locked() checks this right off the bat*/ + igb_start_locked(txr, ifp); IGB_TX_UNLOCK(txr); - if (more) { + if (more || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { taskqueue_enqueue(que->tq, &que->que_task); return; } @@ -1361,7 +1370,7 @@ no_calc: /* Schedule a clean task if needed*/ - if (more_tx || more_rx) + if (more_tx || more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) taskqueue_enqueue(que->tq, &que->que_task); else /* Reenable this interrupt */ @@ -1535,6 +1545,14 @@ if (m_head->m_flags & M_VLANTAG) cmd_type_len |= E1000_ADVTXD_DCMD_VLE; +/* + * We just did this in before invocation, seems completely + * redundant, igb_handle_queue -> igb_txeof + * Pretty sure this is impossible as we check for the + * IGB_TX_CLEANUP_THRESHOLD in igb_start_locked() which happens + * before this func in invoked + */ +#if 0 /* * Force a cleanup if number of TX descriptors * available hits the threshold @@ -1547,6 +1565,7 @@ return (ENOBUFS); } } +#endif /* * Map the packet for DMA. --=-jFCXdpagJIiUUJVyJJjK--