Re: [Bridge] Re: tg3 bridge problems

[Gergely Madarasz <gorgo@broadband.hu>]

On Tue, Jan 11, 2005 at 08:12:11AM -0500, Neil Horman wrote:
> Gergely Madarasz wrote:
> >On Tue, Jan 11, 2005 at 07:36:56AM -0500, Neil Horman wrote:
> >
> >>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
> 
> I do believe that tg3 driven chips reset the promisc. bit on chip reset, 
> so it may be possible that you have found a driver bug in which the 
> appropriate promiscuous state isn't restored after a reset.  Try adding 
> a printk to tg3_reset to see if it gets called after you follow your 
> non-working procedure, and check to see if the promisc bit in 
> MAC_RX_MODE gets lost.  If so, I'd say thats arguably your bug.

I have now added quite a lot of debugging printk's to tg3.c.
Here is what I see:

eth2: tg3.c(tg3_reset_hw,4946) MAC_RX_MODE: 0006
eth2: tg3.c(tg3_chip_reset,3786) MAC_RX_MODE: 0006
eth2: tg3.c(tg3_chip_reset,3948) MAC_RX_MODE: 0000
eth2: tg3.c(tg3_reset_hw,5413) MAC_RX_MODE: 0002
eth2: tg3.c(tg3_reset_hw,5436) MAC_RX_MODE: 0002
eth2: tg3.c(tg3_setup_phy,2434) MAC_RX_MODE: 0002
eth2: tg3.c(tg3_phy_reset,810) MAC_RX_MODE: 0002
eth2: tg3.c(tg3_phy_reset,868) MAC_RX_MODE: 0002
eth2: tg3.c(tg3_setup_phy,2464) MAC_RX_MODE: 0002
eth2: tg3.c(__tg3_set_rx_mode,6320) MAC_RX_MODE: 0102
eth2: tg3.c(tg3_reset_hw,5530) MAC_RX_MODE: 0102
eth2: tg3.c(tg3_poll,2816) MAC_RX_MODE: 0002

that is the promisc bit is lost after leaving tg3_reset_hw, and before
entering tg3_poll.

Greg