Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

2016-04-04 Thread Wesley W. Terpstra 
On Mon, Apr 4, 2016 at 8:42 PM, Alexander Duyck
 wrote:
> It is always possible that the SFP+ cages on the device may not dissipate
> enough heat for a given SFP+ module

If an SFP is capable of melting itself or other devices, that is the
fault of the SFP, not Intel's card, and not my unlocking of said card.
FYI, I have never seen such an SFP, and we use lots of different
models at my day job.

> when the device is under heavy use.

There is no "heavy use" for 10GBase.
You constantly transmit comma codes for clock recovery or the link goes dead.

> Odds are the card does have a fuse on it so it probably would just
> brick the card.  Still, intentionally circumventing the white list in
> the EEPROM puts you at a greater risk than just "bricking the card"
> there is always the potential for more catastrophic issues such as the
> risk of actually starting a fire.

While I agree there is a non-zero risk, it's EXTREMELY unlikely.

> I've seen things such as someone
> overclocking a graphics card and literally burning the network card in
> the slot next to it.

Overclocking a graphics card can increase power consumption a lot! You
are talking about parts that draw 200W during normal operation, and
god knows how much when they overclocked it. An SFP+ that draws 5W
would already be on the high end. There is no fire risk from 5W in a
housing that size, with thermal contact to the copper layers of the
card. The surface area is plenty.

> It is those kind of liability issues that lead to things like
> this white-list that Intel implemented in their EEPROM in the first
> place.

I don't believe that for a second.

If that were the case, then the low-margin bargain 10GBase cards would
be the ones implementing the SFP+ white lists.  However, the cheap
cards allow all SFP+s. Why? Because the legal jeopardy is so low that
even with their low margin, they don't care. It's no coincidence that
the two major bad actors (Intel and Cisco) also sell SFP+s.

> My concern wouldn't be so much about bricking the card as voiding the
> warranty for the entire system.  You should probably stress that this
> is "at your own risk" ... You might also want to throw a license on the code 
> in the
> git repo so that you make it expressly clear you are not liable for
> any possible damages caused by the use of your code.  Probably
> something like a BSD license would suffice.

Yes, I should put a licence on it. So I suppose there will be an "at
your own risk" from that. However, I live in Germany. If you help
someone and do not charge anything for it, you can not be held liable
here. It's the "good samaritan law".

> ... the risks could extend beyond just the card
> itself as there is always potential for damage to other components in
> the system.

I suppose it doesn't hurt to say this, but I don't agree that there is
any real risk.

PS. Alex, sorry for sending this to you twice.

--
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

2016-04-04 Thread Alexander Duyck 
On Mon, Apr 4, 2016 at 10:48 AM, Wesley W. Terpstra  wrote:
> On Mon, Apr 4, 2016 at 7:28 PM, Alexander Duyck
>  wrote:
>>> DO NOT FOLLOW THIS GUIDE UNLESS YOU DON'T FEAR BRICKING YOUR CARD!
>>
>> Actually possible repercussions are far worse than bricking your card.
>> You could potentially burn up the entire system if you mess with an
>> EEPROM and you don't know what you are doing.
>
> I disagree.
>
> To even read the I2C EEPROM from the SFP+, which is how the card
> rejects the SFP+, it must power it. If the SFP+ is electrically
> broken, it will be a hazard regardless of whether or not it passes the
> qualification check.

Yes and no.  Plugging it in is one thing.  Enabling link and passing
traffic is another.  Most devices consume less power when idle.
Another thing I forgot to mention is that there are also thermal
considerations you have to take into account as well.  It is always
possible that the SFP+ cages on the device may not dissipate enough
heat for a given SFP+ module when the device is under heavy use.

> Furthermore, any responsibly developed board includes a fuse to
> prevent overcurrent with plug-in modules. I do not have the card in
> front of me, but I expect such an expensive card would include this
> sort of basic safety precaution.

Odds are the card does have a fuse on it so it probably would just
brick the card.  Still, intentionally circumventing the white list in
the EEPROM puts you at a greater risk than just "bricking the card"
there is always the potential for more catastrophic issues such as the
risk of actually starting a fire.  I've seen things such as someone
overclocking a graphics card and literally burning the network card in
the slot next to it.  Voiding a warranty by doing something like this
can have a greater risk than just breaking the one thing you tampered
with.  It is those kind of liability issues that lead to things like
this white-list that Intel implemented in their EEPROM in the first
place.

My concern wouldn't be so much about bricking the card as voiding the
warranty for the entire system.  You should probably stress that this
is "at your own risk" and the risks could extend beyond just the card
itself as there is always potential for damage to other components in
the system.  You might also want to throw a license on the code in the
git repo so that you make it expressly clear you are not liable for
any possible damages caused by the use of your code.  Probably
something like a BSD license would suffice.

