From owner-freebsd-current@FreeBSD.ORG  Fri May 23 13:35:28 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 8AFF237B401; Fri, 23 May 2003 13:35:28 -0700 (PDT)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id DD3F943F85; Fri, 23 May 2003 13:35:27 -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 h4NKZBM7079385;
	Fri, 23 May 2003 13:35:15 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200305232035.h4NKZBM7079385@gw.catspoiler.org>
Date: Fri, 23 May 2003 13:35:11 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: wpaul@FreeBSD.org
In-Reply-To: <20030523183419.0636037B401@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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2003 20:35:28 -0000

On 23 May, Bill Paul wrote:
>> > 
>> > 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 <otherhost>. 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.
> 
> Argh. No. IP checksumming == a checksum of the IP header only. The
> chip is perfectly capable of computing IP header checksums over
> fragments, and does so quite well, _except_ in this one bizarro case
> I encountered with tiny packets on this single P166 system.

Maybe that was the original intent and hardware bugs were found later.
The Intel document specifically says (emphasis mine):
	Therefore, the driver should not request *any* offload features
        for an IP fragment.