Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 9B8hNyZPHet4vKfDe/Olr6q56o4FVx++38mbSwfq8TlBqSsiL2Nx11ba5zSYdzU4/+jtIH1ZcY
 yNIOCQX013Ig==
IronPort-SDR: uWwFLGQTAYKeaMt97OS8jhqfbu7YoLLp991/raMTzw/nfTgf1qCTL1oSFXggQ85Rixx26VfEdB
 dq/epV0Eg76g==
From:   "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>
To:     xiao <534535881@qq.com>, "xiao33522@qq.com" <xiao33522@qq.com>,
        "Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
        "Nguyen, Anthony L" <anthony.l.nguyen@intel.com>
CC:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        xiaolinkui <xiaolinkui@kylinos.cn>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "davem@davemloft.net" <davem@davemloft.net>
Subject: RE: [Intel-wired-lan] [PATCH] i40e: The state of phy may not be
 correct during power-on
Thread-Topic: [Intel-wired-lan] [PATCH] i40e: The state of phy may not be
 correct during power-on
Thread-Index: AQHXLUs+VWmh6nM5fUSVYn6hAWVkL6qsfJ4wgAU6zQCAAUX2AA==
Date:   Tue, 13 Apr 2021 21:33:00 +0000
Message-ID: <MN2PR11MB466465F88C02C85A4A45202F9B4F9@MN2PR11MB4664.namprd11.prod.outlook.com>
References: <tencent_A3F0B1FAA65495EB2220B5B72EB6E5AF1B07@qq.com>
 <DM6PR11MB4657EB5A8040E7D5A9CB155E9B739@DM6PR11MB4657.namprd11.prod.outlook.com>
 <tencent_AAC300E9BCF5B21D7C99816BD69FA56E5D0A@qq.com>
In-Reply-To: <tencent_AAC300E9BCF5B21D7C99816BD69FA56E5D0A@qq.com>
Accept-Language: pl-PL, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ea53712b-3c54-4e0a-94d4-08d8fec3b650
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2021 21:33:00.3269
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: j8fp9sShfpTZvP74jVEvc6/s8ujMZOnzuGvOKlu0wzJyxBon4DNd2vaxS6chWB/AEQu2oth2jbcNXNzJkjYniSiDVlYgKgsT1x3Kzo7n3p8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4663
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>On 4/10/21 2:12 AM, Kubalewski, Arkadiusz wrote:
>>> -----Original Message-----
>>> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of=
 xiao33522@qq.com
>>> Sent: pi=B1tek, 9 kwietnia 2021 11:18
>>> To: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L <=
anthony.l.nguyen@intel.com>
>>> Cc: netdev@vger.kernel.org; xiaolinkui <xiaolinkui@kylinos.cn>; linux-k=
ernel@vger.kernel.org; intel-wired-lan@lists.osuosl.org; kuba@kernel.org; d=
avem@davemloft.net
>>> Subject: [Intel-wired-lan] [PATCH] i40e: The state of phy may not be co=
rrect during power-on
>>>
>>> From: xiaolinkui <xiaolinkui@kylinos.cn>
>>>
>>> Sometimes the power on state of the x710 network card indicator is not =
right, and the indicator shows orange. At this time, the network card speed=
 is Gigabit.
>> By "power on state" you mean that it happens after power-up of the serve=
r?
>Yes, it means that sometimes the boot state of the server is still in=20
>the BIOS boot stage, and the network card indicator is wrong(orange=20
>indicator).
>

I am still confused a little bit, at that point (before proper link is esta=
blished)
the NIC is supposed to be in so called pxe-mode. Which allows for some basi=
c
functionality. I wonder are you sure it happens "sometimes"? I would say th=
is
behavior is expected after each Power-Off-Reset of the host.

