Basically, the baremetal F8 kernel has an e1000e driver which is needed to support the NIC on the ICH9 chipset on newer Intel machines. Currently, the driver is added by the patch-2.6.24-rc1 patch. It'd be very useful if kernel-xen also supported this NIC.
A test package was built on Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=239874 I have included the e1000e patch from RHEL-5, with small modifications due to API changes between 2.6.18 and 2.6.21.
I see that -2952 (a later build) was released for F8 without this update. Is an update for F8 incorporating this patch anticipated?
Well, no updates since the test package in November, and no response to my ping from Eduardo. I have build a working variant of -2952 that applies the e1000e patch from RHEL-5, and all of the subsequent e1000e patches (-05 and onward) from the 2.6.23 kernel. This necessitated a one-off patch of my own to delete an unnecessary header include. In addition, the SOURCES/kernel-2.6.21-i686-xen-config file must be hand-edited to add CONFIG_E1000E=m in the obvious place. My patch and the revised spec file are attached (or will be momentarily). You'll need to pull the 2.6.23 -05 through -10 patches from the *current* source RPM, or if it's easier you can pull the full SRPM from our repo and re-extract them (they are unchanged). The SRPM is at http://www.eros-os.com/coyotos/8/SRPMS. My patch is just a refinement of Eduardo's. It's an improvement, but Eduardo's patch does work. Given which, and given the successful build on Koji, why has this bug become stalled?
Created attachment 290421 [details] Removes unneeded include of delay.h so that the -05 patch from 2.6.23 will apply cleanly.
Created attachment 290423 [details] Revised spec file applying previous patch and selected patches from 2.6.23 You'll need to pull the -05 through -10 e1000e patches from 2.6.23, but they will apply cleanly. Build will also require adding CONFIG_E1000E=m in the obvious place in the xen config file. Note that you will probably want to remove my change to localid... SRPM copying to our public repo now. I'll post a comment here when it has uploaded.
(In reply to comment #3) > Well, no updates since the test package in November, and no response to my ping > from Eduardo. Sorry, I thought I had replied to your comment. The packages I have built had problems related to tx checksum offload. That's why the package wasn't sent to F8 updates yet. > > I have build a working variant of -2952 that applies the e1000e patch from > RHEL-5, and all of the subsequent e1000e patches (-05 and onward) from the > 2.6.23 kernel. This necessitated a one-off patch of my own to delete an > unnecessary header include. In addition, the > SOURCES/kernel-2.6.21-i686-xen-config file must be hand-edited to add > CONFIG_E1000E=m in the obvious place. > > My patch and the revised spec file are attached (or will be momentarily). You'll > need to pull the 2.6.23 -05 through -10 patches from the *current* source RPM, > or if it's easier you can pull the full SRPM from our repo and re-extract them > (they are unchanged). The SRPM is at http://www.eros-os.com/coyotos/8/SRPMS. > > My patch is just a refinement of Eduardo's. It's an improvement, but Eduardo's > patch does work. Given which, and given the successful build on Koji, why has > this bug become stalled? Because of the checksum problems that were reported. However, disabling this feature on the Fedora package should be simple.
No problem -- I'm overloaded too, and balls get dropped. Concerning the checksums, I can't really help. The patch I did is a hack and slash job without any real examination of the driver, because I needed something working immediately. I'm not familiar with the tx checksum offload issue(s). Bottom line is that I needed something that worked right now, so I've basically put an update on the Coyotos repository that replaces the Fedora -2952 on my clients' machines. The update should (in theory) in turn be replaced by your next release. If the tx checksum offload issue can be solved by disable, I think it would be good to release a package that does that. A suboptimal, functional package is better than none, and the commodity ICH9 machines at the moment are VERY nicely configured to serve as Xen boxes.
Okay, I tried Eduardo's RHEL5 backport and my own backport of latest upstream, neither of which worked. Finally, I got a backport of e1000e from the latest F8 2.6.23 bare-metal kernel to work. So, fixed in rawhide with kernel-xen-2.6-2.6.21.7-2895.fc9 Jonathan: if you could test the F-8 build and confirm it works for you, then I'll push an update with it: http://koji.fedoraproject.org/koji/buildinfo?buildID=36433
kernel-xen-2.6-2.6.21.7-2.fc8 has been submitted as an update for Fedora 8
kernel-xen-2.6-2.6.21.7-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.