lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 12 Apr 2017 18:54:23 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Tim Harvey <tharvey@...eworks.com>
Cc:     netdev <netdev@...r.kernel.org>,
        Fabio Estevam <fabio.estevam@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Fugang Duan <fugang.duan@....com>,
        Koen Vandeputte <koen.vandeputte@...ntric.com>
Subject: Re: IMX6 FEC connection drops occasionally with 'MDIO read timeout'

On Wed, Apr 12, 2017 at 09:15:11AM -0700, Tim Harvey wrote:
> On Fri, Apr 7, 2017 at 9:09 AM, Andrew Lunn <andrew@...n.ch> wrote:
> > On Fri, Apr 07, 2017 at 07:47:17AM -0700, Tim Harvey wrote:
> >> Greetings,
> >>
> >> I've had a couple of users report that they are getting occasional
> >> link drops when using IMX6 FEC on our boards which are using a Marvell
> >> 88E1510 PHY:
> >>
> >> [ 9348.474418] fec 2188000.ethernet eth0: MDIO read timeout
> >> [ 9350.478804] fec 2188000.ethernet eth0: Link is Down
> >>
> >> If they bring the interface back up it works fine.
> >>
> >> The most recent version of Linux they have tested and seen this on is
> >> v4.9 with CONFIG_MARVELL_PHY=y
> >>
> >> Has anyone else run into this or know what the issue could be? Should
> >> there be any retries at the MDIO level or above?
> >
> > Hi Tim
> >
> > MDIO is assumed to be reliable. It failing is bad.
> >
> > However, ETIMEOUT is interesting. The MDIO protocol has no flow
> > control. There is no way for the PHY to delay replying.
> >
> > I would suggest you look at the power management code. What i have
> > seen with the FEC, when using switches attached to the FEC, is that if
> > the clocks are turned off, you get ETIMEOUT from MDIO.
> >
> >     Andrew
> 
> Andrew,
> 
> Thanks for the reply. Your talking about suspend/resume power
> management right? The users reporting this were not using
> suspend/resume.

Hi Tim

As Fabio just pointed out, i was meaning run time power management.

It used to be, that the FEC driver powered up the clocks when the
interface was opened. But when using a switch connected to the MDIO
bus, you can be using the MDIO bus while the interface is still
closed. And that did not work. So the runtime PM was extended to the
MDIO bus.

It could be there is a race condition in this code somewhere.

   Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