Intel Ethernet Adapter I340-T4 (8086:150E:8086:12A1) showing up as unknown (8086:1509)

[Zac]

I have two identical Atom C2758 systems each equipped with a I340-T4 quad-port NIC, running an OpenSuSE 13.x distribution that I have tuned to my needs.

After some years of service, one of these NICs now powers up claiming PCI ID 8086:1509 instead of the expected 8086:150E.  Sometimes a reset will get it back to normal, but that seems to be working less frequently as time progresses.  The driver will not recognise the NIC when it claims to be 8086:1509, so that renders the connections from that NIC inoperative.  The NIC in the other system seems to be fine.

Looking up PCI IDs online says that the 1509 is 'EEPROM-less'.

Is there a way to test the card to find out whether it is corruption or a failing/failed component?

Would the driver work if I added that PCI ID to it (maybe having to provide manually things that are normally in the EEPROM such as MAC addresses)?

Thanks!

[Mike_Intel]

Hello Zac,

Thank you for posting in Intel Ethernet Communities. 

For us to further check the issue, please provide the following details.

1. What is the brand and model of the atom board?
2. What is your OS?
3. Can you share the link of your latest driver?
4. When did you start having the issue? What was the last change made?

If you have questions, please let us know. In case we do not hear from you, we will make a follow up after 3 workings days. Thank you.

Best regards,

Michael L.

Intel® Customer Support Technician

[Zac]

There are two identically equipped and almost identically configured (only things like IP addresses and system name differ) systems.

1) SuperMicro A1SRi-2758F (I have 32GiB ECC memory installed and using a Samsung 850Pro SSD) with an Intel I340-T4 in the PCIe slot.

2) Running OpenSuSE 13.2 (with some changes to suit what I'm doing with them more tightly)

3) It is using the 'igb' driver that came with the distribution

Question 4 requires a little more explanation.  Once I had these systems set up, I have not made frequent changes.  I go through the kernel and what is running in userspace and disable things I don't want or need, firewall everything I don't want or need exposed, &c.  Setting this up and verifying, since I am doing this in my spare time, usually means any significant update requires at least a couple months of configuring, patching, verifying, and testing before I'm willing to consider it ready for 'live' use.  It actually took me about six months after ordering the components for these systems (almost four years ago -- just looked at when I bought the parts) before I considered them ready.  Once I have current patches installed for what I am running and harden everything, I don't make significant changes unless/until necessary.  The last such update was more than a year ago (and things still seemed good at that point).  The systems are booted on demand via external power control and scripts on other systems (so they spend some of the time powered off -- they shut themselves down when finished with their work, including triggering the external power control to cut power after a delay of a few minutes).

A few months ago, one of them started to come up without the I340-T4 showing up.  Rebooting it (reset using the board microcontroller) would usually get it working again, but it has progressed to the point where it always comes up initially with the I340-T4 showing the problem (instead of the ports showing on PCI as 8086:150E, they show up as 8086:1509).  BMC reset is no longer 'usually fixing' the issue.  The NIC driver does not see the I340-T4 when it claims to be 8086:1509, but it works properly when it claims its normal ID of 8086:150E.

The other system still seems to be working well.  They are running the same distribution, with the same changes, same patches, the only configuration differences are limited to things needed to keep the systems unique -- IP addresses, system names, &c.  The biggest differences in use between the two is the other one (that is still working) spends most of its time powered on, while the one that has failed spends most of its time powered off.

I'm getting a replacement for the failed I340-T4, but wondering what's wrong, whether it can be fixed (or is worth it -- these cards are still not inexpensive but physical repair is too often not worthwhile, but I have seen stuff like this happen because of a corruption in NVmem settings on other devices and that can sometimes be fixed with proper software tools), and whether something can/should be done to prevent the other one failing similarly (or if this was just a fluke)...

I have a case open now with support, and will provide them some more information once I get the replacement (so I can just swap the failed card with the new one and give them the pictures and information they have requested without having to tear the system down so many times).  If I get anything helpful from that, I'll post it here.

In the meantime, if someone else has experienced this, or has some ideas, I'm interested.  I may try hacking the PCI IDs table in the driver to see whether it works as-is (since the 1509 is claimed to be EEPROM-less online, I'll probably have to provide MAC addresses or something), when I get some time to spend on that.

[Mike_Intel]

Hello Zac,

Thank you so much for a very detailed update. By the way, for us to document and clarify the information that you just provided. Please verify the details below:

1. Are you using a 3rdparty network card using i340 controller?
2. Can you provide photos of the card focusing on the markings on both sides?
3. Can you tell us where did you log a case and where did you asked replacement for a possible faulty network card?

If you have questions, please let us know. In case we do not hear from you, we will make a follow up after 3 workings days. Thank you.

Best regards,

Michael L.

Intel® Customer Support Technician

[Zac]

1) I don't think it's third party, but I wonder sometimes (it's hard to tell with 'white box' instead of retail).  Both device and subsystem claim Intel's ID.  The old and new boards look similar, slightly different sticker placement and a clearly different heatsink (new one looks like raw aluminum, the failed one looks like it's probably anodised).

2) Attaching them here, as well as LSPCI output from the failed card and a good card.

3) Intel support case 05178865.

[Mike_Intel]

Hello Zac,

Thank you for the update. I have reviewed your case 05178865 and your local Technical Support team is already handling your case. To avoid duplicate request. We need to close this thread now. Kindly continue coordinating with us via case 05178865.

If you need assistance again in the future, please don't hesitate to post a new question.

Thank you and stay safe.

Best regards,

Michael L.

Intel® Customer Support Technician