We have developed a product that hosts an Atom E3805, the Intel 82574 ethernet controller and an i210 Ethernet controller. On one specific instance of our product the 82574 ethernet stopped working during general use and when running lspci we get the following output:
Instead of reporting that Bus 03 is connected to an Intel 82574 ethernet controller it is reported as 0000. When running eeupdate we get the following output:
Bus 03 is not recognized as an Intel 82574 ethernet controller. We have over 40 of these units and this is the first time we see this behavior.
So the question: What would cause the bridge to be recognized as “0000” and not a 82574? Keeping in mind that it worked 100% before and just suddenly stopped working.
Thank you very much.
Thank you for contacting Intel Embedded Community.
Could you please let us know the changes that you have made previous to the affected design fails?
How many units are failing? By the way, please list the sources that you have used to design the affected project if it has been verified by Intel?
Could you please provide pictures of the top side markings of the affected 82574 Ethernet Controllers?
We are waiting for your answer to these questions.
Thanks for the response.
- We haven't made any changes to the design. The unit that failed is exactly the same configuration as functional units.
- We are only experiencing this problem on a single unit. It used to work and stopped working without any changes.
- The design wasn't verified by Intel. We followed the datasheet and it works on at least 40 units. Would a review by intel be possible?
- I will upload this tomorrow.
Thanks for your update.
In case that you want to request a full schematics and layout review of your design, please follow the procedure stated in the following website:
By the way, could you please clarify if this situation happens on a specific Operating System (OS) or various? please provide the information of the Operating Systems (version, manufacturer, kernel, and other details) associated to this situation.
We are waiting for your answer to this question and the requested picture.
Thanks for your update.
Could you please verify if the problem persists when you use any of the following Operating Systems?
Windows Server* 2003
Windows Server* 2008
Windows XP* (Service Pack 2 or 3)
Linux* Kernel version 2.6.24 or higher
Linux* Kernel version 220.127.116.11 or higher
SLES* 9 SP4
SLES* 10 SP1
SCO OpenServer 6/Unixware* 7.1.x
Novell Netware* 6.5
Windows XP Embedded
We are waiting for your confirmation.
Our current system already uses a Linux kernel version higher than the ones specified in the list above (4.9.76) and it has been running fine over 4 years on at least 40 units. This is the first time we have experienced this problem.
Given some more testing on our side I'd like to focus on the EEPROM attached to the bridge. When we unsoldered the EEPROM (AT25256B) attached to the bridge on the affected board, it was detected again as 82574L using lspci-k (and eeupdate32). We have not yet confirmed whether the EEPROM is physically broken or if the contents were only corrupted. We will confirm this on Monday by attempting to wipe the original EEPROM and replacing it on the board.
- Have you ever had instances of corrupt EEPROM when using this bridge?
- What write transactions are issued by the bridge after initial programming of the EEPROM? Is wear a problem? The unit is not our oldest and was produced in December 2018.
- Can you confirm that the AT25256B is compatible with the bridge?
Hi @Mæcenas_INTEL ,
We swopped the EEPROM with a new part and the bridge now functions as it should. We have not installed the old EEPROM on another board to check if it still functions.
We have not replaced the bridge.
I installed the original EEPROM on a test board and tested the EEPROM through several wipe/read/write/read cycles. Electrically it works 100%.
I've attached the contents of the EEPROM (before I wiped it). Can you please confirm whether this image is valid for the controller (ie. is anything corrupted).
Also, can you please provide feedback on my questions from earlier in this thread:
- Have you ever had instances of corrupt EEPROM when using this ethernet controller?
- What write transactions are issued by the ethernet controller after initial programming of the EEPROM?
- Can you confirm that the AT25256B is compatible with the ethernet controller?
Thanks for your replies.
The list of the compatible EEPROMs with the Intel(R) 82574 Gigabit Ethernet Controller [Hartwell] can be found in Table 26, on page 54 of the Intel(R) 82574 GbE Controller Family Datasheet document # 317694.
It is important to let you know that the questions related to the replacement, compatibility, or issues of the listed third-party devices should be addressed to their manufacturers.
The Hartwell Datasheet can be found when you are logged into your Resource & Design Center (RDC) privileged account at the following website:
The RDC Account Support form is the channel to process your account update request or solve any inconvenience with the cited website. It can be found at:
The same problem has occurred on another unit.
- After initial programming through eeupdate32 is the EEPROM contents ever modified by the 82574 controller?
- Can you please provide me with the timing requirements of the NVM.