Messages in this thread | | | Subject | RE: [regression] e1000e broke e1000 (was: Re: [ANNOUNCE] e1000 toe1000e migration of PCI Express devices) | Date | Tue, 8 Apr 2008 12:43:00 -0700 | From | "Brandeburg, Jesse" <> |
| |
Auke is out sick, so I'm responding...
Ingo Molnar wrote: > this is a simple bzImage kernel, no modules at all. Here's the full > regression report:
then why are you compiling e1000e as a module? no "=y" in your kernel means no support, and this kernel .config has e1000e supporting your hardware.
your expectation is that e1000 once loaded on this device in a previous kernel (2.6.24) so it should continue to work, right? I see your point but we are trying to make general improvements to both drivers, and the best way forward was a split, in order to make the user experience better by eliminating chances for regressions on older hardware.
> v2.6.25-rc8 regresses relative to v2.6.24, with the following config, > which config works fine in v2.6.24:
> the eth0 interface is not detected at all: > http://redhat.com/~mingo/misc/dmesg.e1000.bad
if you're running a no module kernel, you'll need to set CONFIG_E1000E=y for your device to be detected.
> so the pure presence of the e1000e module breaks the e1000 driver. > That > is a regression and a bug that should be fixed.
The device IDs moved to e1000e, we don't want collisions between drivers that support the same IDs, so to avoid those user support issues, we're trying to make the process as painless as possible with announcements and time. The distros are already including the e1000e driver in their builds and new installs with the new ID layout will automatically select the correct driver for their hardware.
Users that take an upgrade to their kernel (with e1000e enabled) might benefit if the distro upgrading that kernel included a post upgrade script that migrated e1000e devices previously using e1000 in modprobe.conf to alias ethX e1000e
If there is a more reasonable solution you can come up with I am interested.
Jesse
| |