netdev - Re: Problem: net: mvneta: auto-negotiation with disconnected network cable

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c5e143f0-f6b4-ff74-4239-e64ca025821b@list.ru>
Date:   Thu, 23 Mar 2017 00:34:51 +0300
From:   Stas Sergeev <stsp@...t.ru>
To:     Maxime Morin <maxime.morin@...ec.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        "thomas.petazzoni@...e-electrons.com" 
        <thomas.petazzoni@...e-electrons.com>
Subject: Re: Problem: net: mvneta: auto-negotiation with disconnected network
 cable

22.03.2017 16:23, Maxime Morin пишет:
> Hi all,
>
> I work on an embedded platform based on the Marvell Armada 88F6707, that is connected to a Marvell Alaska 88E1512 ethernet transceiver. A defect has appeared recently, and it turns out to be a regression on the network part. There is a complete lost of the network when following these steps:
>      1) boot the board with the network cable disconnected
>      2) run the following commands (or equivalent):
>          ip link set eth0 up
>          ip addr add 10.0.0.80/24 dev eth0
>          ethtool -s eth0 autoneg on #this is the command that really breaks the network
Why do you call it a regression, if previously
this command did nothing at all?

>      3) plug the network cable
>          => there is no network, and no way to have it back except by rebooting
> If I do not launch the "ethtool" command, when I plug the network cable it works, so it really seems to be related to the auto-negotiation set to "on" when the network cable has never been connected.
So if you do that with the cable plugged it, there
is no breakage?
When you do "ethtool -s eth0 autoneg off" it doesn't
revive?

> I did a "git bisect" to find when the regression was introduced, because it previously worked with kernel 4.4, but not with the recent ones. The commit that made appear the issue is this one: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c0744fc1dd5b
> If I remove on mvneta.c the part that was added on this commit on the function mvneta_ethtool_set_link_ksettings (mvneta_ethtool_set_settings at that time), I do not have the issue, but I can't call that a fix...
> So, could it be a driver issue, or maybe a wrong configuration somewhere? If you need additional information to reproduce the problem please ask me, I will be as responsive as possible.
It seems mvneta_set_autoneg() does some non-symmetric
things. It clears
MVNETA_GMAC_FORCE_LINK_PASS |
MVNETA_GMAC_FORCE_LINK_DOWN |
MVNETA_GMAC_AN_FLOW_CTRL_EN
when enabling autoneg, and does not restore these flags
when disabling it. Try to make it to set or to restore these
flags and see if that makes "ethtool -s eth0 autoneg off" to
get the network back alive.