From owner-freebsd-stable@FreeBSD.ORG Thu May 8 12:23:36 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA1E937B401 for ; Thu, 8 May 2003 12:23:36 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17D1C43FBD for ; Thu, 8 May 2003 12:23:34 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9/8.12.9) with ESMTP id h48JNNM7035986; Thu, 8 May 2003 12:23:28 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200305081923.h48JNNM7035986@gw.catspoiler.org> Date: Thu, 8 May 2003 12:23:23 -0700 (PDT) From: Don Lewis To: matt@hasta.se In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: stable@FreeBSD.org cc: hrs@eos.ocn.ne.jp Subject: Re: NFS problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 19:23:37 -0000 On 8 May, Matt Douhan wrote: > The problem is that certain-sized fragmented packets get truncated by > the card when the card is programmed in a mode to use some new features > that this particular Ethernet chip has available. In the short term, > the solution to your problem is to patch your copy of the fxp driver so > that this chip is treated like an older model. If you can't do that, > then change your NFS mount options to use TCP, which will avoid the > packet fragmentation. > > > We already use TCP for the NFS mounts and I still see the exact same > problems I only saw the problem on packets that were broken into three or more fragments, but I don't know why it couldn't happen with two fragments, as in the case at the start of this thread, or possibly even with an unfragmented packet in the bad range of sizes. If you're not doing VLANs, try pinging from client to server with packets of size 216+(N*1480): ping -c 216 ping -c 1696 ping -c 3176 ping -c 4656 When you trigger the bug, you won't get a response, and the ip "fragments dropped after timeout" counter in the "netstat -s" statistics will increment, at least in the case of fragmented packets. If you sniff the wire with tcpdump, you'll see the "truncated-ip" message. On the broken machine, the tcpdump output will look normal because tcpdump is capturing the packets before they are corrupted by the NIC. I didn't see any problems until I hit the third size. If you are affected by this bug, please document the hardware involved, including the exact chip part number if possible, the pciconf -l output, and which version of the fxp driver you are using.