[Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R]

[Oleg Bulyzhin]

On Mon, Jan 08, 2007 at 04:33:29PM -0800, John Polstra wrote:
> On 30-Dec-2006 Bruce Evans wrote:
> > More debugging showed that almost any of the reads of the phy in mii
> > cause an input error,
> 
> The errors appear to be caused by the code in bge_miibus_{read,write}reg
> that clears and then restores the BGE_MIMODE_AUTOPOLL bit of the
> BGE_MI_MODE register.  If you remove those chunks of code, the errors
> go away even when mii_tick is called periodically, and the chip
> performs quite well under heavy traffic load in both directions.

I've seen this kind of ierrors (LINK_LOST error flag in rx buffer descriptor)
only on bcm5701 chip. Other chips i tried (5700 and 5721) seems are not
affected.

> 
> I know that some of the *_MODE registers in these chips cause problems
> if they are read, so I tried putting a shadow copy of the register
> into the softc and doing only writes to the hardware register.  But
> that didn't help in this case.
> 
> I seem to recall having heard that Broadcom discourages the use of
> PHY autopolling for unspecified reasons.  The Linux driver from
> Broadcom had code to support it, but it was never actually used for
> any devices.  The current Linux driver uses autopolling only for the
> Altima chip that's present on the inexpensive Netgear GA302T card.

If i remember right, Broadcom recommends using phy interrupts for
tracing link events, though auto-polling noted as alternative method
for that.

> 
> I agree with you that we shouldn't need to call mii_tick periodically,
> except perhaps for a few very old variants of the Broadcom chip.
> 
> John
mii_tick periodic calls are requried -  MII layer use it for link
autonegotiation. Though i guess it's possible to avoid phy access if we
have link up.
I see two different ways to solve this:
1) convert driver for using phy interrupts as default (like linux driver),
   thus BGE_MI_MODE read/write can be avoided.
2) do not touch PHY inside bge_tick() if we have link up. Actually, this
   check was in driver but was removed as workaround of existed link state
   issues (due to some bugs in if_bge.c and brgphy.c link loss events were
   detected with few seconds delay or even not detected at all).
   Those bugs are fixed now, so we can revive this check (bge_link_upd() can
   be simplified a bit too).

-- 
Oleg.

================================================================
=== Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg at rinet.ru ===
================================================================