Intel 10G NIC problems

This isn't probably isn't a Linux question, it's really a hardware issue
but please answer anyway.

I have a couple of Intel E10G42BTDA Dual SFP+ 10G NICs in a pair of
Scientific Linux 6.1 systems. They work fine when I connect them together
with passive copper cables but they don't get signal detect when I connect
them with fiber. I'm using Finisar transceivers with 2M fiber LC-LC
cables. I've been able to reliably send data through the fiber cables from
an FPGA card that I'm working on so I know the cables are OK. I've tried
reversing the cable connections and that doesn't help.

Is there something that has to be configured to make them work with fiber?

General Schvantzkoph <(E-Mail Removed)> wrote:
> This isn't probably isn't a Linux question, it's really a hardware issue
> but please answer anyway.

> I have a couple of Intel E10G42BTDA Dual SFP+ 10G NICs in a pair of
> Scientific Linux 6.1 systems. They work fine when I connect them
> together with passive copper cables but they don't get signal detect
> when I connect them with fiber. I'm using Finisar transceivers with
> 2M fiber LC-LC cables. I've been able to reliably send data through
> the fiber cables from an FPGA card that I'm working on so I know the
> cables are OK. I've tried reversing the cable connections and that
> doesn't help.

> Is there something that has to be configured to make them work with
> fiber?

Are you certain that your Finisar transceivers are 10GbE transceivers
and not Fibre Channel transceivers? What does dmesg say about NIC
initialization - you might dmesg | grep <driver> and dmesg | grep
<interface> and see what they say.

You might also hunt around to see if there is an Intel NIC support
email address.

rick jones
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Tue, 06 Sep 2011 17:56:19 +0000, Rick Jones wrote:

> General Schvantzkoph <(E-Mail Removed)> wrote:
>> This isn't probably isn't a Linux question, it's really a hardware
>> issue but please answer anyway.
>
>> I have a couple of Intel E10G42BTDA Dual SFP+ 10G NICs in a pair of
>> Scientific Linux 6.1 systems. They work fine when I connect them
>> together with passive copper cables but they don't get signal detect
>> when I connect them with fiber. I'm using Finisar transceivers with 2M
>> fiber LC-LC cables. I've been able to reliably send data through the
>> fiber cables from an FPGA card that I'm working on so I know the cables
>> are OK. I've tried reversing the cable connections and that doesn't
>> help.
>
>> Is there something that has to be configured to make them work with
>> fiber?
>
> Are you certain that your Finisar transceivers are 10GbE transceivers
> and not Fibre Channel transceivers? What does dmesg say about NIC
> initialization - you might dmesg | grep <driver> and dmesg | grep
> <interface> and see what they say.
>
> You might also hunt around to see if there is an Intel NIC support email
> address.
>
> rick jones

I found a page on Intel's site where they say that their NICs only work
with Intel transceivers, and I've received an e-mail from them to that
effect. I wonder what the hell they did that made there adapters
incompatible with a standard SFP+ transceiver?

http://www.intel.com/support/network.../CS-030612.htm

General Schvantzkoph <(E-Mail Removed)> wrote:
> I found a page on Intel's site where they say that their NICs only
> work with Intel transceivers, and I've received an e-mail from them
> to that effect. I wonder what the hell they did that made there
> adapters incompatible with a standard SFP+ transceiver?

> http://www.intel.com/support/network.../CS-030612.htm

I don't know specifically which NIC vendors do that and which do not,
and which switch vendors do that and which do not (apart from some
specific examples not worth mentioning here), but there are probably
two factors.

First is the testing/support matrix if one "supports" essentially
random transceivers - one either has to test them all, or be prepared
to turn things around in a really short period of time when some
incompatible transceiver shows up. In my conversations with some
switch and NIC types whom I trust, they have told me that indeed,
while there is a standard, there is also a rather wide range of how
well different bits of kit adhere to it and they have encountered
problems when someone wanted to use some fly-by-night transceiver.

The second, perhaps less noble but equally affecting reason would be
cost and revenue. All that testing to check other transceivers
(rather than ass-u-me they will work) is cost that does not
necessarily translate into revenue. Limiting support to the vendor's
own branded transceivers though does increase revenue (assuming it
does not cause people to not buy your NICs in the first place). And
it shrinks the test matrix *considerably*.

If you think the situation is fun with things like optical
transceivers you would really love DAC - the cable with transceiver
IDs on either end. Then, have a switch from vendor A and one from
vendor B - who's DAC will you have to use? Though, in that case,
there has been some relaxation of what (at least some) switches will
accept wrt IDs on the DACs, with some switches no a priori rejecting
the "foreign" IDs but also saying it may not be "supported" which
leads to a generalized version of something I trot-out to explain the
difference between "supported" and "works" in HPSpeak:

Supported, known to work -> warm fuzzies all around
Supported, not known to not work -> an Vendorite may be in trouble
Supported, known to not work -> an Vendorite is in trouble
Unsupported, known to work -> lucky today, unlucky tomorrow?
Unsupported, not known to not work -> there but for the grace of Turing
Unsupported, known to not work -> no, it was not deliberate ;-)

rick jones
--
It is not a question of half full or empty - the glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Sep 6, 2:28*pm, General Schvantzkoph <schvantzk...@yahoo.com>
wrote:

> I found a page on Intel's site where they say that their NICs only work
> with Intel transceivers, and I've received an e-mail from them to that
> effect. I wonder what the hell they did that made there adapters
> incompatible with a standard SFP+ transceiver?
>
> http://www.intel.com/support/network.../CS-030612.htm

1) Read the transceiver ID.

2) Check the ID against a list.

3) If it doesn't match, pretend the transceiver doesn't exist.

DS

On Thu, 08 Sep 2011 17:38:59 -0700, David Schwartz wrote:

> On Sep 6, 2:28Â*pm, General Schvantzkoph <schvantzk...@yahoo.com> wrote:
>
>> I found a page on Intel's site where they say that their NICs only work
>> with Intel transceivers, and I've received an e-mail from them to that
>> effect. I wonder what the hell they did that made there adapters
>> incompatible with a standard SFP+ transceiver?
>>
>> http://www.intel.com/support/network.../CS-030612.htm
>
> 1) Read the transceiver ID.
>
> 2) Check the ID against a list.
>
> 3) If it doesn't match, pretend the transceiver doesn't exist.
>
> DS

It turns out the particular cards that I bought don't support optical
transceivers, it doesn't say that on Newegg's website but there is a hard
to find page on Intel's website that say so.