From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) by dpdk.org (Postfix) with ESMTP id 1B859FFA for ; Mon, 6 Feb 2017 22:06:32 +0100 (CET) Received: by mail-it0-f53.google.com with SMTP id 203so63619143ith.0 for ; Mon, 06 Feb 2017 13:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=03BtIpwcwdVGIRLLqV295u9P1/hmDXaHwAg5J2056no=; b=LhVHWDzoEBtD/j7Rm8vZ72EiekiOd0hxNG3Z4Hie9ikn6C378+8EUqwLGp8yTXWOmP mRZZbUitykNXwtZWO5Sgcl4Ua9xZaen7ARs7YKv8IotGFZYKSl3DQjfXlxeuIgpuzGma 5c1Wvjn78EhRCGg94bOiL5+OVoLoTW7+zlondyddcj6I3k5hrh3m9PfKYO0bwFBuVAJV HlzrxR2ItiPhwGRlWLbt+INBUhS452n/6m6LGGKmvS1S+VYxin+WaUSbA+3WyY4+Lvkw +50tJDLPLzWUBsj+7tpLO8Sv1bcxDqK0mRP+oHMxA1/CfNRX54+Zc6HBOo2zDZqFvFIx raDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=03BtIpwcwdVGIRLLqV295u9P1/hmDXaHwAg5J2056no=; b=Dpn6IJ64XyOwL1TBfCzpHa/iJ20OrYp1c28Nw1LtVMMgdKzpBiSoV2w+T4Jacuu4+C wz32aHjXvgLrib+tuQNxwOtzo/9PGwz5tW4fCt+SGUGSIn3AdmnKi+jm+2R2EymdxXoh 3Jkl3+Zp2jk1z6Ne11AVg8WjAKmsh5JdD6czeNMy/pCwoW9wqRtbim6N2qO3vcLzdgqk 1i8I3ja3gtxs18KHu+Tt9vtXXnFt9cTZWeiMRYzx9kDzTayZioS8i1lF6w5MNrGEc1qo PfOUvxStK/MaizQhb/ckw+CADMzV5V6ZhXhx2A5WTgoEKwiGQmimsmGSRlu737swxkPg /xtQ== X-Gm-Message-State: AIkVDXK7nOpyWLm7/7l0GXk6hqWlvQmMZl53cXy1qYsZf5Qf5wckpgC814UG+YMD1UgSFEQ2B6x6HSmCYxO0Sw== X-Received: by 10.36.36.142 with SMTP id f136mr9510524ita.0.1486415191434; Mon, 06 Feb 2017 13:06:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.135.161 with HTTP; Mon, 6 Feb 2017 13:06:00 -0800 (PST) In-Reply-To: <039ED4275CED7440929022BC67E706115305832F@SHSMSX103.ccr.corp.intel.com> References: <2BF7FCC7-B2DF-43EE-B5F8-2F3271FB3DA1@gmail.com> <20170110162849.2256dc6e@glumotte.dev.6wind.com> <1A089981-6412-47FD-A46A-95A958D5E206@gmail.com> <20170112145554.44506d05@glumotte.dev.6wind.com> <7F35F791-2981-47EF-A0B0-3DE4D6E3CF02@gmail.com> <039ED4275CED7440929022BC67E706115305832F@SHSMSX103.ccr.corp.intel.com> From: Ivan Nardi Date: Mon, 6 Feb 2017 22:06:00 +0100 Message-ID: To: "Zhang, Qi Z" Cc: "dev@dpdk.org" , Olivier MATZ , Christos Ricudis , "Rowden, Aaron F" , "Zhang, Helin" , "Wu, Jingjing" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] i40e_aq_get_phy_capabilities() fails when using SFP+ with no link X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 21:06:32 -0000 Thanks for the suggestions! I'll try them and I will report back the results in the next days. Regards Ivan On 6 February 2017 at 02:04, Zhang, Qi Z wrote: > Hi Ivan: > > I'm looking at this issue, but I can't repeat it on my environmen= t both with X710x4 and XL710x1 > Not sure if you could try below things to help narrow down this i= ssue. > > 1) move i40e_dev_sync_phy_type call after i40e_set_fc call, to se= e if the problem still exist, since without i40e_dev_sync_phy_type, i40e_se= t_fc is the first place i40e_aq_get_phy_capabilities get called and we didn= 't see this issue before 16.11. > > 2) if above change works, at least we have a work around, if abov= e still fail, please modify the parameter of i40e_aq_get_phy_capabilities i= n i40e_dev_sync_phy_type as below and check result. > - status =3D i40e_aq_get_phy_capabilities(hw, false, true, &phy_a= b, > - NULL); > + status =3D i40e_aq_get_phy_capabilities(hw, false, false, &phy_= ab, > + NULL); > > Thank you! > > Regards > Qi > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ivan Nardi >> Sent: Monday, February 6, 2017 4:19 AM >> To: dev@dpdk.org >> Cc: Olivier MATZ ; Christos Ricudis >> ; Rowden, Aaron F >> ; Zhang, Helin ; Wu, >> Jingjing >> Subject: Re: [dpdk-dev] i40e_aq_get_phy_capabilities() fails when using = SFP+ >> with no link >> >> HI >> same issue with 17.02-rc2 >> It seems to me the problem I am facing is similar to the ones reported i= n >> these mails; if not, I apologize to have used this thread >> >> Ivan >> >> On 5 February 2017 at 16:30, Ivan Nardi wrote: >> >> > Hi guys >> > any updates on this issue? > >> > We are facing a very similar problem. >> > We have a server with 4 nics X710 4*10Gbit and the dpdk randomly >> > failed to start with the error: >> > >> > PMD: eth_i40e_dev_init(): FW 4.40 API 1.4 NVM 04.05.03 eetrack >> > 80001cd8 >> > PMD: eth_i40e_dev_init(): Failed to sync phy type: -95 >> > >> > It happens randomly (sometimes it works properly, sometimes not), the >> > "failed" port index is random too and it happens whether the fibers >> > have been connected or not. >> > >> > We are using dpdk 16.11. >> > >> > Any help would be appreciated >> > Thanks in advance >> > >> > Ivan >> > >> > On 18 January 2017 at 11:15, Christos Ricudis >> > >> > wrote: >> > >> >> Hi, >> >> >> >> > On 12 Jan 2017, at 21:55, Olivier MATZ >> wrote: >> >> > >> >> > Hi, >> >> > >> >> > On Wed, 11 Jan 2017 20:51:58 +0000, "Rowden, Aaron F" >> >> > wrote: >> >> >> Hi Helin, >> >> >> >> >> >> I'm checking on this to see why it could be failing but I don=E2= =80=99t >> >> >> think this is one part of formal validation. Intel modules are >> >> >> always what is recommended. >> >> >> >> >> >> Aaron >> >> >> >> >> >>> Hi Helin, >> >> >>> >> >> >>>> On 11 Jan 2017, at 09:08, Zhang, Helin >> >> >>>> wrote: >> >> >>>> >> >> >>>> Hi Aaron >> >> >>>> >> >> >>>> Is the SFP+ (Finisar FTLX8571D3BCL) supported and validated by >> >> >>>> Intel? It seems there is some PHY issue in this case. >> >> >>> >> >> >>> As the original reporter of this issue, I will test with >> >> >>> validated >> >> >>> SFP+s and will report on my testing. >> >> >>> >> >> >>> Shouldn=E2=80=99t unsupported SFP+s be blacklisted in the I40E dr= iver? >> >> >>> >> >> > >> >> > Just to let you know that in my case the SFP are Intel ones. >> >> > Maybe it's a different issue. >> >> > >> >> > I see there are some i40e fixes in the net-next repo, I'll give a >> >> > try with this version. >> >> > >> >> > Regards, >> >> > Olivier >> >> >> >> After further testing, I can confirm that this issue persists with >> >> supported Intel SFPs (Intel FTLX8571D3BCV-IT). >> >> >> >> As for the changeset introducing this issue - we had failure reports >> >> with previous DPDK versions, probably related to LSE handling, but >> >> these weren=E2=80=99t properly investigated. The change in 16.11 whic= h calls >> >> get_phy_capability too early in initialization stage might have >> >> alleviated the issue making it easier for us to detect and confirm. >> >> >> >> Best regards, >> >> Christos Ricudis. >> >> >> >> >> >