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 ***************************************************/
