Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Jan 2004 18:57:14 -0500 (EST)
From:      Robert Watson <rwatson@freebsd.org>
To:        Luigi Rizzo <rizzo@icir.org>
Cc:        hackers@freebsd.org
Subject:   Re: XL driver checksum producing corrupted but checksum-correct packets
Message-ID:  <Pine.NEB.3.96L.1040124185529.62871Q-100000@fledge.watson.org>
In-Reply-To: <20040124151029.A73519@xorpc.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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@fledge.watson.org      Senior Research Scientist, McAfee Research




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040124185529.62871Q-100000>