Table of Contents
The SCSI mid level is common to all usage of the SCSI subsystem. Probably its most important role is to define internal interfaces and services that are used by all other SCSI drivers. These internal mechanisms are not discussed in this document [see ref: W2].
The primary kernel configuration parameter "CONFIG_SCSI" determines whether the mid level is built in (when "=y") or a module (when "=m"). If "CONFIG_SCSI=m" then all other SCSI subsystem drivers must also be modules.
When the mid level is built as a module then it probably never needs to be loaded explicitly because using 'modprobe' to load any other SCSI subsystem module will cause the mid level to be loaded first (if it is not already).
Some upper and lower level drivers do not (fully) load if there are no devices for that driver to control. Sometimes the report is loud as in this case for the imm driver which controls zip drives connected to a parallel port:
$ modprobe imm imm.o: init_module: No such device
lsmod will not show the "imm" module as loaded. In other cases the result is more subtle. For example, if the sg driver is loaded in a system with no (real or pseudo) scsi devices then the /proc/scsi/sg directory will not appear. [It will be created when the first scsi device is recognized.]
SCSI drivers that are built into the kernel are checked in a pre-determined order to see if HBAs that they can control are present. The user has no control over this order which in most cases is arbitrary but in the case of some older ISA adapters is required to stop misidentification [6] .
scsi_logging=<n>
where <n> is 0 to turn logging off
where <n> is non-zero to turn logging on
max_scsi_luns=<n>
where <n> is a number between 1 and 8 (< lk 2.4.7),
>= lk 2.4.7 the upper limit can be much larger
scsihosts=host0:hosts1::host3
The recently introduced devfs defines a "scsihosts" boot time parameter to give the user some control over this. See the devfs documentation [ref: W5] for a description. The host names given in the list to the "scsihosts" boot option are the names of lower level drivers (e.g. "scsihosts=advansys:imm::ide-scsi"). [7] [8] Devfs does not need to be present for "scsihosts" to be used. The "scsihosts" parameter, if given, is echoed during in the boot up messages. For example:
scsi: host order: advansys:imm::ide-scsi
Also if multiple HBA are present in a system then they are scanned in a fixed order (see footnote). The "scsihosts" parameter only effects how these HBAs are indexed (i.e. which SCSI adapter numbers are associated with them by the kernel). In the above example, if the "imm" driver is not found during boot up, then the scsi adapter number "1" is not allocated. If the "imm" driver is later loaded as a module, then it will adopt scsi adapter number "1". If a driver that is not named in "scsihosts" is found, then it will get the next available scsi adapter number (e.g. a built in aic7xxx driver would get scsi adapter number "2" in the above example).
A full list of kernel parameters with some explanations can be found in the file /usr/src/linux/Documentation/kernel-parameters.txt .
[6] PCI adapters are much "safer" for initialization code than the older ISA adapters. Hence the order of initialization of PCI adapters is unlikely to lead to lockups. In this case the order of initialization (and thus SCSI adapter numbers) of built in drivers may be modified by changing the order of entries in the SCSI subsystem Makefile ( /usr/src/linux/drivers/scsi/Makefile). Beware: some adapters may be recognized by more than one lower level driver (e.g. those based on NCR chipsets).
[7] Either comma or colon can be delimiters for "scsihosts". This means that "scsihosts=advansys,imm,,ide-scsi" is also valid. Also if a machine's boot sequence involves an "initrd" stage (look in /etc/grub.conf or /etc/lilo.conf to find out if this is the case), then the mkinitrd command should be run after a change to the "scsihosts" boot time parameter. This will generate a new initrd image that needs to be put in the correct place (most probably in the /boot directory).
[8] Using "scsihosts" can lead to a situation in which the computer's BIOS finds the boot track (and hence boot time parameters set in lilo or grub) on one disk while the kernel finds the root partition on another disk. This can be quite confusing when it is unplanned. Hence after changing (or adding) "scsihosts" in lilo or grub's configuration, it may be wise to boot the machine to see which disks are accessed.