Hi Intel support team, hi all,
I have the exact same symptoms with an Intel 82566MM Gigabit Network connection card in my Toshiba Tecra S5 notebook.
Every driver up to and including version 220.127.116.11 works fine and auto-connects at Gigabit Ethernet rate, but any more recent driver (from driver packages 16.4 onwards) shortly connects with 1GBit, then disconnects, tries again and finally only connects with 100MBit.
The issue does only exist with those recent Windows drivers - when I am using RHEL6 with e1000e driver - or even an Oracle Solaris 11 x64 Live CD with its e1000g0 driver -, these operating systems connect just fine with Gigabit Ethernet.
I have been using the exact same hardware, network cables, router, ... for all these tests.
There must be a new issue with the driver which has newly been introduced in 16.4 (as opposed to 16.3 where it works fine) and affects all newer driver packages up to the current 16.8...
Can anybody from Intel please comment? Is this a known issue?
Please also get back to me if there is anything that I can do for you to help you debugging what exactly might be going wrong with these newer drivers...
Many thanks in advance & best regards,
Thanks for the post. I am still looking for ideas on what might have changed.
Thanks for the offer to help. I might contact you directly next week for some more details.
The 82566MM network connections are fairly stable at this point, so you might be better off staying at 16.3 and never upgrading. WIth the built-in network connections, often the best option is to use the drivers supported by the PC manufacturer. Unless you are trying to fix a bug, upgrading will not likely benefit you. And like you encountered, an upgrade might break something that worked good before the upgrade.
I will post something more when I have more information.
What router or switch are you connecting to? If you connect to a different router or swtich does the connection work properly?
many thanks for your reply.
My laptop is a Toshiba Tecra S5 (Centrino vPro) and is connected to a Deutsche Telekom Speedport W921V with a very exotic "Lantiq XWAY PHY11G GbE" chipset.
Unfortunately, I cannot test with another router (as I don't own one) - what I have tried in the mean time is to connect a no-name GbE switch to the router and the laptop only via the switch to the router - with the exact same results: GbE works fine in general, but not with recent Windows drivers >= 16.4.
So I am 100% certain that we can rule out the router's chipset as the root cause for the issue, because not only the Intel Windows drivers <= version 16.3, but also Intel's Linux e1000e driver and even the Oracle Solaris 11 x64 Live CD e1000g0 driver all do successfully connect and communicate with GbE speed.
The only driver versions which don't are any Windows drivers >= 16.4...
Would it be possible for you to get hold of a list of all changes between 16.3 and 16.4 regarding auto-notification? One of these changes must have broken something and hopefully can be identified this way...
Many thanks & best regards,
I am preparing a report for investigation by our engineers. Please confirm that you have tried the latest version of the driver that was introduced in the 16.7 package, version 18.104.22.168. (The 16.8 and 16.8.1 packages have the same driver.) Thank you.
yes, I can indeed confirm that I have tried every driver package between 16.3 and 16.8 (a version 18.8.1 does not yet seem publicly available!?).
When doing so, I also noted that the particular 82566MM driver did change between 16.3 and 16.4 (16.5 and 16.6 containing the same as 16.4) and between 16.6 and 16.7 (16.8 again containing the same as 16.7).
Any driver version more recent than from the 16.3 driver package is affected. Note that this is not simply a negotiation issue - when I manually override the driver to set GbE mode as the target, it connects successfully for less than a second, then disconnects again and stays disconnected stating that it could not create a link.
Exact same scenario and devices, using the 16.3 driver, no issues neither with auto-negotiation nor setting speed manually to GbE...
Thanks again for raising a bug with your engineers - there has definitely a regression being introduced between 16.3 and 16.4...
"(a version 18.8.1 does not yet seem publicly available!?)"
my typo: of course I meant to say: "(a version 16.8.1 does not yet seem publicly available!?)"
Thank you Andreas,
So far we only have a CD for version 16.8.1. The OS downloads are still being tested before posting. But 16.8.1 will not change anything for you compared to 16.8, so do not bother to test that version. As you pointed out, the last driver change for your network connection was in the 16.7 package.
This issue is now under investigation. The next planned refresh to the e1e driver used by your network connection is scheduled for the second quarter, 2012. You can skip trying any updates that come out this quarter since they will not have a refresh to the e1e driver. I do not know the package numbers yet.
Watch the page at http://www.intel.com/support/network/sb/cs-006333.htm to see when the e1e driver gets refreshed. I usually get this page updated several days before the OS downloads are available in Download Center.
I'm trying to fix the really same problem as the original poster (thanks to).
At this link:
I can find informations about the possibly corrected driver (version 17.1) but when I look for it here:
for the product named "Intel 82566 Gigabit Ethernet PHY", I found available only drivers up to 17.0 version (which, looking at the rev history, doesn't contain any changes about 82566 controller).
I then looked for 16.3 driver, with no luck as well.
Is it possible to have some help about this?
Unfortunately, the webpacks for Windows downloads for release 17.1 will not be available for a few weeks. You can download a zip file of the CD. (You don't have to make a CD, just expand the zip file onto a hard drive or thumb drive and then launch the autorun.
I hope this helps you.
Brilliant Mark, thank you.
Hi, I have the same issue, I have tried the 17.1 driver (22.214.171.124) but it has not fixed the problem. We have other network problems which may be related – Windows 7 Dot1x authentications occasionally fail during boot (3% of the time).
unfortunately, I have to confirm what other users in this thread have already noted:
The 17.1 driver update (which comes with version 126.96.36.199 of the "e1e" driver) has NOT fixed the issue - it still exposes the same buggy behaviour and only auto-negotiates and connects at 100MBit.
Symptoms are exactly the same as mentioned in the original posts, so I have some real doubts that the issue has been addressed at all...
Did your engineers successfully identify at all the unfortunate code change that has been done between 16.3 and 16.4 which introduced this regression and started to break GbE negotiation and connections for us?
It throws a very poor light on Intel's driver development that a huge company like yours seems unable to fix a quite major driver bug which has been introduced such a long time (i.e. so many releases) ago...
As stated before: If there is anything that I can do to help your engineers debug and finally fix the issue, please let me know...
For now, I am reverting my system one more time to the 16.3 driver... Sigh!
Many thanks & best regards,
Unfortunately the bug reported by Andreas, awl29, is still open. I do not know if a driver fix will be available in the future or not.
In general, I always like to run the latest driver and software. I think most of the people following this thread feel the same way, since a driver update is behind the issue in this thread. Sometimes with older hardware, keeping the last tested driver and software is a better choice. This might be one of those times.
For those of you who do not have a copy of an earlier driver and are having trouble with the newer driver versions, your best bet would be to get whatever was posted by your motherboard or computer maker. For example, you could download the last software posted for the Intel® Desktop Board DQ965GF to get a copy of an earlier driver.
The bug is still open, and if there is a driver change to fix this bug, I will post about it here.