From owner-freebsd-net@FreeBSD.ORG Thu Apr 17 23:48:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A85D22B8 for ; Thu, 17 Apr 2014 23:48:06 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 31B621258 for ; Thu, 17 Apr 2014 23:48:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEAPVnUFODaFve/2dsb2JhbABZg0FXgxO5HYZmUoE4dIIlAQEBAwEBAQEgBCcgCwUWDgoCAg0ZAikBCSYGCAcEARoCBIdTCA2oZ6MvF4EpjGgBAQ0ONAeCb4FJBIh0jSKED5EWg00hMX0HFyI X-IronPort-AV: E=Sophos;i="4.97,882,1389762000"; d="scan'208";a="115926903" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 17 Apr 2014 19:47:58 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 57E99B3F43; Thu, 17 Apr 2014 19:47:58 -0400 (EDT) Date: Thu, 17 Apr 2014 19:47:58 -0400 (EDT) From: Rick Macklem To: John Nielsen Message-ID: <2018376789.12960091.1397778478349.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Network troubles after 8.3 -> 8.4 upgrade MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 23:48:06 -0000 John Nielsen wrote: > On Apr 17, 2014, at 2:38 PM, Andrea Venturoli wrote: > > > Three days ago I upgraded an amd64 8.3 box to the latest 8.4. > > Since then the outside network is misbehaving: large mails are not > > sended (although small ones do), svn operations will work for a > > while, then come to a sudden stop, etc... > > Perhaps the most evident test is "wget"ting a big file: it will > > download some chunk, halt; restart after a while and download > > another chunk; lose the connection once again, then restart and so > > on. > > > > I remember a couple of similar experiences in the past, from which > > I got out by disabling TSO; however those box had fxp cards, while > > this has an em. > > In any case disabling TSO did not help. > > My first thought was TSO as well, since I've seen the symptoms you > describe a few times on systems running 10.0. Do you use IPFW or any > kind of NAT on this system? When an application encounters a network > problem, does it report or log anything at all? Anything in the > kernel log/dmesg? > > A bit of a shot in the dark, but could you try applying r264517 > (fixes a problem with VLAN and TSO interaction)? > http://svnweb.freebsd.org/base/head/sys/net/if_vlan.c?r1=257241&r2=264517 > Since the only net driver that sets if_hw_tsomax is Xen's netfront, the patch only affects systems that use that at this time. (The bug, which was also in if_lagg.c, was found during testing of an experimental patch for a net driver.) So, I'm pretty sure that patch won't help, rick > Otherwise my only other thought would be the driver. Can you try > reverting only the em(4) driver back to 8.3? If that helps it would > give you both a workaround and a clue for where to look for a > solution. Build modules and a kernel without em(4) from unmodified > 8.4 src, load em(4) as a module, confirm that the problem persists. > Replace the contents of src/sys/dev/e1000, src/sys/modules/em and > src/sys/conf/files with those from an 8.3 src tree (or otherwise > revert revision 247430), rebuild em module, unload/reload or reboot, > see if problem goes away. (Could be somewhat complicated by the fact > that you also have igb interfaces which also use code from the e1000 > directory, but rather than speculate I'll leave solving that as an > exercise for someone else.) > > JN > > > This is the relevant part of rc.conf: > >> cloned_interfaces="lagg0 vlan1 vlan2 vlan3 carp0 carp1 carp3 carp4 > >> carp6 carp7 carp9 carp10" > >> ifconfig_igb0="up" > >> ifconfig_igb1="up" > >> ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1 > >> 192.168.101.4 netmask 255.255.255.0" > >> ifconfig_lagg0_alias0="inet 192.168.101.101 netmask 0xffffffff" > >> ifconfig_carp0="vhid 1 advskew 100 pass xxxxxxx 192.168.101.10" > >> ifconfig_carp1="vhid 2 pass xxxxxxxx 192.168.101.10" > >> ifconfig_em0="up" > >> ifconfig_vlan1="inet 81.174.30.11 netmask 255.255.255.248 vlan 4 > >> vlandev em0" > >> ifconfig_vlan2="inet 83.211.188.186 netmask 255.255.255.248 vlan 2 > >> vlandev em0" > >> ifconfig_vlan3="inet 192.168.2.202 netmask 255.255.255.0 vlan 3 > >> vlandev em0" > >> ifconfig_carp3="vhid 4 advskew 100 pass xxxx 81.174.30.12" > >> ifconfig_carp4="vhid 5 pass xxxxxxx 81.174.30.12" > >> ifconfig_carp6="vhid 7 advskew 100 pass xxxxxx 83.211.188.187" > >> ifconfig_carp7="vhid 8 pass xxxxxxxxxxx 83.211.188.187" > >> ifconfig_carp9="vhid 10 advskew 100 pass xxxxxxxx 192.168.2.203" > >> ifconfig_carp10="vhid 11 pass xxxxxxxx 192.168.2.203" > >> ifconfig_lo0_alias0="inet 127.0.0.2 netmask 0xffffffff" > >> ifconfig_lo0_alias1="inet 127.0.0.3 netmask 0xffffffff" > >> ifconfig_lo0_alias2="inet 127.0.0.4 netmask 0xffffffff" > > > > As you can see the setup is quite complicated, but worked like a > > charm until the upgrade; actually the internal net (igb+lagg+carp) > > still does, so this is what points me toward em0, where I cannot > > seem to get any kind of stability. > > > > The card is > >> em0@pci0:6:0:0: class=0x020000 card=0x10828086 chip=0x107d8086 > >> rev=0x06 hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = 'PRO/1000 PT' > >> class = network > >> subclass = ethernet > > > > I tried disabling TSO, RXCSUM, TXCSUM, VLANHWTAG, VLANHWCSUM, > > VLANHWTSO... > > I tried putting the card into 10baseT/UTP mode... > > I tried sysctl net.inet.tcp.tso=0... > > > > None helped. > > > > Maybe I'm barking up the wrong tree, but nothing is in the logs to > > help... > > > > Nor did Google or wading through bug reports. > > > > > > > > Now I could restore the dumps I made before upgrading to 8.4 (but > > I'd really like to avoid this), try to upgrade even further to 9.2 > > (although this will be a lot of work and I'm not looking forward > > to it as a shot in the dark), drop in another NIC... > > What I'd really like, however, is some insight. > > > > Is this a known problem of some sort? Is this card or this driver > > known to be broken? > > Is there any way I could get some debugging info? > > > > Any hint is appreciated (and I need it badly :( !!!). > > > > bye & Thanks > > av. > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" >