I have a system using an Intel i218-LM ethernet controller:
- Fully patched (as of 16th Feb 2015) Windows 8.1 64-bit
- Intel driver PROWinx64.exe, Version:19.5, Date:28th Oct 2014. Appears in Windows as driver v188.8.131.52 dated 29th Sept 2014.
Under normal operation the LAN works correctly. I can disconnect and re-connect the LAN cable, and each time the LAN connection is re-established.
If I perform a system restart with the LAN cable connected, the LAN is established correctly once Windows boots.
However, if I perform a system restart without a LAN cable connected then I get a Code-10 error in Windows under Device-Manager for the i218-LM controller. When I re-connect the LAN cable obviously the connection isn't re-established due to the Code-10 error. If within Device-Manager I disable and then re-enable the i218-LM, the Code-10 error goes away, and the connection is correctly established.
I have rolled back the Intel driver to the earliest one I can find on the Intel download site e.g. v18.5 (appears as v184.108.40.206 dated 2nd July 2013 in Device-Manager). This still causes the Code-10 error when I perform a Windows restart without a cable connected.
However, if I completely remove the Intel driver, and use the Windows 8.1 Microsoft built-in driver (appears as v220.127.116.11 dated 28th March 2013 in Device-Manager) then the Microsoft driver solves the above restart issue. So, it looks like using any of the official Intel drivers causes the issue!
Any comment/help from Intel?
I have tried your suggestion but it didn't make any difference to my problem - I still get a Code 10 error after a restart without a cable connected. If I perform a full power-cycle without a cable connected, I don't get the problem....it is only with a restart!
When in this Code 10 state the error logged in Event-Viewer is "Source: e1dexpress" "Event ID 24". I am guessing that this doesn't tell me very much as I think the "e1dexpress" is just identifying the i218-LM part of the driver, and "Event ID 24" is just Intel's way of stating it couldn't start the driver.
Have you tried installing driver version 19.3 http://downloadcenter.intel.com/download/24397/Network-Adapter-Driver-for-Windows-8-1- Intel® Download Center, see this could be of help. thanks.
As I previously posted (17th Feb), I have tried the earliest driver I could find on the Intel site. This was v18.5 (appears as v18.104.22.168 dated 2nd July 2013 in Device-Manager). This version still causes the same issue. The interesting thing here is that this Intel driver (v18.5 [v22.214.171.124]) is only 3 months newer from the Win8.1 built-in Microsoft driver (v126.96.36.199) which doesn't exhibit the problem.
So what has changed between v188.8.131.52 and v184.108.40.206 ???
I haven't specifically tried v19.3. I'll try this today and let you know the results.
I have tested Intel driver v19.3 [v220.127.116.11] today. This version still causes the issue.
Today I have also built a completely clean Win8.1 image on an identical piece of hardware, and have tried Intel driver v18.5, v19.3 & v19.5. All versions cause the same issue. The Microsoft driver [v18.104.22.168] does not exhibit the issue.
We have a new driver version 20 released recently, please try this version to see if this will make any difference:
https://downloadcenter.intel.com/download/23071/Network-Adapter-Driver-for-Windows-8-1- Intel® Download Center
I have tried the version 20 release and the problem is still there. This is not surprising, as the i218-LM driver has not changed - within DeviceManager it is still shown as v22.214.171.124 dated 29th Sept 2014. In fact the release notes for version 20 only state a change in the 'teaming name', which is clearly nothing to do with the problem I am experiencing!
My question still remains - "what has changed between v126.96.36.199 and v188.8.131.52" ???
Yes I have dialogue going with Kontron as well as Intel....
The problem, as usual, is that both parties try to pass the blame to each other, including bringing Microsoft into the equation, and the poor old customer (me) who has actually spent his money, doesn't get any co-operation!
Support really needs to differentiate between customers who are technically capable (I am a CEng with a degree in Electronic Engineering) of investigating the issue, providing a little guidance is provided.
At no stage has any party managed to provide an explanation as to why there is a difference in behaviour between a full POWER-CYCLE and a POWER-RESTART (I only see this problem when I perform a RESTART).
I understand that the Intel chip can go in to ULP mode when the cable is disconnected, and that it comes out of ULP mode when the cable is re-connected. So why doesn't this work after a RESTART?? What exactly is the process that brings the chip out of ULP?? What hardware and/or software functions are required to do this?? Intel must know what the correct process should be??
In reality I understand that the issue may include a combination of Kontron's design (which they are not going to give me), the BIOS (again Kontron's responsibility), Intel's i218-LM, Intel's driver and the Windows 8.1 operating system. If I know what features are required and I understand the correct process, I can then ask a specific question to Kontron as to whether they have implemented the design to support these features.