Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Jun 2010 10:35:35 -0700
From:      Pyun YongHyeon <pyunyh@gmail.com>
To:        Jakub Klama <jceel@semihalf.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Booting over NFS - PHY autonegotiation issues
Message-ID:  <20100615173535.GF4257@michelle.cdnetworks.com>
In-Reply-To: <5B7858C2-B5BD-48BC-BA5F-D4E81F9E78ED@semihalf.com>
References:  <5B7858C2-B5BD-48BC-BA5F-D4E81F9E78ED@semihalf.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 15, 2010 at 10:00:48AM +0200, Jakub Klama wrote:
> Hi,
> 
> Firstly, this mail was sent to freebsd-embedded@, but with no response,
> so I repost it here.
> 
> We have a problem booting FreeBSD from NFS root after upgrade to newest 
> HEAD on Marvell 88F6281 (using driver mge) and Freescale MPC8572 (using 
> driver tsec). Problem is related to changes in sys/net/route.h
> (RT_LINK_IS_UP macro) and PHY autonegotation, similar to:
> 
> http://lists.freebsd.org/pipermail/freebsd-ppc/2010-March/004134.html
> 
> Here's output from Marvell 88F6281:
> #v+
> (...)
> WARNING: WITNESS option enabled, expect reduced performance.
> WARNING: DIAGNOSTIC option enabled, expect reduced performance.
> Root mount waiting for: usbus0
> uhub0: 1 port with 1 removable, self powered
> Trying to mount root from nfs:10.0.0.201:/nfsroot/mv6281-2/
> krpc_call: sosend: 65
> NFS_ROOT: NFSv3 mount failed (error: 65). Trying NFSv2 ...
> krpc_call: sosend: 65
> nfs_mountroot: md_mount(): 65
> ROOT MOUNT ERROR:
> If you have invalid mount options, reboot, and first try the following from
> the loader prompt:
> 
>      set vfs.root.mountfrom.options=rw
> 
> and then remove invalid mount options from /etc/fstab.
> 
> Trying to mount root from nfs:
> ifaddr cache = 0xc3e18500  is deleted
> nfs_mountroot: RTM_ADD: 17
> ROOT MOUNT ERROR:
> (...)
> #v-
> 
> We've managed changes that prevents restarting autonegotiation and allows
> to boot from NFS correctly, based on investigating other PHY drivers (such
> as rlphy) and mii_phy_setmedia():
> 

I believe rlphy(4) is bad example because its PHY hardware has
peculiar (non-standard) features.

> on Marvell (mge/e1000phy):
> #v+
> --- a/sys/dev/mii/e1000phy.c
> +++ b/sys/dev/mii/e1000phy.c
> @@ -349,7 +349,9 @@ e1000phy_service(struct mii_softc *sc, struct 
> mii_data *mii, int cmd)
>                         break;
>  
>                 if (IFM_SUBTYPE(ife->ifm_media) == IFM_AUTO) {
> -                       e1000phy_mii_phy_auto(esc);
> +                       if ((PHY_READ(sc, MII_BMCR) & BMCR_AUTOEN) == 0 ||
> +                          (sc->mii_flags & MIIF_FORCEANEG))
> +                               e1000phy_mii_phy_auto(esc);
>                         break;
>                 }
> #v-
> 
> and on MPC8572 (tsec/ciphy):
> #v+
> --- a/sys/dev/mii/ciphy.c
> +++ b/sys/dev/mii/ciphy.c
> @@ -176,13 +176,12 @@ ciphy_service(struct mii_softc *sc, struct 
> mii_data *mii, int cmd)
>  
>                 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
> +                               break;
> +
>                         (void) mii_phy_auto(sc);
>                         break;
> #v-
> 
> Is this preferred way to fix this issue?
> 
> Of course, with this fix, manually restarting autonegotiation using
> 'ifconfig mge0 media auto' doesn't work - but it doesn't work also on
> other PHY's (we've tested it on rl/rlphy).
> 

Due to lack of mge(4)/tsec(4) hardwares I'm not completely sure
what is root cause but I'd rather see how mge(4) and tsec(4) handle
link state changes.
It seems mge(4) completely ignores link state changes as well as
missing media configuration in mge_init_locked(). Link state can
change at any time and driver should be prepared to stop/restart
the controller depending on link state. I also guess dhclient(8)
may not work reliably with mge(4) due to lack of link state change
handling.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100615173535.GF4257>