On Tue, Jan 11, 2005 at 07:36:56AM -0500, Neil Horman wrote: > 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. It seems they do not match: failing: MAC_RX_MODE[00000002] working: MAC_RX_MODE[00000102] So this would point to a driver bug. To search for that, I added a printk at each write to MAC_RX_MODE to see what is being set up. Every call was fine, the last always being 0x102. Would it be possible that the buggy hardware itself resets this register after a link change or something? The following workaround patch made the problem disappear: --- tg3.c~ 2005-01-11 12:30:21.000000000 +0100 +++ tg3.c 2005-01-11 12:30:21.000000000 +0100 @@ -2803,6 +2803,8 @@ sblk->status = SD_STATUS_UPDATED | (sblk->status & ~SD_STATUS_LINK_CHG); tg3_setup_phy(tp, 0); + tw32_f(MAC_RX_MODE, tp->rx_mode); + udelay(10); } } So if I reset the rx_mode after the card has reported a link change, promisc works fine. This workaround works on both machines, one having rev 4001 cards, the other having rev 2003's. Greg - : 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
