fxp/82550 bug (was Re: IP fragmentation disagreement between current and stable)

[Don Lewis]

On 23 Apr, Bill Paul wrote:
>> 
>> > It's starting to smell like a bug in the -current fxp driver.
> 
> Or a bug in the current rev of the fxp chip.
> 
> For the record, it helps to actually identify the chip you have,
> either by looking at the output of pciconf -l, or by looking at the
> chip and making a note of the part number. (I can understand why
> some people don't bother to do this: Intel uses a special silkscreening
> process that makes their part numbers nearly invisible.)

fxp0 at pci0:10:0: class=0x020000 card=0x00508086 chip=0x12298086 rev=0x0d hdr=0x00

82550GY
L107SA39


> I my tests, I didn't observe any problems with larger fragments,
> only with the one case outlined in this comment. I think I may have
> mis-identified the actual bug here. I never noticed any "XX bytes
> missing!" messages from tcpdump when I stumbled across this problem,
> but I think that was because, with my test, even though I was sending
> out only 1 byte of data, I was still generating a 64-byte ethernet
> frame (64 bytes is the minimum frame size). So all I noticed was
> that the IP header checksum was flagged as bad by the receiving
> system.

In case you haven't seen the entire thread, the problem only seems to
occur if the packet is split across three or more fragments.  Ping -s
3175 through 3177 break, as well as those sizes plus N*1480.


I wish knew why these cards aren't visible to the BIOS or the OS after a
power-on cold boot. It's pretty annoying to have to have to either hit
the reset button or long on the console and reboot the OS.  I haven't
seen any other mention of this problem on the net.  At least this isn't
a bug in the fxp driver ...