From owner-freebsd-current@FreeBSD.ORG Thu May 22 23:11:44 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 575C537B401; Thu, 22 May 2003 23:11:44 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB9843F75; Thu, 22 May 2003 23:11:43 -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 h4N6BUM7077910; Thu, 22 May 2003 23:11:35 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200305230611.h4N6BUM7077910@gw.catspoiler.org> Date: Thu, 22 May 2003 23:11:30 -0700 (PDT) From: Don Lewis To: wpaul@FreeBSD.org In-Reply-To: <20030523003333.E83B537B401@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: matt@hasta.se cc: drs@rucus.ru.ac.za cc: hrs@eos.ocn.ne.jp cc: current@FreeBSD.org Subject: Re: possible bug fix for 82550-based fxp packet truncation problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 06:11:44 -0000 On 22 May, Bill Paul wrote: >> Don Lewis wrote >> in <200305220823.h4M8N9M7075271@gw.catspoiler.org>: >> >> truckman> If you are using one of my previous patches which worked around the >> truckman> problem by disabling the IPCB mode, you may want to try the patch below. >> >> This works fine in my environment. My fxp has the following id: >> >> fxp0@pci7:2:0: class=0x020000 card=0x10508086 chip=0x12298086 rev=0x0d hdr=0x00 >> >> Without any patches, packets whose size is 216+(N*1480) are dropped >> as I reported on -stable before. Similarly I tried "ping -s X" with >> various payload size from X=1 to X=6000 in the system using the >> patched kernel, but no error is reported. >> > > Just to let people know, I have been trying to investigate this, but > my time has been somewhat limited lately. The original reason I turned > off the IP checksumming on transmit was that there was one test case > where the chip seemed to be generating improper checksums. That is, > if you did something like: ping -s 1473 . This would result > in a full sized frame, plus a small IP fragment containing just one > byte of data. On the machine I used for testing, the small fragment > was rejected by the host on the other side due to a bad header checksum. According to the second note in the Intel document that I cited, hardware checksumming is unsupported in this case. > The machine I was testing on was an old Gateway 2000 Pentium 166 system. > I have since tried re-enabling the IP checksumming on transmit and > re-run the test on an Athlon system, and everything works correctly. > (Coincidentally, I ran a similar test on a PowerPC 440GP board running > VxWorks and everything worked correctly there too.) > > So my theory is that the original bug I found was not due to the chip > computing bad checksums, although I'm at a loss to say what the cause > really was. And I don't have that particular machine handy anymore. :/ Maybe the stack was fixed to not request hardware IP header checksumming if the card doesn't advertise support for checksumming fragments ... > As an experiment, you might try re-enabling the IP header checksumming to > see just what happens. If the ping -s 1473 tests succeeds, then maybe > I was smoking crack and we should turn IP checksumming back on. Sounds like a good task for after 5.1-RELEASE. I'm just hoping to get the existing driver fixed before 5.1-RELEASE so that it doesn't truncate packets like it currently does.