Ian Bruce wrote: > It turns out that in the mkinitrd script there is a function called > "print_ide_modules()" which is responsible for most of the contents of > this "loadmodules" file. It doesn't appear to do any kind of hardware > detection. It just runs "find" on the > /lib/modules/<version>/kernel/drivers/ide/pci directory, the output of > which depends only on the order that the files in that directory were > originally copied into it. > > Notice that both of the lists you quoted are (mostly) alphabetically > ordered, the first in reverse. This is undoubtedly a result of modules > being copied into various directories in that order; "for x in *" would > do it. The implication is that neither the installer nor mkinitrd is > particularly concerned about the order in which IDE modules are loaded.
Right.. I should have said that the installer tries to match the load
order of the installed system within blocks for a single subsystem --
things like loading ethernet interface modules in the same order, and
loading ide-core after all the pci ide chipset drivers. Necessities of
the installation may result in it loading network modules before ide
drivers or the like.
Here's a reworking of Frans's lists that may make this more clear:
installer reboot
--------- ------
(ethdetect)
3c59x (unsure what part of the initrd loads these)
vesafb
fbcon
unix
(hw-detect)
(pci ide chipset drivers) (pci ide chipset drivers)
piix pdc202xx_new
via82cxxx adma100
trm290 aec62xx
triflex alim15x3
slc90e66 amd74xx
sis5513 atiixp
siimage cmd640
serverworks cmd64x
sc1200 cs5530
rz1000 cy82c693
pdc202xx_old generic
pdc202xx_new hpt34x
opti621 hpt366
ns87415 ns87415
hpt366 opti621
generic pdc202xx_old
cy82c693 piix
cs5530 rz1000
cmd64x sc1200
cmd640 serverworks
amd74xx siimage
alim15x3 sis5513
aec62xx slc90e66
adma100 triflex
trm290
via82cxxx
(misc others) (misc others)
ide-detect ide-detect
ide-disk ide-disk
(cdrom-detect)
cdrom
ide-cd
isofs
BTW, you're right that there's a high correlation between the order the
modules are on disk/ramdisk and the load order for the pci ones, since we do
use find. The reversal of the order is interesting; they're in the udeb
in the same order that find finds them on disk from the kernel package.
Also, the correlation is not perfect, somehow piix is loaded first instead
of later by the installer (unless you loaded piix first by hand).
> > In this case the problem could well be the reversed load order of the
> > piix and generic modules.
>
> I tried hacking the mkinitrd script to reverse the relative order of
> these two modules, and I also tried eliminating all the other IDE
> modules except those. Neither change fixed the problem.
>
> modprobe -k vesafb > /dev/null 2>&1
> modprobe -k fbcon 2> /dev/null
> modprobe -k unix 2> /dev/null
> modprobe -k piix > /dev/null 2>&1
> modprobe -k generic > /dev/null 2>&1
> modprobe -k ide-detect
> modprobe -k ide-disk
So it's not an ordering problem at all..?
> The installation floppies still have no difficulty at all with this
> hardware. What file on them controls module loading? Perhaps some module
> parameters are required? I could change mkinitrd to produce exactly the
> same module load order as during installation, but it's not clear
> to me that this will work either. Any suggestions?
Most module loading, except for a few exceptions such as getting the
frame buffer and essential acpi stuff loaded as the installer boots, is
performed by /bin/hw-detect. We don't pass any parameters to ide pci
modules unless the user tells us to (in expert mode). ide-detect and
ide-disk don't get any special params by default either.
--
SEE Shy jo
signature.asc
Description: Digital signature
