Description of problem: Update the latest e1000 driver to the latest upstream Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
*** Bug 451863 has been marked as a duplicate of this bug. ***
Are these updates in Andy's latest test kernel? If so we can test this as well.
Updating PM score.
*** Bug 452288 has been marked as a duplicate of this bug. ***
=Comment: #0================================================= Emily J. Ratliff <emilyr.com> - 2008-07-09 17:30 EDT 1. Feature Id: [201254] Feature Name: Intel ICH10 Support Sponsor: xSeries Category: Kernel Request Type: Kernel - Enhancement from Upstream 2. Short Description Intel ICH10 based systems will be available in the 2008/9 timeframe. More details on ICH10 are available from Intel. 3. Business Case Intel ICH10 based systems will be available in the 2008/9 timeframe. 4. Sponsor Priority 1 IBM Confidential: yes Code Contribution: 3rd party code Upstream Acceptance: Accepted Component Version Target: 2.6.25+ Performance Assistance: no 5. PM Contact: Monte Knutson, mknutson.com, 877-894-1495 6. Technical contact(s): Kevin Stansell, kstansel.com Chris McDermott, mcdermoc.com 7. LTC Manager: Julio Alvarez, julioa.com *** This bug has been marked as a duplicate of 451860 *** +++ This bug was initially created as a clone of Bug #436045 +++ Current RHEL4 e1000e driver does not support ICH9M (Montevina) and ICH10 LAN devices. Match upstream e1000e driver version once it has been updated for ICH9M and ICH10 support. Current RHEL4 does not support the new devices. 1. RUN RHEL4 on an ICH9M or ICH10 platform. Should work but won't since the driver won't recognize the device. Should just work. -- Additional comment from john.ronciak on 2008-03-04 18:45 EST -- Also to match the driver split that has happened upstream the e1000e driver needs to have the PCIe devices that are currently in e1000 and move that support to the e1000e driver. These devices are Ophir, Rimon, Tekoa and ESB2. These changes have already been accepted and implemented upstream. -- Additional comment from rpacheco on 2008-03-21 09:01 EST -- ICH9m is critical to the next Intel laptop architecture (Montevina) and the ICH10 is for the next generation of clients (and servers that use the LOM from ICH10). -- Additional comment from rpacheco on 2008-04-14 00:21 EST -- *** Bug 437322 has been marked as a duplicate of this bug. *** *** Bug 454809 has been marked as a duplicate of this bug. *** *** Bug 449774 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of 452288 *** Update the latest e1000e driver to the latest upstream *** Bug 451860 has been marked as a duplicate of this bug. *** *** Bug 451911 has been marked as a duplicate of this bug. *** *** Bug 452099 has been marked as a duplicate of this bug. *** The patches to 2.6.27 for this support has been pushed upstream as of today. These patches add ICH9m, ICH10 and Hartwell support to the driver. The changes should be picked up for RHEL5.3. *** This bug has been marked as a duplicate of 452287 ***
My test kernels have been updated to include a patch for this bugzilla. http://people.redhat.com/agospoda/#rhel4 Please test them and report back your results.
We tried the test kernel's with a new Dell Optiplex 760 and sadly the ethernet still fails to work using the test kernels 2.6.9-78.20, with e1000e entered in modprobe.conf Just a tiny thing this test kernel also required a manual "depmod -a" before it would find the e1000e module with modprobe at all. lspci lists it as: 00:19.0 Ethernet controller: Intel Corporation 82567LM-3 Gigabit Network Connection (rev 02) A hand built driver from Intel e1000e-0.5.8.2.tar.gz seems to work fine.
JohnR, Was your team ever able to test the kernel listed in comment #9 ?
We have not yet been testing 4.8 only 5.3 kernels. Once we get 5.3 out of our hair we will move on to 4.8.
Colin, I managed to remove all support for hardware during the backport process, but I fixed this up and will release new test kernels later this week. Thanks for bringing the problem to my attention.
Hi Andy, I'm helping Colin Simpson test this on the new Dell Optiplex 760 (ultra Small Form Factor) I downloaded your new test kernels and tested this morning, but sadly the machine now fails to boot when bringing up the network card, it just hangs hard. I also tried bringing up the network card manually in single user mode, and it produced a kernel panic with the final part of the output: <0>Kernel panic - not syncing: Oops Unfortunately, with no network access I am unable to provide the full dump at this time.
Gordon, that's not good news. I have some new test kernels available, but no promises that anything will be resolved with them. Until some more output is available from the panic there isn't much I can do to help. :-(
Created attachment 328333 [details] kernel messages from 2.6.9-78.23.EL.gtest.53 I tried booting your kernel off a sata disk on a Nahalem based pre GA server with ICH10 here in at IBM and am failing to mount root device. I am not certain whether this is a ICH10 support issue or where I am not picking up the right SATA driver because I can't set the native SATA mode set properly in the UEFI bios (the bios has some bugs). I attached the kernel boot messages for you too look at. BTW, the kernel string isn't what you expect because I had to rebuild the kernel to short circuit the serial port autoconfig. It is this kernel -- kernel-2.6.9-78.23.EL.gtest.53.src.rpm.
Just to be clear about what devices need to be added, they are ICH9m, ICH10 and Hartwell (82574). These are the same ones that are in the RHEL5.3 e1000e driver already.
My test kernels have been updated to include a patch for this bugzilla. http://people.redhat.com/agospoda/#rhel4 Please test them and report back your results. Without immediate feedback there is a good chance this or any other fix for this driver will not be included in the upcoming update.
Attempted to install the latest test kernels, but receive an MD5 digest error, not sure if this is on your end or just a corrupted download on my end? [root@760test ~]# rpm -Uvh kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm error: kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm: MD5 digest: BAD Expected(adaa29589cac1ff8f7a3e7d6d74b1920) != (340f42a1f9fb595c82b02acf6b6ea24c) error: kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm cannot be installed [root@760test ~]# md5sum kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm 2d5c7e3072d67782bf75b4b35df956ab kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm
Gordon, when I check the md5sum and sha1sums I get the following: $ sha1sum kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm 7c83c95c824fc43b9ec0fbed7d64c912a1173158 kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm $ md5sum kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm 6e12644679b382387637be5c83a2ad5f kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm The sha1sum when I compute this on my desktop matches what's posted at http://people.redhat.com/agospoda#rhel4 kernel-smp-2.6.9-78.25.EL.gtest.55.x86_64.rpm 7c83c95c824fc43b9ec0fbed7d64c912a1173158 so it was most-likely an incomplete download. Please download it again and let me know how it works for you.
(In reply to comment #18) > Created an attachment (id=328333) [details] > kernel messages from 2.6.9-78.23.EL.gtest.53 > > > > I tried booting your kernel off a sata disk on a Nahalem based pre GA server > with ICH10 here in at IBM and am failing to mount root device. I am not > certain whether this is a ICH10 support issue or where I am not picking up the > right SATA driver because I can't set the native SATA mode set properly in the > UEFI bios (the bios has some bugs). > > I attached the kernel boot messages for you too look at. > > BTW, the kernel string isn't what you expect because I had to rebuild the > kernel to short circuit the serial port autoconfig. It is this kernel -- > kernel-2.6.9-78.23.EL.gtest.53.src.rpm. Did you buy any chance install that kernel when running a non-RHEL4 kernel? I've seen issues when running newer kernels and installing a RHEL4 kernel since some of the driver names changed.
Hi Andy, The rpm was getting corrupted in some way on when transferring to a USB key to get it on the Dell Optiplex 760. However, that's another story. Managed to get the rpm on there with the correct sha1sum result, and the kernel installed fine. After a reboot, kudzu picked up the card, as before, although this time, the machine didn't lock, the card came up as expected, and as far as I can tell, is working just as it should! Thanks for your help on this, I really do hope it's in time for inclusion in the upcoming update.
Thanks for the testing, Gordon. It looks like that system has an 82567LM, so that that seems a reasonable indicator that this patch enabled your hardware. That card wasn't working before was it?
It does indeed have 82567LM-3. Originally on the RH4.7 kernel the card wasn't detected at all. Building the driver from intel manually worked though. Since then, your previous test kernels found the card, but paniced when it tried to bring the card up. I would say that a previous patch enabled the hardware, but the latest patch stopped the panic.
Committed in 78.29.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
~~ Attention Partners! ~~ RHEL 4.8 Partner Alpha has been released on partners.redhat.com. There should be a fix present in the Beta, which addresses this bug. If you have already completed testing your other URGENT priority bugs, and you still haven't had a chance yet to test this bug, please do so at your earliest convenience, to ensure that only the highest possible quality bits are shipped in the upcoming public Beta drop. If you encounter any issues, please set the bug back to the ASSIGNED state and describe the issues you encountered. Further questions can be directed to your Red Hat Partner Manager. Thanks, more information about Beta testing to come. - Red Hat QE Partner Management
~~ Attention Partners! ~~ RHEL 4.8Beta has been released on partners.redhat.com. There should be a fix present, which addresses this bug. Please test and report back results on this OtherQA Partner bug at your earliest convenience. If you encounter any issues, please set the bug back to the ASSIGNED state and describe any issues you encountered. If you have found a NEW bug, clone this bug and describe the issues you've encountered. Further questions can be directed to your Red Hat Partner Manager. If you have VERIFIED the bug fix. Please select your PartnerID from the Verified field above. Please leave a comment with your test results details. Include which arches tested, package version and any applicable logs. - Red Hat QE Partner Management
RHEL4.8 32-bit/64-bit (Alpha) was successfully installed and tested on an IBM iDataPlex dx360 with 4 SATA drives connected to the ICH10 interface.
Partners, this feature should be available in the RHEL 4.8 Beta, released recently on partners.redhat.com. IBM has confirmed it, but we're still waiting for additional results from the rest of you. Please test and provide feedback as soon as possible. There are only a couple more weeks of testing left.
~~ Attention Partners! Snap 2 *Kernel Only* Released ~~ RHEL 4.8 Snapshot 2 *kernel* has been released on partners.redhat.com. There should be a fix present, which addresses this bug. NOTE: there is only a short amount of time left to test, please test and report back results on this OtherQA Partner bug at your earliest convenience. If you encounter any issues, please set the bug back to the ASSIGNED state and describe the issues you encountered. If you have found a NEW bug, clone this bug and describe the issues you encountered. Further questions can be directed to your Red Hat Partner Manager. If you have VERIFIED the bug fix. Please select your PartnerID from the Verified field above. Please leave a comment with your test results details. Include which arches tested, package version and any applicable logs.
I was just able to reproduce this on a local system, so hopefully I will have some news shortly.
Created attachment 338586 [details] e1000e-reset-chip-when-taking-card-down.patch This patch fixes it on my system. Testing is greatly appreciated!
In which Snapshot will this patch be included? Thank you, Sandy
~~ Attention Partners! Snap 3 Released ~~ RHEL 4.8 Snapshot 3 has been released on partners.redhat.com. There should be a fix present that resolves this bug. If you encounter any issues, please set the bug back to the ASSIGNED state and describe the issues you encountered. If you have found a NEW bug, clone this bug and describe the issues you encountered. Further questions can be directed to your Red Hat Partner Manager. If you have VERIFIED the bug fix. Please select your PartnerID from the Verified field above. Please leave a comment with your test results details. Include which arches tested, package version and any applicable logs.
Committed in 88.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Partners, this issue should be resolved in the latest test packages, available in comment #50. Please test ASAP and report back.
Can the patches from upstream be listed in these BZ's that call for the driver to be updated to upstream? We understand that not all patches are needed but it's really hard to tell what is being pulled into these driver updates.
John, I've never been asked to keep track of specific commits, just to update to version a.b.c or 'latest upstream' so I typically take everything that isn't an upstream API change or adding a feature that isn't available in RHEL. This update goes up through this commit: commit 92af3e95e4896452ab33b1841c3e9a9d50658064 Author: Jesse Brandeburg <jesse.brandeburg> Date: Mon Jan 19 14:17:08 2009 +0000 e1000e: drop lltx, remove unnecessary lock If you want to check the differences, it would probably be best to check out a git tree at that point and then do a diff. You should see the differences are quite small. I've got some scripts that do my backporting (when I'm not just taking small cherry-picks) and I've recently added a feature to help try and track which commits I added or skipped. Unfortunately I don't expect to start publishing that information until 5.4 since I don't have any record before then.
From our testing this e1000e driver is missing support for the following device ID's: E1000_DEV_ID_82574LA 0x10F6 - the "Apple" MACPro ID for Hartwell E1000_DEV_ID_82583V 0x150C - Colleyville-V Both devices are supported upstream. Testing on the e1000e driver continues on this kernel on the supported devices.
OK, thanks Andy. In the future having a list of the commits pulled into the drivers during kernel updates would be a nice thing. We'll take a look at the changes doing a diff of the drivers. Thanks again. Please see the #55 comments on the missing devices.
*** Bug 491411 has been marked as a duplicate of this bug. ***
Committed in 89.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Intel, have you been able to confirm that the -89 kernel resolves the issues mentioned in comment #55?
I don't think that the ID were added. We'll check again but we should have a list of the devices that are expected to be in this release. I thought from Andy 's comment above that they were not going to be added.
We have confirmed that the device ID above in #55 are not in the e1000e driver in the latest kernel (snap 5). If RH does not want to included them they just need to make that statement. The OEM's are probably going to want at least the 0x150C ID since it's being included in a some low cost designs and NICs.
Created attachment 341226 [details] e1000e-device-id-add.patch John, I made sure the patch that included the ids in comment #55 were included in 4.8 and the patch appears to be included in 2.6.9-89. Please let me know if you were testing 2.6.9-89 and no support was there. Attached is the patch we added.
The device ID's are indeed included and preliminary tests show that the driver is passing traffic without problems. Tests have been started that will run across the weekend on the -89 kernel. We'll have another update on Monday. Thanks.
Thanks, John.
The tests ran over the weekend without error. So this looks to be fine at this point.
------- Comment From snmishra.com 2009-05-04 17:54 EDT------- Tests ran successfully on 89 kernel.
HP successfully verified with RC1.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1024.html