possible bug fix for 82550-based fxp packet truncation problem

[Don Lewis]

On 22 May, Bill Paul wrote:
>> Don Lewis <truckman at freebsd.org> wrote
>>   in <200305220823.h4M8N9M7075271 at 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 at 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 <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.

> 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.