Tue Feb 21 15:56:25 CST 2006 HBA driver distribution for Red Hat Enterprise Linux AS release 3 (Taroon Update 2) Driver versions contained herein: aacraid-1.1.5.2418 for 2.4.21-15.EL aacraid-1.1.5.2418 for 2.4.21-15.0.4.EL aacraid-1.1.5.2418 for 2.4.21-20.EL aacraid-1.1.5.2418 for 2.4.21-20.0.1.EL aacraid-1.1.5.2418 for 2.4.21-27.EL aacraid-1.1.5.2418 for 2.4.21-27.0.4.EL aacraid-1.1.5.2418 for 2.4.21-32.EL aacraid-1.1.5.2418 for 2.4.21-32.0.1.EL aacraid-1.1.5.2418 for 2.4.21-37.EL If you do not wish to install the binary object modules provided in this package, you may instead use the source RPM to build the binaries on your system. The kernels and variants of each supported by this RPM are: 2.4.21-15.0.4.EL 2.4.21-15.EL 2.4.21-20.0.1.EL 2.4.21-20.EL 2.4.21-27.0.4.EL 2.4.21-27.EL 2.4.21-32.0.1.EL 2.4.21-32.EL 2.4.21-37.EL Installation: If you have not done so already, unpack the gzipped tar file: root@host # tar xzvf aacraid-1.1.5.2418_2006_02_21.tar.gz root@host # cd aacraid-1.1.5.2418_2006_02_21 Please read ALL of the instructions before proceeding further. After unpacking the gzipped tar file, execute the "install" script. You may wish to try it with the --dry-run option first, to see what will be done to your system without actually installing any drivers: root@host # ./install --initrd --grub --dry-run Then, if you are satisfied with the results, root@host # ./install --initrd --grub What will the install script do? The install script will install the aacraid loadable object modules into the /lib/modules directory for each kernel for which a driver object module is present in this package and exists on the system. Then it will make a new initrd (initial RAM disk) image for the running kernel, if a driver for the running kernel was installed. Then, it will update the LILO or GRUB configuration, as directed, adding a new entry to use the new initrd image. If there were already aacraid loadable object modules present in the kernel libraries, these will be backed up under /use/src/HP/driver_backup. There are many options to the "install" script: ./install --help /u1/build/sbe/scripts/install/install: line 128: ./print_usage: No such file or directory /u1/build/sbe/scripts/install/install: line 1: ./error_report: No such file or directory The "install" and "uninstall" scripts try to be very carefull not to leave the system in an unusable state. When "install" installs a driver, if it overwrites an existing driver, the old driver is saved in the /usr/src/HP/driver_backup directory. Several levels of backups of the same driver can be created if "install" is run several times and each time is installing a different version of the same driver. ("install" will not overwrite one driver with and identical driver creating a pointless backup). "uninstall" will use the backups created by "install", if any. When a driver is uninstalled, if there is any backup file for it, the newest one will be used to replace the just uninstalled driver. Although every effort has been made to ensure that the installation script will properly install the drivers, or, if for whatever reason it is unable to do that, that it detects this, and at the very least, does not harm, we understand that you may not be comfortable running the installation script. Perhaps you have a highly customized system and feel that it is unlikely that the script will be able to anticipate your requirements and carry out the appropriate steps to your satisfaction, (or you notice, by way of the --dry-run option, that it in fact will do something that you do not like.) If that is the case, you can manually install the appropriate driver object modules contained here, within the ./lib directory, into the appropriate subdirectory of your /lib/modules directory and manually configure LILO or GRUB easily enough, or alternately, obtain the source rpm and build the sources yourself. How to make SCSI tape drives work --------------------------------- How to make SCSI tape drives and medium changers work with Smartarray controllers on linux with the cciss driver. Here are some notes about using tape drives with Smartarray controllers and the cciss driver. -------------- * The Easy Way -------------- Run /sbin/cciss_hotplug at system boot time, and after any hot plugging (or unplugging) of any tape drives. That's it. Assuming you have one or more SCSI tape drives and perhaps medium changers attached to your Smartarray controllers, there is a script i "/sbin/cciss_hotplug" which works in conjunction with a program "/sbin/cciss_phys_devs" to bring these devices online. All you have to do is run /sbin/cciss_hotplug, and any tape drives present, recently added, (or removed) from your Smartarray controllers should be brought online (or offline if removed) without further ado. Note: The cciss_hotplug script now takes pains to perform the minimum set of operations required to bring these devices online due to complaints that previous incarnations of the script caused too much console output to be generated as it did brute force scanning of SCSI busses, and was otherwise generally noisy. See also: man pages for "cciss_hotplug" and "cciss_phys_devs" -------------- * The Hard Way -------------- How to "manually" do the nearly the same thing the script does: To tell the cciss driver to register with the SCSI mid layer as a SCSI Host bus adapter (HBA), do the following: echo "engage scsi" > /proc/driver/cciss/ccissN Where N is the Smartarray controller for which there are attached tape drives or medium changers, and repeat this command for each such controller. To brute force search for every Smartarray controller which might have a tape drive attached, you could do something like the following: for x in /proc/driver/cciss/* do echo "engage scsi" > $x done This will however cause somewhat excessive output to the console (and in dmesg output) which using the cciss_hotplug script will avoid. If there are no tape drives or medium changers attached to a particular Smartarray controller, the driver will not register that controlelr as a SCSI HBA. Once registered as a SCSI HBA, the driver cannot be unregistered except by unloading the driver completely via rmmod. After any hot plug operation, that is, after physically adding or removing any tape drive from any Smartarray controller, there are two things which must be done. First, you must inform the cciss driver that some changes have occurred so it can rescan the bus and detect these changes. Second, you must also inform the linux SCSI mid layer of what changes have been made. 1. To make the cciss driver rescan for new devices, you need to issue a command such as: echo "rescan" > /proc/scsi/cciss/0 For each Smartarray controller which has registered as a SCSI HBA there will be a file in the directory /proc/scsi/cciss into which the "rescan" command may be written. This action syncs up the cciss driver's notion of what physical devices are attached to it with the reality of what physical devices actually are currently attached to it. To brute force search for all tape drives, you might do something like: for x in /proc/scsi/cciss/* do echo "rescan" > $x done This will however cause more output to the console (and from dmesg) than is optimal, which using the cciss_hotplug script avoids. Note that we have talked about two distinct files for each controller here, /proc/scsi/cciss/* and /proc/driver/cciss/cciss*. These correspond more or less to the SCSI and block portions of the driver. Every Smartarray instance will have /proc/driver/cciss/cciss* file, but only those registered as SCSI HBAs will have a /proc/scsi/cciss/* file. The numbers used for the /proc/scsi/cciss/[0-9]* filenames are the linux SCSI Host numbers, and are not the same numbers as the numbers used in the /proc/driver/cciss/cciss[0-9]* filenames. The latter are the Smartarray instance numbers. 2. The linux SCSI mid layer must also be informed of changes. This is also done via commands issued through the /proc filesystem. The cciss driver will issue messages (viewable by way of the dmesg command) whenever a tape drive is added or removed. For example: cciss0: Sequential-Access device c2b0t0l0 removed. or cciss0: Sequential-Access device c2b0t0l0 added. The "c2b0t0l0" is telling you the "SCSI nexus" of the device, and means "Controller 2, Bus 0, Target 0, Logical Unit 0." To inform the SCSI mid layer of such changes, a command such as the following is used: echo scsi remove-single-device 2 0 0 0 > /proc/scsi/scsi or echo scsi add-single-device 2 0 0 0 > /proc/scsi/scsi The numbers in the above commands are the "SCSI nexus" of the device to be added or removed. You should see a message on the console (or in dmesg output) such as: Vendor: COMPAQ Model: SDX-500C Rev: 1.08 Type: Sequential-Access ANSI SCSI revision: 02 Attached scsi tape st0 at scsi2, channel 0, id 0, lun 0 st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 4503599627370495 Then you can use /dev/st0 in the usual manner of using SCSI tape drives. Why is the "engage scsi" step necessary? ---------------------------------------- In linux there are two main types of storage drivers, SCSI drivers, and "block" drivers. The cciss driver happens to be implemented as a block driver. When SCSI tape drive support was added, it became a SCSI driver as well, but only for the tape drives. Neither the logical drives nor the physical disks are presented to linux through the SCSI driver interfaces, these continue to be presented through the block driver interfaces. Block drivers are loaded before the SCSI mid layer is loaded. Because of this, the cciss driver cannot try to "become" a SCSI driver by registering as a SCSI host device because the SCSI mid layer is not yet present, and there is nothing to register with, and making the calls to register at driver init time would result in a panic. So, the driver must register with the SCSI mid layer "later." When is "later?" Later is whenever a user process writes "engage scsi" into /proc/driver/cciss/cciss*, typically via something like the following command, as described above: echo "engage scsi" > /proc/driver/cciss/cciss0 ("cciss0" is just an example, if you have more than one Smartarray in your system, you of course may have cciss1, cciss2, etc.) Modern kernels will perform a SCSI bus scan when a new SCSI host registers, and register any devices (e.g. tape drives) which they find. Older kernels may not do this and may require additional steps to inform the SCSI mid layer of added devices, as described above, as will modern kernels when any tape device is hot plugged (or unplugged) as also described above.