- Alex

--
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

2016-04-04 Thread Wesley W. Terpstra 
On Mon, Apr 4, 2016 at 7:28 PM, Alexander Duyck
 wrote:
>> DO NOT FOLLOW THIS GUIDE UNLESS YOU DON'T FEAR BRICKING YOUR CARD!
>
> Actually possible repercussions are far worse than bricking your card.
> You could potentially burn up the entire system if you mess with an
> EEPROM and you don't know what you are doing.

I disagree.

To even read the I2C EEPROM from the SFP+, which is how the card
rejects the SFP+, it must power it. If the SFP+ is electrically
broken, it will be a hazard regardless of whether or not it passes the
qualification check.

Furthermore, any responsibly developed board includes a fuse to
prevent overcurrent with plug-in modules. I do not have the card in
front of me, but I expect such an expensive card would include this
sort of basic safety precaution.

--
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

2016-04-04 Thread Alexander Duyck 
On Sun, Apr 3, 2016 at 7:21 AM, Wesley W. Terpstra  wrote:
> Sorry for the earlier message! My hand hit the send button before I'd
> finished writing the email.
>
> I had a bit more time this weekend, and I managed to unlock my
> X710-DA4. It now accepts any SFP+. I tried four different models of
> 10GBASE-LR transceivers in the card, and they all seemed to work just
> fine. Admittedly, I only tested that they could hit 1.1GiB/s TCP flows
> for a few minutes before picking one transceiver type and sticking
> with it. In particular, I had some A7EL-LND3-ADMA transceivers lying
> around that I found for 10EUR a piece and I am now using these
> reliably the whole day. In summary, FUD aside, the X710-DA4 works
> great with most SFP+s and the decision to lock this card down seems
> more like it has something to do with monopolistic practices than
> anything else. If I run into any problems with the cheaper SFP+s I
> will follow-up with a reply to the list.
>
> The XL710 has four records in NVM that describe whether or not the
> card should reject an unknown SFP+. When you flip these four bits, it
> will accept any SFP+. I have tested Linux only, but the driver works
> unmodified with an unlocked card. Todd Fujinaka mentioned that Intel
> sells an unlocked optics card, so I imagine the drivers were tested
> against those cards which is why it works under linux. Therefore, I'd
> wager the windows driver likewise works with an unlocked card, though
> I have not tested it.
>
> Be warned: running nvmupdate64e -rd will restore the lock bits! Normal
> update appears to preserve their value.
>
> To unlock your card, you will need linux 4.5, nvmupdate64e v1.26.17.09
> , skill with Cl, and some time. I have not prepared a general-purpose
> unlocking tool, because the NVM format might differ between cards and
> thus this procedure should only be undertaken by someone who knows
> what they are doing.
>
> DO NOT FOLLOW THIS GUIDE UNLESS YOU DON'T FEAR BRICKING YOUR CARD!

Actually possible repercussions are far worse than bricking your card.
You could potentially burn up the entire system if you mess with an
EEPROM and you don't know what you are doing.

The main reason why Intel locks out third party SFPs is because they
want to be able to perform electrical validation before attempting to
power them on in the driver.  Odds are most SFPs won't cause any
issues, but you just opened yourself up to liability if someone starts
a fire or damages their equipment by following your guide so I want to
make sure you understand the risks are much greater then what you have
stated here.

- Alex

--
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

2016-04-04 Thread Wesley W. Terpstra 
On Mon, Apr 4, 2016 at 7:09 AM, Oleg A. Arkhangelsky  wrote:
> Sourceforge eat mail attachments. Put your program somewhere else.

Ok. Thanks for pointing this out!

I've put a slightly improved version up at:


--
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

2016-04-03 Thread Oleg A . Arkhangelsky 


03.04.2016, 17:22, "Wesley W. Terpstra" :

> Once you've found the first record's offset, update mypoke.c with the
> correct offset. Then calculate the correct value for the Misc0
> register by subtracting bit 11 and modify the line
> "*(uint16_t*)(eeprom+1) = 0x230c;". Then, compile and run mypoke.
> Finally, confirm with mytool that your new Misc0 register was
> correctly written. If anything goes wrong, run nvmupdate64e -rd BEFORE
> you reboot! This will blow away any changes you made by mistake.
>

Sourceforge eat mail attachments. Put your program somewhere else.

--
wbr, Oleg.

"Anarchy is about taking complete responsibility for yourself."
  Alan Moore.

--
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel Ethernet, visit 
http://communities.intel.com/community/wired

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

2016-04-03 Thread Wesley W. Terpstra 
Sorry for the earlier message! My hand hit the send button before I'd
finished writing the email.

