[dpdk-dev] [E1000-devel] Unsupported SFP+ Module - Hardware Initialization Failure -19

[Skidmore, Donald C]

The error value of -19 means your EEPROM indicates you're NIC doesn't have support for your SFP+ module.  So you're correct this isn't specifically a DPDK issue, the code that verifies this is shared both between the Linux driver as well as DPDK.  There are two possible cases here 1) we recognize the module but it isn't supported or 2) we don't know what the module is.  If it was the first case then for the out of tree linux driver you could use the module parameter "allow_unsupported_sfp" to get around this check.  Of course turning on this option produces the following rather scary log message:

"WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.

Thanks,
-Don Skidmore <donald.c.skidmore at intel.com>

> -----Original Message-----
> From: Ajit Khaparde [mailto:ajit.khaparde at broadcom.com]
> Sent: Tuesday, August 30, 2016 7:22 PM
> To: Alex Forster <alex at alexforster.com>; e1000-devel at lists.sourceforge.net
> Cc: dev at dpdk.org
> Subject: Re: [E1000-devel] [dpdk-dev] Unsupported SFP+ Module - Hardware
> Initialization Failure -19
> 
> On Tue, Aug 30, 2016 at 11:02 AM, Alex Forster <alex at alexforster.com>
> wrote:
> 
> > Hi guys,
> >
> > I have a problem again that I had about a year ago[1]. My Finisar
> > FTL410QE2C (multimode QSFP) transceivers aren’t working with my Intel
> > X520-QDA1’s. I have 7 servers, each with two X520’s and two QSFP
> > transceivers in them, totaling 14 NICs and transceivers, and all of
> > them fail with the same error: Unsupported SFP+ Module / Hardware
> > Initialization
> > Failure: -19.
> >
> > This doesn’t appear to be specifically a DPDK issue, but rather an
> > IXGBE issue, since (a) the stock Debian 8 IXGBE, (b) the latest out of
> > tree IXGBE, and (c) DPDK’s copy of IXGBE all fail in this same way.
> > I’m happy to take this to an IXGBE mailing list if somebody can point
> > me to one, but just in case anyone here can help, here’s the info I’ve
> > gathered–
> >
> > * The exact function where IXGBE bails is here, annotated with the
> > values read from the transceiver’s EEPROMs:
> > https://www.googledrive.com/ host/0B_-81lR_g8lyNDJ6QkkxS28yQzQ
> > * I’ve modified DPDK’s copy of IXGBE to dump the whole EEPROM of these
> > transceivers, which are here: https://gist.github.com/alexforster/
> > 5da30cd89d49877d5d6908e9628baee8
> >
> > Here’s (I think) an important part: Last time I had this problem, I
> > only had one server, and one of the two transceivers worked. I fixed
> > the other transceiver in that server by replacing it with an identical
> > model. Now, suddenly, neither of those transceivers (which have worked
> > for ~11 months) are recognized. I don’t know how I could have done
> > something that would have affected the EEPROM output, but I suspect I may
> have.
> >
> > Anybody able to offer any advice?
> >
> > Alex Forster
> >
> > [1] http://dpdk.org/ml/archives/dev/2015-October/024973.html
> 
> 
> Adding e1000-devel at lists.sourceforge.net