Re: [Bridge] Re: tg3 bridge problems

[Gergely Madarasz <gorgo@broadband.hu>]

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