From owner-freebsd-net@FreeBSD.ORG Tue Sep 28 14:27:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4259216A4CE for ; Tue, 28 Sep 2004 14:27:51 +0000 (GMT) Received: from mail.borderware.com (mail.borderware.com [207.236.65.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC93D43D1D for ; Tue, 28 Sep 2004 14:27:46 +0000 (GMT) (envelope-from fming@borderware.com) Message-ID: <415974DF.8080009@borderware.com> Date: Tue, 28 Sep 2004 10:27:43 -0400 From: ming fu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Pierre Beyssac References: <20040927182722.GA1664@bofh.enst.fr> In-Reply-To: <20040927182722.GA1664@bofh.enst.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: reproductible hang with if_em X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 28 Sep 2004 14:27:51 -0000 I have experienced the same thing with 4.7 as well. The driver just refuse to send anymore and won't self recover. However, tcpdump on the interface will still see traffic on the network, so receive seem working. Upgrade the driver to the most up-to-date code from 4.10 tree or from Intel does not help. Looking at the em_watchdog, there is a test that could cause the watchdog to do nothing. Comparing to the similar fxp driver, fxp watchdog just go ahead to restart the driver. Ming Pierre Beyssac wrote: >Hello, > >I'm having a problem (under 5.3-BETA, but I don't think it matters >much) with the if_em driver on bursty outbound traffic: the card >is stuck in a state where it only returns ENOBUFS. No buffers ever >become available again, but ifconfig down+up fixes the problem. > >>From a quick analysis it looks like the TX descriptor cleanup routine >em_clean_transmit_interrupts() as called by em_encap() in such cases >doesn't manage to find anything free with E1000_TXD_STAT_DD set. >The card seems stuck in this state. A simple albeit dirty fix would >be to cancel some or all untransmitted packets in such cases. > >Perhaps this is related to my using the card on a 100Mbps switch. >I have a small program to exercise the hang in case someone would >like to have a look at it. > >See below for the result of "sysctl hw.em0.debug_info=1" (notice >the not avail1 = 12 and not avail2 = 0 hinting at >em_clean_transmit_interrupts). > >em0: [MPSAFE] >em0: bpf attached >em0: Ethernet address: 00:0d:56:d0:5c:15 >em0: Speed:N/A Duplex:N/A >em0: Link is up 100 Mbps Full Duplex >em0: Adapter hardware address = 0xc3570b34 >em0:tx_int_delay = 66, tx_abs_int_delay = 66 >em0:rx_int_delay = 0, rx_abs_int_delay = 66 >em0: fifo workaround = 0, fifo_reset = 0 >em0: hw tdh = 238, hw tdt = 238 >em0: Num Tx descriptors avail = 256 >em0: Tx Descriptors not avail1 = 12 >em0: Tx Descriptors not avail2 = 0 >em0: Std mbuf failed = 0 >em0: Std mbuf cluster failed = 0 >em0: Driver dropped packets = 0 > > >