From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christos Ricudis Subject: i40e_aq_get_phy_capabilities() fails when using SFP+ with no link Date: Tue, 10 Jan 2017 20:32:26 +0800 Message-ID: <2BF7FCC7-B2DF-43EE-B5F8-2F3271FB3DA1@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dev@dpdk.org Return-path: Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com [209.85.192.171]) by dpdk.org (Postfix) with ESMTP id AAA42152A for ; Tue, 10 Jan 2017 13:32:30 +0100 (CET) Received: by mail-pf0-f171.google.com with SMTP id y143so26198910pfb.0 for ; Tue, 10 Jan 2017 04:32:30 -0800 (PST) Received: from ricudismac.niometrics.com ([66.96.194.217]) by smtp.gmail.com with ESMTPSA id e184sm5501961pfc.28.2017.01.10.04.32.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 04:32:29 -0800 (PST) List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hello,=20 Using a X710 based 4-port 4x10Gbit NIC, I have came across the following = issue on the i40e PMD:=20 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.=20 This prevents DPDK 16.11 from initializing the port, and ultimately = fails with the following error:=20 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.=20 This behaviour is the same across the following NVM releases:=20 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.=20 I=E2=80=99d be happy to do more testing on this issue per your = recommendations.=20 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.=20= Best regards,=20 Christos Ricudis.