[Linux] The Linux 2.4 SCSI subsystem HOWTO - Mid Level, Unifying layer

Chapter 8. Mid Level, Unifying layer

Table of Contents

8.1. boot parameters

8.2. module parameters

8.3. proc interface

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.]

8.1. boot parameters

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 [1] .

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 scsi_allow_ghost_devices=<n> where (<n> - 1) is the maximum lu number to ghost if the the corresponding device is offline. When <n>==0 (default) then don't ghost any devices (in lk 2.4.26 and later) 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"). [2] [3] 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 .

Notes

[1]	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).
[2]	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).
[3]	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.

8.2. module parameters

If SCSI disks are present in the system then it usually is better to build the mid level driver into the kernel. However if the SCSI subsystem is only being used periodically (e.g. to burn CD-Rs on an ATAPI CD writer) then building the mid level as a module is fine. The module load time options are the same as the driver's built in options:

scsi_logging_level=<n> where <n> is the logging level mask (0 for logging off) max_scsi_luns=<n> scsihosts=host0::host2 scsi_allow_ghost_devices=<n>

8.3. proc interface

To display the SCSI devices currently attached (and recognized) by the SCSI subsystem use cat /proc/scsi/scsi.

The output looks like this:

Attached devices: Host: scsi0 Channel: 00 Id: 02 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: IBM Model: DNES-309170W Rev: SA30 Type: Direct-Access ANSI SCSI revision: 03

After the "Attached devices:" line there are 3 lines for each recognized device. The first of these lines is SCSI address information discussed in Section 3.1. The following 2 lines of data are obtained from a INQUIRY command that was performed on the device when it was attached. See Section 9.4 for the relationship between the ordering of these devices compared with the sg driver's ordering (which most of the time is the same).

Existing devices can be removed using echo "scsi remove-single-device <h> <b> <t> <l>" > /proc/scsi/scsi where the variables are host, bus (channel), target (scsi id) and lun. The success (or otherwise) of this command can be determined by sending a subsequent cat /proc/scsi/scsi command. The removal will fail if the device is busy (e.g. if a file system on the device is mounted).

New devices can be added using echo "scsi add-single-device <h> <b> <t> <l>" > /proc/scsi/scsi where the variables are host, bus (channel), target (scsi id) and lun. The success (or otherwise) of this command can be determined by sending a subsequent cat /proc/scsi/scsi command. [1]

The SCSI subsystem does not support hot-plugging of SCSI devices (there may also be electrical issues on the associated SCSI parallel bus). It is recommended that those who use add+remove-single-device make sure that other devices on that SCSI bus are inactive if re-plugging is going to take place.

To output a list of internal SCSI command blocks use echo "scsi dump <n>" > /proc/scsi/scsi where the numeric value of <n> doesn't matter. This is probably only of interest to people chasing down bugs within the SCSI subsystem.

To start (or stop) logging information being sent to the console/log use echo "scsi log <token> <n>" > /proc/scsi/scsi where <token> is one of: {all, none, error, timeout, scan, mlqueue, mlcomplete, llqueue, llcomplete, hlqueue, hlcomplete, ioctl} and <n> is a number between 0 and 7. The tokens "all" and "none" don't take an <n> argument. Prefix meanings:

hl upper level drivers [exception: sg uses "timeout"] ml mid level ll lower level drivers [adapter drivers often have there own flags]

The value "0" turns off logging while "7" maximizes the volume of output. Logging information will only be output if CONFIG_SCSI_LOGGING was selected in the kernel build.

Warning: "scsi log all" (and several other variants) can cause a logging infinite loop if the log file (typically /var/log/messages ) lies on a SCSI disk. Either turn off the kernel logging daemon or direct its output to a non SCSI device.

Notes

[1]	The parsing of "add-single-device" and "remove-single-device" is rather inflexible. Hence it is best to stay close to the demonstrated syntax with no extra spaces (and no tabs).