[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#303680: Debian Installer installation report

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

Attachment: signature.asc
Description: Digital signature

Reply to: