From owner-freebsd-current@FreeBSD.ORG Thu May 22 17:33:33 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id E83B537B401; Thu, 22 May 2003 17:33:33 -0700 (PDT) In-Reply-To: <20030523.043131.02305993.hrs@eos.ocn.ne.jp> from Hiroki Sato at "May 23, 2003 04:31:31 am" To: hrs@eos.ocn.ne.jp (Hiroki Sato) Date: Thu, 22 May 2003 17:33:33 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20030523003333.E83B537B401@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: truckman@freebsd.org cc: drs@rucus.ru.ac.za cc: matt@hasta.se 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 00:33:34 -0000 > 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. 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. :/ 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. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= "If stupidity were a handicap, you'd have the best parking spot." =============================================================================