Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Mar 2010 12:23:18 -0700
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        powerpc@FreeBSD.org, embedded@FreeBSD.org, nwhitehorn@FreeBSD.org
Subject:   Re: Anyone using BOOTP with latest current (Book-E)?
Message-ID:  <E210061E-5EE8-42C9-9B20-9788AB6F836B@mac.com>
In-Reply-To: <20100323.094126.787670930724128348.imp@bsdimp.com>
References:  <B7BAFA66-33DF-4EAB-835D-50BEEF7919D0@mac.com> <4BA8CF0E.50201@freebsd.org> <20100323.094126.787670930724128348.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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?

-- 
Marcel Moolenaar
xcllnt@mac.com






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E210061E-5EE8-42C9-9B20-9788AB6F836B>