Hi, Thank you very much for your help and your reactivity! See my answer bellow:
> 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? I called that a regression because we still pass through the function phy_ethtool_sset(), which I though was also doing something about the auto-negotiation. But apparently not. > > > 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? Unfortunately no, it does not. I tried many things with ethtool, but it never gets back. > > 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> . As you suggested, I just set these three flags when the function is called with "enable" set to 0. And it works! Actually, I did not even have to set autoneg to off. When the module is probed, the default param are applied (mvneta_defaults_set()), and mvneta_set_autoneg() is called with "enable" to 0, and it seems to fix everything. I tested it then, by setting autoneg to off/on, booting with or without the cable plugged, and I failed to break it. It seems to be fixed. Should I submit a patch? (would be the first time...) Again, thanks a lot for your help.
