From owner-freebsd-questions@FreeBSD.ORG Mon May 31 21:46:59 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68D0D1065678 for ; Mon, 31 May 2010 21:46:59 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id E971E8FC1D for ; Mon, 31 May 2010 21:46:58 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OJCoz-0001iO-Ez for freebsd-questions@freebsd.org; Mon, 31 May 2010 23:46:57 +0200 Received: from pool-72-75-58-9.washdc.east.verizon.net ([72.75.58.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 May 2010 23:46:57 +0200 Received: from nightrecon by pool-72-75-58-9.washdc.east.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 May 2010 23:46:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org connect(): No such file or directory From: Michael Powell Followup-To: gmane.os.freebsd.questions Date: Mon, 31 May 2010 17:46:57 -0400 Lines: 49 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-72-75-58-9.washdc.east.verizon.net Subject: Re: Network sort of stops working with the em (intel) driver under load. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 21:46:59 -0000 mark rowlands wrote: > Newly built and cvsupped system,with GENERIC kernel, when copying > large amounts of data over a gigabit link via scp the network will > hang after a couple of gig. I can then no longer login via ssh. If I > leave it be, after about 12-24 hours I can then login again. (A reboot > of course fixes the issue immediately...) . > > The system is very vanilla, only accf_http in loader.conf. No sysctl > tuning done, no firewall hankypanky. > > pciconf -lv | grep -A4 ^em > em0@pci0:3:4:0: class=0x020000 card=0x001e8086 chip=0x100e8086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (82540EM)' > class = network > subclass = ethernet > > em0: port > 0xec00-0xec3f mem 0xfeae0000-0xfeafffff,0xff irq 17 at device 4.0 on > pci3 > > Suggestions as to where I could look for more information as to the > precise nature of the problem gratefully received. Current plan is to > purchase another variety of gigabit card to see if it is specific to > the intel card. > If memory serves, I think there may have been some traffic about something like this on the -CURRENT list. You might look/search there and see if it sounds similar. If it seems like it might be the same thing, look for an MFC back to -STABLE. Sometimes the fix for very a specific item which has been addressed is to take a system to -STABLE in order to obtain the fixed bits. Research and confirm first, before considering such an update. My policy on -STABLE in the past is I only think about going there for a very narrow and specific situation where I know I have a problem that the devs have seen, analyzed, and fixed, with subsequent MFC. Something else too - if you can disable the vr and the USB chips completely, it might provide a data point. IRQ sharing is supposed to work well, and it is something that may be eliminated from the scenario easily if you do not need these things. -Mike