82579LM - Dev_1502 - DOS-Driver - DHCP-Problem

[idata]

For unattented system installation and imaging we are using a DOS bootdisk with NDIS2 drivers and TCP/IP-stack with DHCP usage.

We are using the E1000.DOS driver with the signature "Intel(R) Gigabit Network Connection Driver v5.67 111610".

This works fine for the following configurations:

PCI-Vendor-ID PCI-Device-ID PCI-Subsys-ID

8086 1502 833810F7

8086 1502 1495103C

8086 1502 161C103C

Now we just got a new notebook that has the network device VEN_8086\DEV_1502\SUBSYS_179B103C installed onboard.

With this hardware our bootdisk does not work. It times out when asking the DHCP-server for an IP-address.

There is a pre-installed Windows 7 on the notebook. Booting this operating system DHCP works just fine.

So this seems to be a DOS driver issue.

Using the latest DOS-driver with signature "Intel(R) Gigabit Network Connection Driver v5.79 041912" did not change the behaviour.

Capturing the network traffic showed that the ethernet card send a DHCP-request-packet. After this the DHCP-server answered with an DHCP-offer-packet. But the ethernet device seems not to recognize the answer and sends out another DHCP-request after waiting a couple of seconds gets a new DHCP-offer in return and ignores it again. This happens a couple of times before the TCPTSR.EXE-program times out. So everything happens according to the DHCP-specification asides from the ethernet device ignoring the answers.....

Does anybody have an idea what I can do about it?

[idata]

Hi,

just to say that we second that.

Nothing to add technically speaking, we observed exactly the same behavior here.

Regards,

Michel.

[idata]

Correction: our PCI-Subsys-ID is 17A7103C (in HP's Elitebook 8570p)

[idata]

Exactly the same problem here...

DHCP offers are ignored!

HP Elitebook 8570w (PCI Subsys ID 17AA103C) with Intel Gigabit Network Connection Driver v5.81 072012 (e1000.dos)

[idata]

Intel just released the "Intel Ethernet Connections CD" version 17.4.

There is a DOS-driver with the signature "Intel(C) Gigabit Network Connection Driver v5.81 072012" included.

That is the driver Ulli already mentioned.

I just tried this and it did NOT work for me as well.

Our problem is not even listed in the "known problems"-section of the readme-file.

[idata]

Ok, so did anybody submit a defect report to Intel so that they are aware of the problem?

[idata]

How can I do this?

I could not find a possibility to request support from Intel for end-users.

[idata]

Same for me, I also don't know the way to do it.

[Douglas_B_Intel]

Hi this is Doug at the factory. We've started a support case on this issue and we will let you know what we figure out. Thanks for your patience and thanks for using Intel Ethernet.

[idata]

Hi Doug, any news on this?

My problem is that I have to clone 300 HP PCs with this problem in about two weeks.

Any chance to get a working version of this driver?

[idata]

+1 on this issue. All our new HP computers don't work with our time-tested imaging solution. We've traced the problem to this driver, but have no solution.

[Douglas_B_Intel]

Doug from the factory here with an update on the DOS driver not getting DHCP replies on some systems.

First of all, thanks for everyone's patience and willingness to share details on the issue.

Second, we believe we have root cause. The interrupt environment in the DOS is very old. Lots of DOS components don't like sharing interrupts. In this case, that sharing is causing the issue. On the platforms we tested with, if the LAN was on a separate IRQ from other devices, it would work fine. But if it was shared, that was the when the issue would be seen. There is a device interrupt handler that was not forwarding the interrupt to our driver when the two share the same IRQ line.

That's all the good news. The less good news is that the solution to this needs to be in the BIOS. The driver can't change the IRQ handler chain and if the device that eats our HW interrupt gets before us, we're done. So the BIOS has to set the IRQs separately so everyone can play nice. We've been working with the OEM partner to have an updated BIOS, but things like timing and availability is up to them. Furthermore the release of the solution is up to them, they might not elect to release it on all platforms. So please, if you have this issue, consult with your HW provider, and hopefully soon you'll have a new BIOS that makes this issue go away.

Thanks for using Intel® Ethernet, and if you have questions about this issue, I'll keep my eye on the thread and will post answers when I can.