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) 267302: tulip loads but no link for pci id 10110019 (DECchip 21142/43 rev 30) 265556: tulip loads but no link for pci id 10110009 (DECchip 21140) 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? -- see shy jo
signature.asc
Description: Digital signature
