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 flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Attachment:
signature.asc
Description: Digital signature