On Fri, Apr 08, 2005 at 02:25:45PM -0400, Joey Hess wrote: > Steve Langasek wrote: > > > According to entries in discover1-data, the de4x5 module should indeed > > > be loaded for that hardware. > > Hmm, that's not good to hear, given the outcome of 294867: it appears that > > the de4x5 module should be removed from the kernel build altogether. Not > > before sarge of course, but hotplug has already been changed to always use > > the tulip module instead -- this could make for some irritating bugs if d-i > > uses a different module than the one hotplug loads for stage 2, no? > FWIW, there is already a de4x5 hack in hw-detect; if we remove the de4x5 > module from any given d-i kernel udebs and tulip is available, then > hw-detect will use tulip instead of de4x5 and blacklist de4x5 to prevent > discover ever loading it. We've only used the hack on hppa so far. I'd > rather see de4x5 dropped or discover changed not to load it, so we could > remove this hack though. > There are, however, some other reports of de4x5 working with hardware > where tulip does not: > 273265: tulip loads but does not work for pci id 10110002 (DECchip 21040) At least this one is a report against RC1, which IIRC didn't use 2.4.27, yes? I have this same chip; in previous 2.4.2x kernels tulip did not work for me, and in 2.4.27 it does. It would be good if we could get the original submitter to test with 2.4.27 as well. > Of course 10110009 is the same pci ID as in this report, although the > one in this report also claims to be a "FasterNet". Unless de4x5 > has somehow stopped working between 2.4.26 and 2.4.27 for the same > hardware, I don't know what to make of that. Different hardware with the > same PCI id? There were multiple revisions of most of these, so it could be. These are also common on alpha systems, so there could be differences in how well each driver works on x86 vs. alpha. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature