From owner-freebsd-ppc@FreeBSD.ORG Wed Mar 24 00:39:21 2010 Return-Path: Delivered-To: powerpc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C832106564A; Wed, 24 Mar 2010 00:39:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id B957E8FC16; Wed, 24 Mar 2010 00:39:20 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id d26so491775eyd.9 for ; Tue, 23 Mar 2010 17:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=0WUxWINV3ZZknAQXaSfbqzqLkoaMkaLBqf9ZMVhGa5c=; b=AIPTXfCaGnzZZJJn0RNXaMMKC8yDYqBKiRr4F6BC0wKn9kNpQlTSif6LWgoekHlXrD WAmddE3ycyS7HFimHBCTcj12gAo/R4GRoYjdtqZqwTdKpphcLD5CCPtqRbTlXwm3AyeB CS+BhidIXjY0v4wXlOUtSl9lST1+7iIh4Ng98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=KP/JS+A2w6Y13uKfxqCFkDSQWVlAWetDZioBXw7mS4GncwzzthG0eBgyStHq22/pyu SMpBN1YTanolo/M9K4swnJZK/+RCZmks14djo0Ot1WrLsrbIyM3K31tlwH6kSdsYmJ5h gytE+kCm4zOq5Ii76Pf/o3tDHFgGSqD8lVBNI= Received: by 10.213.68.203 with SMTP id w11mr1444829ebi.43.1269391159467; Tue, 23 Mar 2010 17:39:19 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 16sm866566ewy.15.2010.03.23.17.39.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 17:39:18 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 23 Mar 2010 17:38:46 -0700 From: Pyun YongHyeon Date: Tue, 23 Mar 2010 17:38:46 -0700 To: Marcel Moolenaar Message-ID: <20100324003846.GK1278@michelle.cdnetworks.com> References: <4BA8CF0E.50201@freebsd.org> <20100323.094126.787670930724128348.imp@bsdimp.com> <20100323230351.GI1278@michelle.cdnetworks.com> <00BE3C94-8C04-4E00-9617-1DB07C7FAF42@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00BE3C94-8C04-4E00-9617-1DB07C7FAF42@mac.com> User-Agent: Mutt/1.4.2.3i Cc: powerpc@freebsd.org, embedded@freebsd.org, "M. Warner Losh" Subject: Re: Anyone using BOOTP with latest current (Book-E)? X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 00:39:21 -0000 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.