Re: i.MX28 based system losing eth0 on boot

[Brian Lilly]

It is happening during boot up:

<snip, kernel 3.12 >

Configuring network interfaces... [   35.117114] fec 800f0000.ethernet
eth0: Freescale FEC PHY driver [SMSC LAN8710/LAN8720]
(mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
[   35.129967] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
udhcpc (v1.21.1) started

Sending discover...

[   37.113901] libphy: 800f0000.etherne:00 - Link is Up - 100/Full
[   37.120134] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending discover...

Sending select for 10.10.10.217...
Lease of 10.10.10.217 obtained, lease time 86400
/etc/udhcpc.d/50default: Adding DNS 10.10.10.13
[   39.319957] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
done.
Starting rpcbind daemon...done.
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
Mon Apr 14 22:40:00 UTC 2014
INIT: Entering runlevel: 5
Starting Xserver
Starting system message bus: dbus.
Starting Connection Manager
Starting wpa_supplicant
Successfully initialized wpa_supplicant
Starting Dropbear SSH server
[   44.754915] fec 800f0000.ethernet eth0: Freescale FEC PHY driver
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
[   45.781364] fec 800f0000.ethernet eth0: MDIO read timeout
[   46.826170] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   47.811385] fec 800f0000.ethernet eth0: MDIO read timeout

With a different kernel (3.14):

[   28.989897] fec 800f0000.ethernet eth0: Freescale FEC PHY driver
[Generic PHY] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
[   30.991210] libphy: 800f0000.etherne:00 - Link is Up - 100/Full
[   37.369372] fec 800f0000.ethernet eth0: Freescale FEC PHY driver
[Generic PHY] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
[   38.398346] fec 800f0000.ethernet eth0: MDIO read timeout
[   39.438412] fec 800f0000.ethernet eth0: MDIO read timeout
[   39.468419] fec 800f0000.ethernet eth0: MDIO write timeout
[   40.498848] fec 800f0000.ethernet eth0: MDIO read timeout

Afterward I have to ifdown eth0, ifup eth0 and then it functions
normally, without reverting the commit.

root@cfa100xx:~# ifdown eth0
[ 1154.679658] fec 800f0000.ethernet eth0: Freescale FEC PHY driver
[Generic PHY] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
root@cfa100xx:~# ifup eth0
udhcpc (v1.21.1) started
Sending discover...
[ 1156.679547] libphy: 800f0000.etherne:00 - Link is Up - 100/Full
Sending discover...
Sending select for 10.10.10.217...
Lease of 10.10.10.217 obtained, lease time 86400
ip: RTNETLINK answers: File exists

--
Brian


On Tue, May 6, 2014 at 11:11 AM, Uwe Kleine-KÃnig
<u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
> Hello Brian,
>
> On Tue, May 06, 2014 at 09:44:34AM -0700, Brian Lilly wrote:
>> With commit a264b981f2c76e281ef27e7232774bf6c54ec865 we're having eth0
>> come up, then brought right back down with an MDIO rx timeout moments
>> after.  Adding back in the removed code keeps the interface alive and
>> it's working afterward without trouble.  I've tested the re-inserted
>> code in 3.12, 3.14 without issue on our boards.
> So you can reliably trigger that problem? You're just doing
>
>         ifconfig eth0 1.2.3.4 up
>
> (or equivalent) and the interface goes down without further
> interference with the above mentioned commit? The exact error you're
> seeing is
>
>         MDIO read timeout
>
> (with some prefix saying something about fec and eth0 I think)?
>
> This error is also present with a264b981f2 reverted, just doesn't affect
> eth0 being functional? Does the timeout always happen, or only on
> specific addresses?
>
> This is not a proper fix, but does it help to increment FEC_MII_TIMEOUT?
>
>> Is there something else that can be done to prevent the MDIO timeouts?
>> We are using basically the same schematic for networking as the
>> imx28evk.
> Hard to say, but assuming it works just fine on the imx28evk for you,
> too, there seems to be some hardware difference that makes your machine
> fail. (That doesn't mean it's not fixable in software.)
>
> I don't know if a mdio read error is intended to make the device go
> down, maybe one the the netdev guys can answer that.
> Assuming that it's not intended, instrument the code, find out how that
> timeout makes your device go down and find the wrong branch. I'd start
> with adding stackdumps when the mdio timeout happens and when
> fec_enet_start_xmit is called with fep->link == 0.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.                           | Uwe Kleine-KÃnig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/