From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 96EF02BB9 for ; Thu, 8 Jun 2017 12:02:19 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2017 03:01:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,314,1493708400"; d="scan'208";a="271721547" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.28]) by fmsmga004.fm.intel.com with SMTP; 08 Jun 2017 03:01:55 -0700 Received: by (sSMTP sendmail emulation); Thu, 08 Jun 2017 11:01:54 +0100 Date: Thu, 8 Jun 2017 11:01:54 +0100 From: Bruce Richardson To: Olivier Matz Cc: helin.zhang@intel.com, jingjing.wu@intel.com, dev@dpdk.org Message-ID: <20170608100154.GA56168@bricha3-MOBL3.ger.corp.intel.com> References: <20170608112917.22fb51eb@platinum> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170608112917.22fb51eb@platinum> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.1 (2017-04-11) Subject: Re: [dpdk-dev] i40e: pci probe fails when using one bogus sfp 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: Thu, 08 Jun 2017 10:02:20 -0000 On Thu, Jun 08, 2017 at 11:29:17AM +0200, Olivier Matz wrote: > Hi, > > One of our customers encounters an issue with dpdk when there > is a bogus SFP on one of the ports. The following message is > reported: > > PMD: eth_i40e_dev_init(): Failed to sync phy type: -95 > > (note: 95 is EOPNOTSUPP/ENOTSUP) > > Unfortunately I cannot reproduce the issue to give more details, > but the hypothesis is that it fails in i40e_dev_sync_phy_type(). > It could be related to that patch: > > http://dpdk.org/browse/dpdk/commit/?id=edfb226f69bf > > To me, the expected behavior should be: > - pci probe is succesful > - the initialization of the port with faulty SFP fails > - the initialization of the other ports is succesful > > Do you have any comment or idea to fix this issue? > And what is the current behaviour you are seeing? The whole PCI probe is terminating after the failure on the error port? Can that one problem port not just be blacklisted, since it's presumably unusable anyway? /Bruce