Anyone using BOOTP with latest current (Book-E)?

[Pyun YongHyeon]

On Tue, Mar 23, 2010 at 04:38:40PM -0700, Marcel Moolenaar wrote:
> 
> On Mar 23, 2010, at 4:03 PM, Pyun YongHyeon wrote:
> >> I looked at whether we restart autoneg if the PHY is in autoneg already because
> >> I've seen at Juniper how that can contribute to excessive link flaps and even
> >> excessive autoneg completion times (>40 seconds) depending on the switch and
> >> did this:
> >> 
> >> Index: dev/mii/ciphy.c
> >> ===================================================================
> >> --- dev/mii/ciphy.c	(revision 205451)
> >> +++ dev/mii/ciphy.c	(working copy)
> >> @@ -176,13 +176,11 @@
> >> 
> >> 		switch (IFM_SUBTYPE(ife->ifm_media)) {
> >> 		case IFM_AUTO:
> >> -#ifdef foo
> >> 			/*
> >> 			 * If we're already in auto mode, just return.
> >> 			 */
> >> 			if (PHY_READ(sc, CIPHY_MII_BMCR) & CIPHY_BMCR_AUTOEN)
> >> 				return (0);
> >> -#endif
> >> 			(void) mii_phy_auto(sc);
> >> 			break;
> >> 		case IFM_1000_T:
> >> 
> >> 
> >> Apparently the author already considered the same and it does resolve the issue.
> >> Anyone see any concerns with my applying this patch?
> >> 
> > 
> > I'm not sure but I guess the #ifdef foo block could be completely
> > nuked. The auto-negotiation timeout is set to 17 seconds for
> > gigabit link and ciphy(4) will reprogram BMCR if auto-negotiation
> > was not resolved after that timeout.
> 
> That's besides the point. calling mii_phy_auto() while autoneg is
> ongoing aborts the autoneg and restarts it. This causes a link flap
> and makes some switches cranky.
> 

Correct.
The reason I said that was it took too much time to complete the
auto-negotiation. mii_phy_auto() blindly disables NEXT PAGE bit of
ANAR and some PHYs require NEXT PAGE bit to establish a link.

> What the patch does is to not enable autoneg when autoneg is already
> enabled so that we don't interfere with the autoneg handshake.
> 

Yeah, but it also disables ability to restart auto-negotiation with
"ifconfig tsec0 media auto" command.

If the PHY is buggy I would add a special case not to check the
CIPHY_BMSR_ACOMP bit of BMCR for a give PHY model in auto-negotiation
completion check.

One odd thing in tsec(4) is tsec_miibus_statchg() handling. If
ciphy(4) just reports link UP, tsec(4) still seems to reprogram
TSEC_REG_ECNTRL register. Shouldn't it check link UP state as well
as resolved speed/duplex of link? Also I'm not sure whether tsec(4)
can safely change duplex configuration when MAC is in
enabled/active state.