Gergely Madarasz wrote:
On Tue, Jan 11, 2005 at 02:36:46PM +1030, Paul Schulz wrote:
Greetings,
This may be the problem that I have seen (and reported) previously...
http://oss.sgi.com/projects/netdev/archive/2004-02/msg00442.html
One suggestion.. do a packet dump on an outgoing bridge port, and a
dump from a transmitting machine connected to the bridge. Compare the
MD5 checksums.
Thanks for the idea, but it doesn't seem to help. I've modified the patch
to apply to my chipset revision (and added a debugging printk to make sure
I've hit the right chipset :)), but nothing really changed. I didn't
expect it to either, because this is not a transmit problem, but a
promiscuous receive problem of the driver/card.
Greg
You know, there is a tg3_dump_state function that if 0-ed out at the
moment, which among other things dumps out the chips RX_MODE. You could
uncomment that function and tie it to a private ioctl which you could
call from user space. That way you could compare the RX_MODE values in
a working and a failing environment. If they matched, you could be
reasonably sure it was a hardware issue, otherwise, you would know your
looking for a driver bug.
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@xxxxxxxxxx
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
