Hi Helin, > On 11 Jan 2017, at 09:08, Zhang, Helin <helin.zh...@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? Best regards, Christos Ricudis > > Regards, > Helin > > -----Original Message----- > From: Olivier MATZ [mailto:olivier.m...@6wind.com] > Sent: Tuesday, January 10, 2017 11:29 PM > To: Christos Ricudis <ricudis.chris...@gmail.com> > Cc: dev@dpdk.org; Zhang, Helin <helin.zh...@intel.com>; Wu, Jingjing > <jingjing...@intel.com> > Subject: Re: [dpdk-dev] i40e_aq_get_phy_capabilities() fails when using SFP+ > with no link > > Hi Christos, > > +CC i40e maintainers > > On Tue, 10 Jan 2017 20:32:26 +0800, Christos Ricudis > <ricudis.chris...@gmail.com> wrote: >> Hello, >> >> Using a X710 based 4-port 4x10Gbit NIC, I have came across the >> following issue on the i40e PMD: >> >> When an optical SFP+ (Finisar FTLX8571D3BCL) is used with no active >> link partner on the other end of the link (or fiber completely >> disconnected from the SFP+), i40e_aq_get_phy_capabilities() (called by >> i40e_dev_sync_phy_type() on port initialization), fails with a >> 0x05 return value (EIO) on the AQ response structure. The struct >> i40e_aq_get_phy_abilities_resp buffer passed to the Get Phy Abilities >> command is unmodified upon return. >> >> This prevents DPDK 16.11 from initializing the port, and ultimately >> fails with the following error: >> >> PMD: eth_i40e_dev_init(): Failed to sync phy type: -95 >> >> The change introducing this issue was >> http://dpdk.org/ml/archives/dev/2016-September/047663.html >> >> Reading the X710 datasheet, I notice that no specific mention is given >> on the meaning of EIO as a response to Get PHY Abilities command >> (opcode 0x0600), whereas in most other commands, an explicit mention >> of the meaning of the possible error status responses is given. >> >> This behaviour is the same across the following NVM releases: >> >> FW 4.33 API 1.2 NVM 04.04.02 eetrack 800018a6 FW 4.40 API 1.4 NVM >> 04.05.03 eetrack 80001cd8 FW 5.0 API 1.5 NVM 05.00.04 eetrack 800024da >> >> I will try to get around the issue by falling back to PHY capabilities >> detection using the device ID in the case >> i40e_aq_get_phy_capabilities() fails, but conceptually the >> capabilities of the PHY should not be dependent on whether PHY detects >> an active link or not. >> >> I’d be happy to do more testing on this issue per your >> recommendations. >> >> Moreover, while trying to debug this issue, I managed to get both 3 >> NIC adapters on my test system on a state where the PHY has apparently >> died - no link indication at all on any ports. A reboot solved this, >> and I am now trying to replicate this behaviour under more controlled >> conditions. >> > > I'm currently running into a similar issue (I think). I can reproduce it with > testpmd with the following case: > > set link_check off > port stop 0 > # don't wait between these 2 commands > port start 0 > > I added some logs that are displayed after the port start: > > PMD: i40e_set_tx_function(): Vector tx finally be used. > PMD: i40e_set_rx_function(): Vector rx enabled, please make sure RX > burst size no less than 4 (port=0). > PMD: i40e_dev_rx_queue_start(): >> > PMD: i40e_dev_tx_queue_start(): >> > PMD: i40e_dev_start(): applying link settings... > PMD: i40e_apply_link_speed(): abilities = 38, speed = 0 > PMD: i40e_phy_conf_link(): i40e_aq_get_phy_capabilities failed -7 > PMD: i40e_dev_start(): Fail to apply link setting > PMD: i40e_dev_clear_queues(): >> > > The -7 corresponds to I40E_ERR_UNKNOWN_PHY. This happens in > i40e_aq_get_phy_capabilities() in the following code, which makes me think > it's the same problem than yours: > > if (hw->aq.asq_last_status == I40E_AQ_RC_EIO) > status = I40E_ERR_UNKNOWN_PHY; > > A workaround in my usecase is to wait a bit between the stop and the start. > > Any help is welcome. > > Regards, > Olivier > >
