XL driver checksum producing corrupted but checksum-correct packets

[Robert Watson]

On Sat, 24 Jan 2004, Luigi Rizzo wrote:

> On Sat, Jan 24, 2004 at 02:12:12PM -0500, Robert Watson wrote:
> ...
> > > but going this way you have no idea on what the driver does, including
> > > enabling hw checksums. This looks like a useless test at least for the
> > > purpose of finding out what is going wrong
> > 
> > Actually, I'm more curious about whether it's a known errata/misbehavior
> > for the card that 3Com's drivers work around, or not.  The problem could
> > well be compleely unrelated to hardware checksuming per se -- the
> > corruption might well be taking place as the buffer is moved from the
> > card's buffer to the operating system managed buffer.  If the NDIS driver
> > doesn't illustrate the same problem, it tells us that by frobbing
> > appropriately, this problem can be worked around.  It also tells us that
> > by looking a bit harder at what the driver is doing (i.e., how it frobs
> > the hardware), we can learn something about the appropriate workaround. 
> 
> yes, but how would you know that, short of reverse engineering the
> driver, or tracing I/O accesses to the hardware ?  It really looks like
> an overkill effort... I'd rather just try to debug the issue working on
> an open source driver, or dump the hardware altogether and replace it
> with something known to work... 

My understanding is that NDIS drivers rely on the HAL provided by NT to
perform hardware access, so you can generate I/O traces with relative
ease.  Decoding and following the HAL traces during card setup is probably
relatively straight forward, since presumably most of the I/O transactions
will match the documented services of the card.  It might be useful to add
some KTR support to Bill's NDIS pieces for this very purpose, if there's
interest.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research