I had a bit more time this weekend, and I managed to unlock my
X710-DA4. It now accepts any SFP+. I tried four different models of
10GBASE-LR transceivers in the card, and they all seemed to work just
fine. Admittedly, I only tested that they could hit 1.1GiB/s TCP flows
for a few minutes before picking one transceiver type and sticking
with it. In particular, I had some A7EL-LND3-ADMA transceivers lying
around that I found for 10EUR a piece and I am now using these
reliably the whole day. In summary, FUD aside, the X710-DA4 works
great with most SFP+s and the decision to lock this card down seems
more like it has something to do with monopolistic practices than
anything else. If I run into any problems with the cheaper SFP+s I
will follow-up with a reply to the list.

The XL710 has four records in NVM that describe whether or not the
card should reject an unknown SFP+. When you flip these four bits, it
will accept any SFP+. I have tested Linux only, but the driver works
unmodified with an unlocked card. Todd Fujinaka mentioned that Intel
sells an unlocked optics card, so I imagine the drivers were tested
against those cards which is why it works under linux. Therefore, I'd
wager the windows driver likewise works with an unlocked card, though
I have not tested it.

Be warned: running nvmupdate64e -rd will restore the lock bits! Normal
update appears to preserve their value.

To unlock your card, you will need linux 4.5, nvmupdate64e v1.26.17.09
, skill with Cl, and some time. I have not prepared a general-purpose
unlocking tool, because the NVM format might differ between cards and
thus this procedure should only be undertaken by someone who knows
what they are doing.

DO NOT FOLLOW THIS GUIDE UNLESS YOU DON'T FEAR BRICKING YOUR CARD!

Step one is to find the "PHY Capability LAN 0" structure in the NVM.
The NVM image that nvmupdate64e v1.26.17.09 writes seems to have a
corrupt "PHY Capability LAN 0 Pointer", so you will need to find the
record by hand. Use the attached my-tool.c to read the NVM. You will
need to set devid to the PCI express device ID for your card. lspci -n on
my machine showed:

01:00.0 0200: 8086:1572 (rev 01)
01:00.1 0200: 8086:1572 (rev 01)
01:00.2 0200: 8086:1572 (rev 01)
01:00.3 0200: 8086:1572 (rev 01)
... and thus I set devid to 0x1572.

You also need to set ifr.ifr_name to one of the corresponding ethernet
names. In my machine the card was eth2, eth3, eth4, eth5. I imagine
other models might have less devices and the numbers assigned depend
on what other cards udev has seen in your system. It does not matter
which card you pick, as long as it matches the devid you picked
earlier.

Once mytool works, run ./mytool 0x6870 0xc as root and see if it has a
similar record to mine.
My "PHY Capability LAN 0" record looked like this:
6870 + 00 => 000b
6870 + 01 => 0022 = external SFP+
6870 + 02 => 0083 = int: SFI, 1000BASE-KX, SGMII (???)
6870 + 03 => 1871 = ext: 0x70 = 10GBASE-{SFP+,LR,SR} 0x1801=crap?
6870 + 04 => 
6870 + 05 => 
6870 + 06 => 3303 = SFP+ copper (passive, active), 10GBase-{SR,LR}, SFP
6870 + 07 => 000b
 6870 + 08 => 2b0c
*** This is the important register ***
(0xb=bits 3+1+0 = enable qualification (3), pause TX+RX capable (1+0),
 0xc = 3+2 = 10GbE + 1GbE)
6870 + 09 => 0a00
6870 + 0a => 0a1e = default LESM values
6870 + 0b => 0003

I had 3 more records just like this at offsets 0x687c, 0x6888, and
0x6894. The key field is at offset 0x08 (PHY Capabilities Misc0). You
need to clear bit 11. In my case that meant writing 0x230c.

If your record is not at this location, run mytool 0 0x8000 >
somefile, and start looking for 4 occurrences of "000b" that are
separated by 0xc addresses and repeat four times. This is how I found
my records, since the NVM image from Intel does not have pointers to
the correct location.

Once you've found the first record's offset, update mypoke.c with the
correct offset. Then calculate the correct value for the Misc0
register by subtracting bit 11 and modify the line
"*(uint16_t*)(eeprom+1) = 0x230c;". Then, compile and run mypoke.
Finally, confirm with mytool that your new Misc0 register was
correctly written. If anything goes wrong, run nvmupdate64e -rd BEFORE
you reboot! This will blow away any changes you made by mistake.

If everything looks good, run nvmupdate64e -u just to make sure the
device is in a valid state. Then, power cycle your machine, insert the
SFP+ of your choice, and enjoy your unlocked card.

If this works for you, please let me know. If this proves useful to
enough people, perhaps we can put together a more user-friendly
unlocking procedure. As I said, without seeing a few more cards, I
would not want to automate this.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications