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>
index | next in thread | previous in thread | raw e-mail
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?
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100323230351.GI1278>