just to say that we second that.
Nothing to add technically speaking, we observed exactly the same behavior here.
Correction: our PCI-Subsys-ID is 17A7103C (in HP's Elitebook 8570p)
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)
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.
Ok, so did anybody submit a defect report to Intel so that they are aware of the problem?
How can I do this?
I could not find a possibility to request support from Intel for end-users.
Same for me, I also don't know the way to do it.
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.
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?
+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.
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.