From owner-freebsd-net@FreeBSD.ORG Mon Feb 7 00:22:34 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 1A95F106564A for ; Mon, 7 Feb 2011 00:22:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CC5038FC13 for ; Mon, 7 Feb 2011 00:22:33 +0000 (UTC) Received: by iwn39 with SMTP id 39so4106710iwn.13 for ; Sun, 06 Feb 2011 16:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=9TxMC8bv32U1GPnJcfZjEOeDc4t3RxMzYKrFnZS+wxM=; b=ElE+fg0R1w1l2nD8axTADesmk55ZuZFhcLCHbgSLpDQ0mjOsJ6C6MQQk2CrGp6rSsF TkYDGAH7JCXaoM11opwB93Rw5OuRHX9VaZd9huvMR8lniCJgcaU4pCIF3R2OLrcey2Bc KB7/8E6b8zT34x2w/KQth9qJBlmloRqUNz2fU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=mbPKjwUNvvQ4Zdr2KprKK1ENyQHC7wLdTBr92ZW20ZajrunrSvY6F/WSsNte2HozXP T62bvsRoC0XSY7s8Mn6qbObvOQI30ZvfitsnBzko6rwplmzrYRVuA0CiK+FKNXzzMc1w Mjz1zM1lQ9RqPreg08yiFqGta2n1S/PplPR6Q= Received: by 10.42.213.136 with SMTP id gw8mr17696725icb.359.1297038153231; Sun, 06 Feb 2011 16:22:33 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id d21sm3240369ibg.21.2011.02.06.16.22.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 06 Feb 2011 16:22:31 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 6 Feb 2011 16:22:36 -0800 From: Pyun YongHyeon Date: Sun, 6 Feb 2011 16:22:36 -0800 To: Ronald Klop Message-ID: <20110207002235.GA1244@michelle.cdnetworks.com> References: <708793006.292748.1295186099577.JavaMail.root@erie.cs.uoguelph.ca> <20110117005524.GA1305@michelle.cdnetworks.com> <20110118.093804.74673434.sthaug@nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i 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 Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 00:22:34 -0000 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. > Ronald.