Date: Thu, 17 Apr 2014 19:47:58 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: John Nielsen <lists@jnielsen.net> Cc: freebsd-net@freebsd.org Subject: Re: Network troubles after 8.3 -> 8.4 upgrade Message-ID: <2018376789.12960091.1397778478349.JavaMail.root@uoguelph.ca> In-Reply-To: <CDFEE4B3-CFAD-4E99-B5FE-731FB3C3C6FC@jnielsen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
John Nielsen wrote: > On Apr 17, 2014, at 2:38 PM, Andrea Venturoli <ml@netfence.it> 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 <half-duplex> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2018376789.12960091.1397778478349.JavaMail.root>