Date: Wed, 23 Apr 2003 14:17:22 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: truckman@FreeBSD.org (Don Lewis) Cc: freebsd-net@FreeBSD.org Subject: Re: fxp/82550 bug (was Re: IP fragmentation disagreement between current and stable) Message-ID: <20030423211722.D81BF37B401@hub.freebsd.org> In-Reply-To: <200304230710.h3N7AmXB028560@gw.catspoiler.org> from Don Lewis at "Apr 23, 2003 00:10:48 am"
next in thread | previous in thread | raw e-mail | index | archive | help
>
> > 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.)
> I did some digging in the fxp driver, and now I think it's a chip bug
> that is being triggered by the -current fxp driver, which attempts to
> use some more advanced features of the 82550. I found this suspicious
> comment in the code:
>
> /*
> * XXX The 82550 chip appears to have trouble
> * dealing with IP header checksums in very small
> * datagrams, namely fragments from 1 to 3 bytes
> * in size. For example, say you want to transmit
> * a UDP packet of 1473 bytes. The packet will be
> * fragmented over two IP datagrams, the latter
> * containing only one byte of data. The 82550 will
> * botch the header checksum on the 1-byte fragment.
> * As long as the datagram contains 4 or more bytes
> * of data, you're ok.
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.
> * The following code attempts to work around this
> * problem: if the datagram is less than 38 bytes
> * in size (14 bytes ether header, 20 bytes IP header,
> * plus 4 bytes of data), we punt and compute the IP
> * header checksum by hand. This workaround doesn't
> * work very well, however, since it can be fooled
> * by things like VLAN tags and IP options that make
> * the header sizes/offsets vary.
> */
>
> The code it mentions is inside a #ifdef block that is not enabled.
It's not enabled because, as the comment says, I didn't think it was
such a great idea. I also didn't fully understand the cause or nature
of the failure, so I chose to switch off the TX IP checksumming entirely
and leave the code/comment there so people could understand my
rationale (or lack thereoff :).
> I think the problem is worse than mentioned above. I attempted to
> totally disable hardware checksumming with some surgery to the code
> (because the fxp driver doesn't appear to support the ifconfig run time
> knobs for this), but even with hardware checksumming disabled, the final
> fragment was still bad.
On transmit, you have to map all the buffers that comprise a packet
into an array of pointer/length pairs. I *think* the chip computes the
total frame length by adding up these buffer sizes. It's possible one
of them is getting stomped in certain circumstances. On the other hand,
if we're setting them correctly and the chip is getting them wrong,
then... uh... I'm not quite sure what to do.
In any case, I need to check into this a bit more.
-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."
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030423211722.D81BF37B401>