Re: SCSI module eata no longer loading automatically from initrd on Sid on i386
Stephen Powell wrote, on 25/03/10 02:47:
On Wed, 24 Mar 2010 07:05:13 -0400 (EDT), Arthur Marsh wrote:
Why shouldn't the eata driver be loaded once the PCI bus has been
scanned and a device that the eata driver knows about [1044:a400] in
this case is detected?
00:08.0 SCSI storage controller [0100]: Adaptec (formerly DPT)
SmartCache/Raid I
-IV Controller [1044:a400] (rev 02)
Flags: bus master, medium devsel, latency 160, IRQ 11
BIST result: 00
I/O ports at d400 [size=32]
Expansion ROM at ee000000 [disabled] [size=32K]
Because the hotplug system doesn't know that eata is the driver for this
board. Once the eata driver gets loaded, it can detect that the board
supports the EATA/DMA protocol, and therefore it grabs the board.
But the driver has to get loaded first.
...
debian:~# modinfo eata
filename: /lib/modules/2.6.26-2-686/kernel/drivers/scsi/eata.ko
description: EATA/DMA SCSI Driver
license: GPL
author: Dario Ballabio
depends: scsi_mod
vermagic: 2.6.26-2-686 SMP mod_unload modversions 686
parm: eata: equivalent to the "eata=..." kernel boot option.
Example: modprobe eata "eata=0x7410,0x230,lc:y,tm:0,mq:4,ep:n" (string)
----------
Do you see the difference? There are no "alias" entries for this module.
For whatever reason, the author/maintainer of the eata module elected
not to define internal aliases for each board that the driver supports.
I'm guessing that this is because there are so many boards that the driver
supports that maintaining the list would be a never-ending job. Also,
some of the boards may be better supported by a more hardware-specific driver,
and if the eata module listed the board then the hotplug system would load
both drivers: the specific one for that board and eata. And the two
drivers would interfere with each other.
I actually don't think any of those cases apply. Although there were
several models of SCSI adaptors from DPT, they are no longer made and
only the eata driver provided support for the DPT SCSI adaptors.
...
The mwave driver was written before Linux had a
hotplug system, and IBM didn't bother to go back and add the alias
retroactively.
This may have been the case. I have not found anyone using the eata
driver recently.
In the case of eata, the best way to handle the situation is to
create an external alias.
What I would do is to create a file called /etc/modprobe.d/local. In it
I would put the following statement:
alias pci:v00001044d0000A400* eata
Then, remove the "eata" entry from /etc/initramfs-tools/modules.
Also make sure that eata is not listed in /etc/modules. Then,
run update-initramfs again. Check to make sure that the eata module is
still included in your initial RAM filesystem. Re-run lilo, if you're
using lilo, then shutdown and reboot. If I have the syntax right for
the alias command above, the hotplug system should load the eata module
at the proper time for SCSI adapter device drivers to be loaded, but
only if the card is actually found in the system. If you were to
shutdown, remove the board, and boot again, the eata driver would not
be loaded, since the board was not found. In this sense, it is
automatic. (But only after you define the external alias.)
Yes, this worked thanks.
I'm not sure if the "A" in the device id needs to be upper case or
lower case. Based on the vendor id for the 3w-9xxx driver, which
uses an upper-case "C", I assumed upper case. You might have to
experiment a little to get a correct match.
If you want to file a bug report that the eata driver should define
an internal alias for every board that it supports, you can give it
a try. But I'm not holding my breath. Good luck. ;-)
I'll post something to linux-scsi then (-:.
Regards and thanks for all the help and explanations,
Arthur.
Reply to: