On Thu, Dec 06, 2007 at 06:39:08PM +0100, Frans Pop wrote: > On Thursday 06 December 2007, Florian Lohoff wrote: > > This is the very same problem as #360699 reported which was closed. > > Because it is not a problem we can solve in the installer, nor is it > apparently a problem that can be solved in the kernel: there are two series > of different, partially incompatible hardware which use the same PCI IDs...
Reading only 0's from an eeprom in the driver can be detected. Why cant the dmfe driver refuse to load (or better not claim the resources) in this case? It used to be the case for hundrets of isa modules that they were loaded, tried if their hardware was there and later if not just notified that they failed to load. I know - these were the old days and we are now pleased with an in kernel module loader and all that fancy stuff but can't this be done ?!? It might mean to really rewrite a little of module init logic and not really look at the chip at ifup time. My guess is that nobody until now was annoyed enough to actually write the code :) > > Unloading dmfe.ko and loading tulip.ko (and removing dmfe.ko to > > dismiss further loading) helps ... > > This is documented in: > http://www.debian.org/releases/etch/sparc/ch02s06.html.en#nics-sparc-trouble > > An easier way to prevent loading dmfe.ko is to boot the installer > with 'install dmfe.blacklist=yes'. This is already documented in the > development version of the installation guide: > http://d-i.alioth.debian.org/manual/en.sparc/ch02s06.html#nics-sparc-trouble Thanks for the hint Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
signature.asc
Description: Digital signature
