![]() | |||||||||||
Messages in this thread |
* Brandeburg, Jesse <jesse.brandeburg@intel.com> wrote: > your expectation is that e1000 once loaded on this device in a > previous kernel (2.6.24) so it should continue to work, right? [...] correct. > > 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. there should be no need for me to set something that the kernel can do itself as well ... > If there is a more reasonable solution you can come up with I am > interested. i think the solution is obvious and simple: if e1000 is built-in then e1000e should not be allowed to be a module. (i.e. it should either be built-in in which case it will handle the PCI IDs, or it should be disabled - in which case e1000 will handle them.) that way e1000e can take over the PCI IDs but we'll never get a non-working system, which takes an hour for a kernel hacker to figure out. The failure was totally silent. eth0 didnt show up at all. Btw., a sidenote: this is another generally annoying property of Linux: there's no easy and user-visible enumeration of PCI IDs (devices) that we _could_ support but dont enable for some reason. It is a royal PITA to track down when some driver decides to (silently) ignore a piece of hardware. Having a seemingly dead piece of hardware component is one of the most frustrating user experiences possible - the first instinctive reaction is "did my hw break???". The kernel should proactively know about all inactive pieces of hardware and should have a one-stop-shop for users where they can reassure themselves which devices are not active and why. Ingo | ||||||||||
| Last update: 2008-04-08 22:03 [from the cache] ©2003-2008 | |||||||||||