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...
cheers
luigi
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
