Date: Tue, 23 Mar 2010 16:03:51 -0700 From: Pyun YongHyeon <pyunyh@gmail.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: powerpc@freebsd.org, embedded@freebsd.org, nwhitehorn@freebsd.org Subject: Re: Anyone using BOOTP with latest current (Book-E)? Message-ID: <20100323230351.GI1278@michelle.cdnetworks.com> In-Reply-To: <E210061E-5EE8-42C9-9B20-9788AB6F836B@mac.com> References: <B7BAFA66-33DF-4EAB-835D-50BEEF7919D0@mac.com> <4BA8CF0E.50201@freebsd.org> <20100323.094126.787670930724128348.imp@bsdimp.com> <E210061E-5EE8-42C9-9B20-9788AB6F836B@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100323230351.GI1278>