Re: [dpdk-dev] i40e_aq_get_phy_capabilities() fails when using SFP+ with no link

[Ivan Nardi <nardi.ivan@gmail.com>]

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 <ricudis.christos@gmail.com>
wrote:

> Hi,
>
> > On 12 Jan 2017, at 21:55, Olivier MATZ <olivier.matz@6wind.com> wrote:
> >
> > Hi,
> >
> > On Wed, 11 Jan 2017 20:51:58 +0000, "Rowden, Aaron F"
> > <aaron.f.rowden@intel.com> wrote:
> >> Hi Helin,
> >>
> >> I'm checking on this to see why it could be failing but I don’t 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 <helin.zhang@intel.com>
> >>>> 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’t unsupported SFP+s be blacklisted in the I40E driver?
> >>>
> >
> > 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’t
> properly investigated. The change in 16.11 which 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.
>
>