netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Yonglong Liu <liuyonglong@huawei.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linuxarm@huawei.com, Salil Mehta <salil.mehta@huawei.com>
Subject: Re: [question] net: phy: rtl8211f: link speed shows 1000Mb/s but actual link speed in phy is 100Mb/s
Date: Tue, 12 May 2020 16:00:17 +0200	[thread overview]
Message-ID: <20200512140017.GK409897@lunn.ch> (raw)
In-Reply-To: <478f871a-583d-01f1-9cc5-2eea56d8c2a7@huawei.com>

On Tue, May 12, 2020 at 08:48:21PM +0800, Yonglong Liu wrote:
> I use two devices, both support 1000M speed, they are directly connected
> with a network cable. Two devices enable autoneg, and then do the following
> test repeatedly:
> 	ifconfig eth5 down
> 	ifconfig eth5 up
> 	sleep $((RANDOM%6))
> 	ifconfig eth5 down
> 	ifconfig eth5 up
> 	sleep 10
> 
> With low probability, one device A link up with 100Mb/s, the other B link up with
> 1000Mb/s(the actual link speed read from phy is 100Mb/s), and the network can
> not work.
> 
> device A:
> Settings for eth5:
>         Supported ports: [ TP ]
>         Supported link modes:   10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>                                 1000baseT/Full
>         Supported pause frame use: Symmetric Receive-only
>         Supports auto-negotiation: Yes
>         Supported FEC modes: Not reported
>         Advertised link modes:  10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>                                 1000baseT/Full
>         Advertised pause frame use: Symmetric
>         Advertised auto-negotiation: Yes
>         Advertised FEC modes: Not reported
>         Link partner advertised link modes:  10baseT/Half 10baseT/Full
>                                              100baseT/Half 100baseT/Full
>         Link partner advertised pause frame use: Symmetric
>         Link partner advertised auto-negotiation: Yes
>         Link partner advertised FEC modes: Not reported
>         Speed: 100Mb/s
>         Duplex: Full
>         Port: MII
>         PHYAD: 3
>         Transceiver: internal
>         Auto-negotiation: on
>         Current message level: 0x00000036 (54)
>                                probe link ifdown ifup
>         Link detected: yes
> 
> The regs value read from mdio are:
> reg 9 = 0x200
> reg a = 0
> 
> device B:
> Settings for eth5:
>         Supported ports: [ TP ]
>         Supported link modes:   10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>                                 1000baseT/Full
>         Supported pause frame use: Symmetric Receive-only
>         Supports auto-negotiation: Yes
>         Supported FEC modes: Not reported
>         Advertised link modes:  10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>                                 1000baseT/Full
>         Advertised pause frame use: Symmetric
>         Advertised auto-negotiation: Yes
>         Advertised FEC modes: Not reported
>         Link partner advertised link modes:  10baseT/Half 10baseT/Full
>                                              100baseT/Half 100baseT/Full
>                                              1000baseT/Full
>         Link partner advertised pause frame use: Symmetric
>         Link partner advertised auto-negotiation: Yes
>         Link partner advertised FEC modes: Not reported
>         Speed: 1000Mb/s
>         Duplex: Full
>         Port: MII
>         PHYAD: 3
>         Transceiver: internal
>         Auto-negotiation: on
>         Current message level: 0x00000036 (54)
>                                probe link ifdown ifup
>         Link detected: yes
> 
> The regs value read from mdio are:
> reg 9 = 0
> reg a = 0x800
> 
> I had talk to the FAE of rtl8211f, they said if negotiation failed with 1000Mb/s,
> rtl8211f will change reg 9 to 0, than try to negotiation with 100Mb/s.
> 
> The problem happened as:
> ifconfig eth5 up -> phy_start -> phy_start_aneg -> phy_modify_changed(MII_CTRL1000)
> (this time both A and B, reg 9 = 0x200) -> wait for link up -> (B: reg 9 changed to 0)
> -> link up.

This sounds like downshift, but not correctly working. 1Gbps requires
that 4 pairs in the cable work. If a 1Gbps link is negotiated, but
then does not establish because one of the pairs is broken, some PHYs
will try to 'downshift'. They drop down to 100Mbps, which only
requires two pairs of the cable to work. To do this, the PHY should
change what it is advertising, to no longer advertise 1G, just 100M
and 10M. The link partner should then try to use 100Mbps and
hopefully, a link is established.

Looking at the ethtool, you can see device A is reporting device B is
only advertising upto 100Mbps. Yet it is locally using 1G. That is
broken. So i would say device A has the problem. Are both PHYs
rtl8211f?

> I think this is the bug of the rtl8211f itself, any one have an idea
> to avoid this bug?

Are you 100% sure your cable and board layout is good? Is it trying
downshift because something is broken? Fix the cable/connector and the
reason to downshift goes away. But it does not solve the problem if a
customer has a broken cable. So you might want to deliberately cut a
pair in the cable so it becomes 100% reproducable and try to debug it
further. See if you can find out why auto-neg is not working
correctly.

	Andrew

  reply	other threads:[~2020-05-12 14:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-12 12:48 [question] net: phy: rtl8211f: link speed shows 1000Mb/s but actual link speed in phy is 100Mb/s Yonglong Liu
2020-05-12 14:00 ` Andrew Lunn [this message]
2020-05-13  1:34   ` Yonglong Liu
2020-05-13  1:59     ` Andrew Lunn
2020-05-13  3:04       ` Yonglong Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200512140017.GK409897@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=liuyonglong@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=salil.mehta@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).