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
Attachment:
signature.asc
Description: Digital signature