82566DM 100MB Auto-Negotiation with 16.4 and 16.5

[KTee]

I recently reloaded an older PC (Intel DQ965GFEKR - 82566DM), and decided to use the 16.5 package upon reinstall. I noticed that network transfers to and from this PC were slower than usual, and I found that it was negotiating at 100Mb/Full Duplex. I tested another PC (Intel DQ67SW - 82579LM) with the same cable/switch etc. and it auto-negotiates at 1Gb/Full-Duplex.

After trying a few things this is what I've found:

- LAN driver packages 16.4 and 16.5 both auto-negotiate at 100mb/Full Duplex since they both use the same driver (e1exxxx.sys 9.14.180.0)

- LAN driver package 16.3 auto-negotiates at 1Gb/Full Duplex (e1exxxx.sys 9.13.41.0)

- The results are the same whether I install the PROSet software or just bare drivers.

- If I force 1Gb / Full Duplex, the network connection disconnects.

- I've tried Windows XP x86 (SP3), Windows XP x64 (SP2), Windows Vista Business x86 (SP1), and Windows 7 Pro x86/x64 (SP1), all with the same

result (16.3 - 1Gb, 16.4/16.5 - 100Mb)

- BIOS version on the DQ965GFEKR is 6100, and I also tried 6077.

- I've tried another PC with the same motherboard (DQ965GFEKR - 82566DM) and it produced the same result as well.

Here are a few screenshots of Win7 Pro x86 with 16.3 and 16.5: http://imgur.com/a/8SzTV http://imgur.com/a/8SzTV

I'm not sure whether other ethernet controllers that use this particular driver are affected. In any case, I'm running with the 16.3 package right now and all is well

Has anybody else noticed this issue with either this or another supported ethernet component supported by this driver?

[idata]

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 9.13.41.0 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,

Andreas

[Mark_H_Intel]

Hi Andreas,

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.

Mark H

[Mark_H_Intel]

Hi Andreas,

What router or switch are you connecting to? If you connect to a different router or swtich does the connection work properly?

[idata]

Hi Mark,

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,

Andreas

[Mark_H_Intel]

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 9.15.11.0. (The 16.8 and 16.8.1 packages have the same driver.) Thank you.

Mark H

[idata]

Hi Mark,

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...

Best regards,

Andreas

[idata]

Sorry,

"(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!?)"

BR,

Andreas

[Mark_H_Intel]

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 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 http://downloadcenter.intel.com/ Download Center.

Mark H

[idata]

Hello.

I'm trying to fix the really same problem as the original poster (thanks to).

At this link:

http://www.intel.com/support/network/sb/cs-006333.htm http://www.intel.com/support/network/sb/cs-006333.htm

I can find informations about the possibly corrected driver (version 17.1) but when I look for it here:

http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&keyword=%22Intel+82566+Gigabit+Ethernet+PHY%22 http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&keyword=%22Intel+82566+Gigabit+Ethernet+PHY%22

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?

Thanks.

[Mark_H_Intel]

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.

http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=21228 http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=21228

I hope this helps you.

Mark H

[idata]

Brilliant Mark, thank you.

[idata]

Hi, I have the same issue, I have tried the 17.1 driver (9.15.17.0) 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).

[idata]

Hi Mark,

unfortunately, I have to confirm what other users in this thread have already noted:

The 17.1 driver update (which comes with version 9.15.17.0 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,

Andreas

[Mark_H_Intel]

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 http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=2372 download the last software posted for the Intel® Desktop Board DQ965GF to get a copy of an earlier driver.

Mark H

The bug is still open, and if there is a driver change to fix this bug, I will post about it here.

[idata]

Hi Mark,

thanks a million for your quick reply, but I have to admit that I am somewhat stumbled about Intel's bugfixing policy...

You state that the bug has been reported formally ok and is therefore known about by your company and your development engineers.

I think that the severity of this bug: basically slowing down GbE devices to 100MBit IMHO deserves the highest bug priority, so I am completely lacking understanding why this bug does not make it on the list of bugs to be fixed in the next release.

What makes you so sure that this issue only affects "old" devices? Can we somehow increase the pressure to have this taken seriously, assigned a higher priority and be fixed (e.g. by complaining with motherboard or computer manufacturers)?

Base line: What can we do that this regression bug gets the level of attention that it deserves and will finally be fixed in an upcoming "e1e" version?

Looking forward to your comments...

Thanks again & best regards,

Andreas

[idata]

Hi Mark,

sorry for being such a pain in the neck, but let me restate that in my opinion, this issue is critical and MUST definitely be fixed in recent versions of the driver.

Is there any way to escalate this issue? Can you please give us (the people participating in this thread) the contact information of your manager and/or the person in charge of deciding about which bugs to be fixed in future releases?

Thanks & best regards,

Andreas

[idata]

OK - I see...

Can you please confirm that drawing a veil of silence around this issue seems to be the official strategy chosen by Intel?

Really disappointing...

BR,

Andreas

[Mark_H_Intel]

Hi everyone,

There is no veil of silence, but I do not have any news since /message/157816# 157816 my post on June 1. I will make it a point to post something when I know something more. Thank you for your patience.

Mark H

[idata]

Systems with these NIC's are entering their second life as we speak, buyers expect a system with a gigabit connection that simply works...

Tested with version PROSet 17.1 on both Windows Server 2003 SP2 and Windows XP x64 SP2 and found this issue to be present still...

Plus when using the 17.1 drivers at the auto negotiated 100Mbps Full Duplex I have the impression that the NIC is really slow in initiation, for example DHCP takes a dozen of seconds to obtain an address.

(When using static IP's there is no delay)

When using PROSet 13/14 I experience massive packet loss at gigabit speeds, only on these NIC's, other systems run fine at the same 1000Mbps speed, replacing cabling and switches doesn't make a difference.

I remember PROSet 13/14 running fine for many months at gigabit speeds but somehow that is not true anymore... do these NIC's electrically get worn out after time ?

I think I'm going to add a plug in adapter for now until some positive driver news appears...

[Mark_H_Intel]

@Tim

RE: I remember PROSet 13/14 running fine for many months at gigabit speeds but somehow that is not true anymore... do these NIC's electrically get worn out after time ?

A physical failure is possible, but I suspect some change in the registry or OS update would be a more likely culprit.

No driver update news yet.

Mark H