>>
>>> After entering the system, check the network card status through the et=
htool command as follows:
>>>
>>> [root@localhost ~]# ethtool enp132s0f0
>>> Settings for enp132s0f0:
>>> 	Supported ports: [ FIBRE ]
>>> 	Supported link modes:   1000baseX/Full
>>> 	                        10000baseSR/Full
>>> 	Supported pause frame use: Symmetric
>>> 	Supports auto-negotiation: Yes
>>> 	Supported FEC modes: Not reported
>>> 	Advertised link modes:  1000baseX/Full
>>> 	                        10000baseSR/Full
>>> 	Advertised pause frame use: No
>>> 	Advertised auto-negotiation: Yes
>>> 	Advertised FEC modes: Not reported
>>> 	Speed: 1000Mb/s
>>> 	Duplex: Full
>>> 	Port: FIBRE
>>> 	PHYAD: 0
>>> 	Transceiver: internal
>>> 	Auto-negotiation: off
>>> 	Supports Wake-on: d
>>> 	Wake-on: d
>>> 	Current message level: 0x00000007 (7)
>>> 			       drv probe link
>>> 	Link detected: yes
>>>
>>> We can see that the speed is 1000Mb/s.
>>>
>>> If you unplug and plug in the optical cable, it can be restored to 10g.
>>> After this operation, the rate is as follows:
>>>
>>> [root@localhost ~]# ethtool enp132s0f0
>>> Settings for enp132s0f0:
>>>         Supported ports: [ FIBRE ]
>>>         Supported link modes:   1000baseX/Full
>>>                                 10000baseSR/Full
>>>         Supported pause frame use: Symmetric
>>>         Supports auto-negotiation: Yes
>>>         Supported FEC modes: Not reported
>>>         Advertised link modes:  1000baseX/Full
>>>                                 10000baseSR/Full
>>>         Advertised pause frame use: No
>>>         Advertised auto-negotiation: Yes
>>>         Advertised FEC modes: Not reported
>>>         Speed: 10000Mb/s
>>>         Duplex: Full
>>>         Port: FIBRE
>>>         PHYAD: 0
>>>         Transceiver: internal
>>>         Auto-negotiation: off
>>>         Supports Wake-on: d
>>>         Wake-on: d
>>>         Current message level: 0x00000007 (7)
>>>                                drv probe link
>>>         Link detected: yes
>>>
>>> Calling i40e_aq_set_link_restart_an can also achieve this function.
>>> So we need to do a reset operation for the network card when the networ=
k card status is abnormal.
>> Can't say much about the root cause of the issue right now,
>> but I don't think it is good idea for the fix.
>> This leads to braking existing link each time
>> i40e_aq_get_link_info is called on 1 Gigabit PHY.
>> For example 'ethtool -m <dev>' does that.
>>
>> Have you tried reloading the driver?
>> Thanks!
> I tried to unload the driver again and then load the driver, but it didn'=
t work.If I pull the fiber optic cable off and plug it in, it can be recove=
red from 1000Mb/s to 10000Mb/s.
>

Well, it is at least strange for me.

Since on driver load there is already a call to:
	i40e_aq_set_link_restart_an(hw, true, NULL);
Although, in order to be called you need to have up to date Firmware of=20
your NIC. Maybe this is the case? Have you tried to update NVM of the NIC?

Another way would be to use link-down-on-close feature.
First enable link-down-on-close private flag, and then
perform link-down and link-up on the port.

Anyway I don't think this patch is fixing anything, it looks like a workaro=
und
that hides actual problem.

Thanks

>>> Signed-off-by: xiaolinkui <xiaolinkui@kylinos.cn>
>>> ---
>>> drivers/net/ethernet/intel/i40e/i40e_common.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c b/drivers/ne=
t/ethernet/intel/i40e/i40e_common.c
>>> index ec19e18305ec..dde0224776ac 100644
>>> --- a/drivers/net/ethernet/intel/i40e/i40e_common.c
>>> +++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
>>> @@ -1866,6 +1866,10 @@ i40e_status i40e_aq_get_link_info(struct i40e_hw=
 *hw,
>>> 	hw_link_info->max_frame_size =3D le16_to_cpu(resp->max_frame_size);
>>> 	hw_link_info->pacing =3D resp->config & I40E_AQ_CONFIG_PACING_MASK;
>>>
>>> +	if (hw_link_info->phy_type =3D=3D I40E_PHY_TYPE_1000BASE_SX &&
>>> +	    hw->mac.type =3D=3D I40E_MAC_XL710)
>>> +		i40e_aq_set_link_restart_an(hw, true, NULL);
>>> +
>>> 	/* update fc info */
>>> 	tx_pause =3D !!(resp->an_info & I40E_AQ_LINK_PAUSE_TX);
>>> 	rx_pause =3D !!(resp->an_info & I40E_AQ_LINK_PAUSE_RX);
>>> --
>>> 2.17.1
>>>
>>> _______________________________________________
>>> Intel-wired-lan mailing list
>>> Intel-wired-lan@osuosl.org
>>> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>>>