From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 23 23:27:40 2010 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8E0A106564A; Tue, 23 Mar 2010 23:27:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id E92F38FC0A; Tue, 23 Mar 2010 23:27:39 +0000 (UTC) Received: by bwz8 with SMTP id 8so616731bwz.3 for ; Tue, 23 Mar 2010 16:27:38 -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=M7MH0+oJ1NrXp9OIjNlln6fI/ewU8fRwW7/6r3alFJU=; b=CFVY++oBISCbJHnrrqYhbJtit5YGFbhKhXTjMeAGNZWIp7YL1B9Y/M2elXiOTp/IxX ynjxlVUWlnqewfM3wrAOqZUSijj55crdb3+vVGYmQ69jKn51fuRluuzy3tgGH8dvvgJv dsAxFbMtmSo4Q8mloDUfjCNN2UkxvWRMlVGG0= 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=TC9IJk4Oc57F94KzDlK9RxYEacLHFA69pckkax7TAb3b4qAagvEXtjZ+3xks9TDANp a8O/gvLqmYgDP8EIQj8R5OD9mv2TRfQsNRwaGJ+FEb6aD3O8/1ApI3imtutor2nNcgJj 4a5i4aQtnQ+6wJE6Fzl3YFL7NoZGBY4yzgN1k= Received: by 10.204.38.71 with SMTP id a7mr3768969bke.159.1269385460324; Tue, 23 Mar 2010 16:04:20 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 16sm2641773bwz.9.2010.03.23.16.04.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 16:04:18 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 23 Mar 2010 16:03:51 -0700 From: Pyun YongHyeon Date: Tue, 23 Mar 2010 16:03:51 -0700 To: Marcel Moolenaar Message-ID: <20100323230351.GI1278@michelle.cdnetworks.com> References: <4BA8CF0E.50201@freebsd.org> <20100323.094126.787670930724128348.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: powerpc@freebsd.org, embedded@freebsd.org, nwhitehorn@freebsd.org Subject: Re: Anyone using BOOTP with latest current (Book-E)? X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:27:41 -0000 On Tue, Mar 23, 2010 at 12:23:18PM -0700, Marcel Moolenaar wrote: > > On Mar 23, 2010, at 8:41 AM, M. Warner Losh wrote: > > : > 192.168.4.1:/net/powerpc Adjusted interface tsec0 > > : > krpc_call: sosend: 65 > > : > krpc_call: sosend: 65 > > : > panic: nfs_boot: mountd root, error=65 > > : > KDB: enter: panic > > : > [ thread pid 0 tid 100000 ] > > : > Stopped at kdb_enter+0x60: addi r0, r0, 0x0 > > : > db> bt > > : > Tracing pid 0 tid 100000 td 0xc0450360 > > : > 0xc2008ae0: at panic+0x13c > > : > 0xc2008b40: at bootpc_init+0x1910 > > : > 0xc2008c20: at mi_startup+0x11c > > : > 0xc2008c50: at __start+0x140 > > : > > > : > BTW: error 65 is EHOSTUNREACH, which I think is caused by a link flag. > > : > > > : This might be a tsec(4) issue, maybe from the recent link-state > > : reporting changes? I netbooted some Book-S machines over bm(4) and > > : gem(4) without incident yesterday, so the issue is probably > > : hardware-specific. > > > > You might try the following hack in route.h: > > > > Index: route.h > > =================================================================== > > --- route.h (revision 205300) > > +++ route.h (working copy) > > @@ -319,8 +319,7 @@ > > > > #ifdef _KERNEL > > > > -#define RT_LINK_IS_UP(ifp) (!((ifp)->if_capabilities & IFCAP_LINKSTATE) \ > > - || (ifp)->if_link_state == LINK_STATE_UP) > > +#define RT_LINK_IS_UP(ifp) (1) > > > > #define RT_LOCK_INIT(_rt) \ > > mtx_init(&(_rt)->rt_mtx, "rtentry", NULL, MTX_DEF | MTX_DUPOK) > > > > Thanks Warner. > > 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. I think it's not common to take more than 40 seconds to establish link. Have you ever tried enabling NEXT PAGE bit of ANAR?