Bug#334104: RFC: workaround for dmfe/tulip module problem

[Richard Mortimer <richm@oldelvet.org.uk>]

On Wed, 2006-11-29 at 21:29 -0800, Jurij Smakov wrote:
> Hi,
> 
> The issue of dmfe and tulip drivers advertising support for the cards 
> with the same PCI IDs has popped up recently again [0]. As some of the 
> cards work with dmfe driver (mostly on x86), and some work with tulip 
> (on sparc Netra machines, for example), the issue cannot be resolved 
> by simply removing the duplicate PCI IDs from one of the drivers, as I 
> initially thought. To provide some kind of workaround for it, I 
> propose to patch dmfe and tulip drivers, introducing a 'disable' 
> parameter, which can be used to prevent the particular module from 
> taking over hardware. d-i currently has a mechanism to supply the 
> options to the modules using kernel boot parameters, so the user may 
> disable the unwanted module without starting a shell and manually 
> mucking with module loading and unloading.
> 
> The patch (attached) is really straightforward, and is unlikely to 
> cause any regression. I don't have access to the dmfe or tulip 
> hardware, so I would appreciate if you could test it on the 
> affected machines (particularly, the disabling feature), and report 
> back.
> 
I've tried this and it seems to be a non-starter. It works fine when I
use it on the modprobe commandline

pingu:/sys/module/dmfe# modprobe dmfe disable=1
dmfe: driver disabled, aborting initialization.

but when I boot with dmfe.disable=1 on the commandline the driver gets
loaded.

pingu:/sys/module/dmfe# cat /proc/cmdline
root=/dev/hda7 ro dmfe.disable=1


Built 1 zonelists
Kernel command line: root=/dev/hda7 ro dmfe.disable=1
Unknown boot option `dmfe.disable=1': ignoring
...
dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
hda: ST320423A, ATA DISK drive
ide0 at 0x1fe02010200-0x1fe02010207,0x1fe0201020a on irq 5,7cc
hdc: ST320423A, ATA DISK drive
ide1 at 0x1fe02010210-0x1fe02010217,0x1fe0201020e on irq 5,7cc
eth0: Davicom DM9102 at pci0000:00:05.0, 00:00:00:00:00:00, irq 7418560.
eth1: Davicom DM9102 at pci0000:00:0c.0, 00:00:00:00:00:00, irq 7417856.
Linux Tulip driver version 1.1.13-NAPI (May 11, 2002)
hda: max request size: 128KiB


If I look the kernel documentation in
Documentation/kernel-parameters.txt it says


Module parameters for modules that are built into the kernel image
are specified on the kernel command line with the module name plus
'.' plus parameter name, with '=' and value if appropriate, such as:

        usbcore.blinkenlights=1


I tried building the kernel with dmfe and tulip built in and that
happily accepted the dmfe.disable=1 and brought the system up with the
correct (tulip) driver loaded.

...
dmfe: driver disabled, aborting initialization.
Linux Tulip driver version 1.1.13-NAPI (May 11, 2002)
tulip0: Old style EEPROM with no media selection information.
tulip0:  MII transceiver #1 config 1000 status 7809 advertising 01e1.
eth0: Davicom DM9102/DM9102A rev 49 at 000001fe02010100, EEPROM not
present, 08:00:20:F8:35:86, IRQ 7475904.
tulip1: Old style EEPROM with no media selection information.
tulip1:  MII transceiver #1 config 3100 status 7829 advertising 01e1.
eth1: Davicom DM9102/DM9102A rev 49 at 000001fe02010000, EEPROM not
present, 08:00:20:F8:35:85, IRQ 7475200.
...


Thus for your patch to work the tulip and dmfe drivers would need to be
compiled in statically rather than as modules.

Thanks

Richard


-- 
Richard Mortimer <richm@oldelvet.org.uk>