From owner-freebsd-net@FreeBSD.ORG Tue Feb 8 20:35:21 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 331F9106564A for ; Tue, 8 Feb 2011 20:35:21 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from fep27.mx.upcmail.net (fep27.mx.upcmail.net [62.179.121.47]) by mx1.freebsd.org (Postfix) with ESMTP id 9CEB18FC26 for ; Tue, 8 Feb 2011 20:35:20 +0000 (UTC) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep18-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110208203422.OQSV1353.viefep18-int.chello.at@edge05.upcmail.net>; Tue, 8 Feb 2011 21:34:22 +0100 Received: from pinky ([213.46.23.80]) by edge05.upcmail.net with edge id 5YaG1g01P1jgp3H05YaHvV; Tue, 08 Feb 2011 21:34:22 +0100 X-SourceIP: 213.46.23.80 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Pyun YongHyeon" References: <708793006.292748.1295186099577.JavaMail.root@erie.cs.uoguelph.ca> <20110117005524.GA1305@michelle.cdnetworks.com> <20110118.093804.74673434.sthaug@nethelp.no> <20110207002235.GA1244@michelle.cdnetworks.com> Date: Tue, 08 Feb 2011 21:34:15 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <20110207002235.GA1244@michelle.cdnetworks.com> User-Agent: Opera Mail/11.01 (Win32) X-Cloudmark-Analysis: v=1.1 cv=FXfX1j538S0toKVv4AeTokQJ/Dr7x98IW2CddS+R9NE= c=1 sm=0 a=trLqpcBp2roA:10 a=bgpUlknNv7MA:10 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=jDIqnEEcAAAA:8 a=6I5d2MoRAAAA:8 a=CZ0vI5ODKe6_T9WnYkEA:9 a=kNvgDllnPDXFXOSbYdwA:7 a=fSqStiGloApSD3bJASq2lZ35NGoA:4 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=WAC6n6Nrh-yNq3b5:21 a=AHIb1GCgqi-6RLmM:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: freebsd-net@freebsd.org, rmacklem@uoguelph.ca, sthaug@nethelp.no Subject: Re: bogus 0 len IP packet, was: Hang in VOP_LOCK1_APV on 8-STABLE with NFS. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Feb 2011 20:35:21 -0000 On Mon, 07 Feb 2011 01:22:36 +0100, Pyun YongHyeon wrote: > On Sun, Feb 06, 2011 at 11:54:49PM +0100, Ronald Klop wrote: >> On Sat, 22 Jan 2011 00:01:47 +0100, Ronald Klop >> wrote: >> >> >On Tue, 18 Jan 2011 09:38:04 +0100, wrote: >> > >> >>>> So, does anyone have an idea why the IP length field would be set >> to >> >>>0 >> >>>> for these TCP/IP packets? >> >>>> >> >>>> Here's some info from Ronald w.r.t. his hardware. (All I can think >> >>>of is >> >>>> that he could try disabling TSO, etc?) >> >>>> >> >>>> Thanks in advance for any help with this, rick >> >>>> >> >>> >> >>>It seems that issue came from TSO. Driver will set ip_len and >> >>>ip_sum field to 0 before passing the TCP segment to controller. >> >>>The failed length were 4446, 5858, 3034 and 4310 and the total >> >>>number of such frames are more than 35k within 90 seconds. Since >> >>>failed length 4310 is continuously repeated I guess there is edge >> >>>case where em(4) didn't free failed TCP segment for TSO. >> >>>I remember there was commit to HEAD(r217295) which could be related >> >>>with this issue. >> >> >> >>I'm seeing the same problem with Broadcom NetXtreme (bce) cards: >> >> >> >>bce0@pci0:3:0:0: class=0x020000 card=0x03421014 chip=0x164c14e4 >> >>rev=0x12 hdr=0x00 >> >> vendor = 'Broadcom Corporation' >> >> device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter >> >>(BCM5708)' >> >> class = network >> >> subclass = ethernet >> >> >> >>This is with 8.2-PRERELEASE. Turning off TSO (ifconfig bce0 -tso) >> >>removes the problem. >> >> >> >>Steinar Haug, Nethelp consulting, sthaug@nethelp.no >> >>_______________________________________________ >> >>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" >> > >> >I tried -tso and -txcsum in various combinations, but it didn't solve >> >the problem. I wil look for another brand of network card to try. But >> >this has to wait till monday when I'm at the office again. >> >> I also used another network card (rl0) and it has the same problem with >> NFS. I'm going to change some network cables to see if that helps. I >> have >> some hints that there might be something wrong with that. >> > > Hmm, given that rl(4) also shows the issue it seems the issue could > be in TCP/IP stack, not in driver side. rl(4) is dumb device so > network stack should do segmentation and checksum computation. > I highly doubt the issue came from faulty cable since other users > also reported the same issue. > Unfortunately I have no clue yet and I was not able to reproduce it > on my box. I vaguely guess some code in kernel changed the ip_len > to 0 in the middle of transmission. Rick's captured traffic looks > normal except 0 ip_len given that controller is computing checksum > on the fly. If mbuf chain was corrupted(e.g. m_len == 0) driver > would have failed to send those frames. Changing the cable didn't help indeed. I'm glad the issue is seen by others too. I will try to downgrade to an older version of FreeBSD to try to find the commit which broke it. But that can take a while, because it is time consuming and I have to do some real work also at work. :-) Thanks for taking the time for it and I hope we will find the cause someday, Ronald.