Stephen Powell wrote, on 2010-03-24 01:29:
On Tue, 23 Mar 2010 04:56:05 -0400 (EDT), Arthur Marsh wrote:
Stephen Powell wrote, on 2010-03-23 00:50:
OK, there are a couple of things to check. First of all, make sure
you have MODULES=most listed in /etc/initramfs-tools/initramfs.conf.
grep -v \# /etc/initramfs-tools/initramfs.conf|uniq
MODULES=most
BUSYBOX=y
KEYMAP=n
BOOT=local
DEVICE=eth0
NFSROOT=auto
Good.
Also check /etc/initramfs-tools/conf.d/driver-policy, if it exists.
$ ls /etc/initramfs-tools/conf.d/driver-policy
ls: cannot access /etc/initramfs-tools/conf.d/driver-policy: No such
file or directory
Good.
Generally, this file only exists if, during installation, you said
you wanted an initial RAM file system with only what is required
to boot the system. If this is the case,
/etc/initramfs-tools/conf.d/driver-policy will likely exist and
specify MODULES=dep. And that overrides what is specified in
/etc/initramfs-tools/initramfs.conf. Change
/etc/initramfs-tools/conf.d/driver-policy to specify
MODULES=most too. For now, do *not* list eata in
/etc/initramfs-tools/modules. Then re-run update-initramfs,
re-run lilo (if lilo is your boot loader), shutdown and
reboot. Let me know the results.
I ran:
update-initramfs -u -k 2.6.32-3-686
then rebooted with break=mount
cat /proc/modules
showed lots of modules but *not* eata.
What happens if you don't use break=mount?
Are you using dependency-based booting?
There are four ways I know of for a kernel module to get loaded during boot:
(1) The modules can be loaded by the kernel because they are referenced,
directly or indirectly, during the boot process. Whether these modules
need to be in the initial RAM filesystem or not depends on when
during the boot process they are referenced. If they are first referenced
before the permanent root filesystem is mounted, they need to be in
the initial RAM filesystem. If the first reference is after that point,
they don't.
(2) You can list them in /etc/initramfs-tools/modules and re-run
update-initramfs. This technique is used for modules which *must*
be explicitly loaded *before* the permanent root file system is mounted.
These modules must be in the initial RAM filesystem.
(3) The modules can be loaded by the hot-plug system. These modules are
loaded because an alias of the module matches an identification
sequence of the device. For example, on my IBM ThinkPad 600, module
snd_cs4236 is loaded because it has an alias, pnp:dCSC0000, that matches
an identification string for the ISA plug-and-play sound chip CS4237B.
A card's identification string can be listed by utilities such as
lspnp, lspci, lspcmcia, etc. There are two kinds of module aliases:
internal and external. Internal aliases can be listed by the modinfo
command. For example: "modinfo snd_cs4236". External aliases are
listed in one or more files in the /etc/modprobe.d directory. The
ACPI "discover" process can also load modules. This automatic loading
can be defeated by listing a module in a "blacklist" statement. For
example, on my IBM ThinkPad 600, I define the following two blacklist
statements in a file I call /etc/modprobe.d/local:
blacklist snd_cs4232
blacklist snd_wavefront
This tells the hotplug system to ignore the internal aliases of kernel
modules snd_cs4232 and snd_wavefront, which causes them not to be
loaded by the hotplug system, even though they both have an alias of
pnp:dCSC0000, which also matches my CS4237B sound chip. snd_cs4236
is the correct driver in my case; I don't need the other two.
This is the preferred method for loading kernel modules that are device
drivers for hardware devices. Whether they need to be in the initial RAM
filesystem or not depends on when the corresponding devices are detected.
Things like SCSI adapters, IDE controllers, etc. are generally probed for
*before* the permanent root filesystem is mounted, for obvious reasons.
Things which are not likely to be required to mount the permanent root file
system, such as sound chips, may be probed for afterward. Typically,
at this stage the permanent root file system is mounted read-only, but
has not yet been mounted read-write.
At the moment, I do not have access to a 2.6.32 kernel for the i386,
ia64, or amd64 architectures; but on a 2.6.26 kernel for i386 I issued
"modinfo eata" and it does not report any internal aliases. So
unless the module has an external alias defined in a file listed in
/etc/modprobe.d that matches an identification string for your SCSI
adapter, I would not expect it to be loaded automatically. On my IBM
ThinkPad 600, I created an external alias for the Mwave® 3780i Digital
Signal Processor (DSP) chip used by the internal modem so that the
corresponding kernel module, mwave, would be recognized as its device
driver:
alias pnp:dIBM3760 mwave
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]
(4) Finally, a module can be listed in /etc/modules. These modules will
be loaded *after* the permanent root file system has been mounted
read/write, but before any other filesystems (/home, etc.) have been
mounted. These modules do not have to be in the initial RAM filesystem.
So you have three options: (1) list eata in /etc/initramfs-tools/modules
and rebuild your initial RAM filesystem.
This is my present workaround. Workaround, not a solution since I
believe that any known PCI ids should have their device drivers
*automatically* loaded.
(2) you can define an external
alias for eata in a file in /etc/modprobe.d (and rebuild your initial RAM
filesystem, just in case). Obviously, if the kernel tries to load it
before mounting the permanent root file system then the module must be
included in the initial RAM filesystem.
I'm not sure why I should have to do this. There is only one possible
driver, eata, for the PCI id of the SCSI adaptor [1044:a400].
(3) list eata in /etc/modules.
This was what I was doing, but it no longer works.
Figure out which method works and use it. With no internal aliases and
no aliases defined in /etc/modprobe.d, I see no reason why the kernel
would load it automatically. eata has a dependency on scsi_mod, but
no module has a dependency on eata; so indirect loading won't happen
either.
Shouldn't the presence of a PCI device cause its driver to be loaded?
Regards,
Arthur.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/e88p77-4np....@ppp121-45-136-118.lns11.adl6.internode.on.net
