From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0088.outbound.protection.outlook.com [157.56.111.88]) by dpdk.org (Postfix) with ESMTP id C06D15A32 for ; Thu, 15 Oct 2015 19:13:37 +0200 (CEST) Received: from SN2PR0601MB1007.namprd06.prod.outlook.com (10.160.59.154) by SN2PR0601MB1007.namprd06.prod.outlook.com (10.160.59.154) with Microsoft SMTP Server (TLS) id 15.1.300.14; Thu, 15 Oct 2015 17:13:33 +0000 Received: from SN2PR0601MB1007.namprd06.prod.outlook.com ([10.160.59.154]) by SN2PR0601MB1007.namprd06.prod.outlook.com ([10.160.59.154]) with mapi id 15.01.0300.010; Thu, 15 Oct 2015 17:13:33 +0000 From: Alex Forster To: Alexander Duyck Thread-Topic: [dpdk-dev] Question about unsupported transceivers Thread-Index: AQHRB2BDwfMhGdCgNkG1Uobt5eIVL55suxgA///MuQA= Date: Thu, 15 Oct 2015 17:13:33 +0000 Message-ID: References: <561FD17E.6070908@gmail.com> In-Reply-To: <561FD17E.6070908@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=alex@alexforster.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [173.161.199.53] x-microsoft-exchange-diagnostics: 1; SN2PR0601MB1007; 5:SUKBNwPiwZM9R8XVdftPJpb3oy8hIrWwaK5NxglD1BeDU9fo68leTzJ0TiVAwmhLmw/1gzeEZwLRpIv55MiN+bVaP6JglTZeZz+hILD/c+X2IH8qtD52m+TGCfYLZ/o+Fc1EQziTS618fq36BFb4Lg==; 24:+slR8nIE4hZUPF4SCq9Umt/WdBh07vsqDOAsB1QSxTSlRl4tlVXy1xj7krDUKy7ICCA+qheW+Zb0AkK3EZVJzMVEaOWtplXKKQiXtyFgfbQ=; 20:S2wmOvusu0ZXKupilxYxGL9X3mK8g9yU8fn3neMB7/S0LA8W23JMWRS5dS20j6zvzXiiLAu31QGhDhGHM4um/Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0601MB1007; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(202767206196957); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:SN2PR0601MB1007; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0601MB1007; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(199003)(189002)(377454003)(24454002)(77096005)(50986999)(15975445007)(5001960100002)(5008740100001)(46102003)(2950100001)(11100500001)(36756003)(76176999)(5007970100001)(102836002)(54356999)(5004730100002)(101416001)(92566002)(110136002)(2900100001)(40100003)(86362001)(105586002)(5002640100001)(87936001)(66066001)(189998001)(99286002)(64706001)(81156007)(97736004)(19580405001)(19580395003)(106356001)(106116001)(10400500002)(122556002)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR0601MB1007; H:SN2PR0601MB1007.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: alexforster.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <1CF68BAE764B1D4B86B2A601A80887A2@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: alexforster.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2015 17:13:33.5767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8fb42f39-75d5-4c92-b720-fa47f1ea1e7a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0601MB1007 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Question about unsupported transceivers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 17:13:38 -0000 On 10/15/15, 12:17 PM, "Alexander Duyck" wrote: >On 10/15/2015 08:43 AM, Alex Forster wrote: >> On 10/15/15, 11:30 AM, "Alexander Duyck" >>wrote: >> >>> On 10/15/2015 07:46 AM, Alex Forster wrote: >>>> On 10/13/15, 4:34 PM, "Alexander Duyck" >>>> wrote: >>>> >>>>> If you are using Intel's out-of-tree ixgbe driver I believe the >>>>>module >>>>> parameters are comma separated with one index per port. So if you >>>>>have >>>>> two ports you should be passing "allow_unsupported_sfp=3D1,1", and fo= r >>>>>4 >>>>> you would need four '1's. >>>> >>>> This seemed very promising. I compiled and installed the out of tree >>>> ixgbe >>>> driver and set the option in /etc/modprobe.d/ixgbe.conf. dmesg shows >>>>all >>>> eight "allow_unsupported_sfp enabled" messages but the last four ports >>>> still error out with the unsupported SFP message when running the >>>>tests. >>>> >>>> Before I start arbitrarily trying to patch out parts of the SFP >>>> verification code in ixgbe, are there any other tips I should know? >>> >>> Can you send me the command you used to load the module, and the exact >>> number of ixgbe ports you have in the system? With that I could then >>> verify that the command was entered correctly as it is possible there >>> could still be an issue in the way the command was entered. >>> >>> One other possibility is that when the driver loads each load counts as >>> an instance in the module parameter array. So if for example you >>>unbind >>> the driver on one port and then later rebind it you will have consumed >>> one of the values in the array. Do it enough times and you exceed the >>> bounds of the array as you entered it and it will simply use the >>>default >>> value of 0. >>> >>> Also the output of "ethtool -i " would be useful to verify that >>> you have the out-of-tree driver loaded and not the in kernel. >>> >>> - Alex >>> >> >> Er, let me try that again. >> >> https://gist.github.com/AlexForster/f5372c5b60153d278089 >> >> >> Alex Forster >> >> > >It looks like you are probably seeing interfaces be unbound and then >rebound. As such you are likely pushing things outside of the array >boundary. One solution might just be to at more ",1"s if you are only >going to be doing this kind of thing at boot up. The upper limit for >the array is 32 entries so as long as you only are setting this up once >you could probably get away with that. > >An alternative would be to modify the definition of the parameter in >ixgbe_param.c. If you look through the file you should fine several >likes like below: > struct ixgbe_option opt =3D { > .type =3D enable_option, > .name =3D "allow_unsupported_sfp", > .err =3D "defaulting to Disabled", > .def =3D OPTION_DISABLED > }; > >If you modify the .def value to "OPTION_ENABLED", and then rebuild and >reinstall your driver you should be able have it install without any >issues. > >- Alex > Yeah, I've had roughly the same thought process since you mentioned the args array. My first idea was "maybe the driver can't fit all of my 1's" but I saw it was defined at 32. Then I decided to just patch the whole enable_unsupported_sfp option out https://gist.github.com/AlexForster/112fd822704caf804849 but I'm still failing. I've been digging a bit, and I'm failing here in ixgbe_main.c... /* reset_hw fills in the perm_addr as well */ hw->phy.reset_if_overtemp =3D true; err =3D hw->mac.ops.reset_hw(hw); hw->phy.reset_if_overtemp =3D false; if (err =3D=3D IXGBE_ERR_SFP_NOT_PRESENT) { err =3D IXGBE_SUCCESS; } else if (err =3D=3D IXGBE_ERR_SFP_NOT_SUPPORTED) { e_dev_err("failed to load because an unsupported SFP+ or QSFP " "module type was detected.\n"); e_dev_err("Reload the driver after installing a supported " "module.\n"); goto err_sw_init; } else if (err) { e_dev_err("HW Init failed: %d\n", err); goto err_sw_init; } I've attempted a hand-stacktrace and came up with the following... ixgbe_82599.c@1016 * ixgbe_reset_hw_82599() is defined * calls phy->ops.init() which potentially returns IXGBE_ERR_SFP_NOT_SUPPORTED ixgbe_82599.c@102 * ixgbe_init_phy_ops_82599() is defined * IXGBE_ERR_SFP_NOT_SUPPORTED is returned after calling phy->ops.identify() ixgbe_82599.c@2085 * ixgbe_identify_phy_82599() is defined * calls ixgbe_identify_module_generic() ixgbe_phy.c@1281 * ixgbe_identify_module_generic() is defined * calls ixgbe_identify_qsfp_module_generic() ixgbe_phy.c@1663 * ixgbe_identify_qsfp_module_generic() is defined * We fail somewhere before the ending call to ixgbe_get_device_caps() which does take allow_unsupported_sfp into account * Possibility: hw->phy.ops.read_i2c_eeprom(hw, IXGBE_SFF_IDENTIFIER, &identifier) !=3D IXGBE_SFF_IDENTIFIER_QSFP_PLUS * Possibility: active_cable !=3D true And then I'm over my head. Should I assume from here that the most likely explanation is a bad transceiver or bad fiber? Alex Forster