| This driver is for Compaq's SMART Array Controllers. |
| |
| Supported Cards: |
| ---------------- |
| |
| This driver is known to work with the following cards: |
| |
| * SA 5300 |
| * SA 5i |
| * SA 532 |
| * SA 5312 |
| * SA 641 |
| * SA 642 |
| * SA 6400 |
| * SA 6400 U320 Expansion Module |
| * SA 6i |
| * SA P600 |
| * SA P800 |
| * SA E400 |
| * SA P400i |
| * SA E200 |
| * SA E200i |
| * SA E500 |
| * SA P700m |
| * SA P212 |
| * SA P410 |
| * SA P410i |
| * SA P411 |
| * SA P812 |
| * SA P712m |
| * SA P711m |
| |
| Detecting drive failures: |
| ------------------------- |
| |
| To get the status of logical volumes and to detect physical drive |
| failures, you can use the cciss_vol_status program found here: |
| http://cciss.sourceforge.net/#cciss_utils |
| |
| Device Naming: |
| -------------- |
| |
| If nodes are not already created in the /dev/cciss directory, run as root: |
| |
| # cd /dev |
| # ./MAKEDEV cciss |
| |
| You need some entries in /dev for the cciss device. The MAKEDEV script |
| can make device nodes for you automatically. Currently the device setup |
| is as follows: |
| |
| Major numbers: |
| 104 cciss0 |
| 105 cciss1 |
| 106 cciss2 |
| 105 cciss3 |
| 108 cciss4 |
| 109 cciss5 |
| 110 cciss6 |
| 111 cciss7 |
| |
| Minor numbers: |
| b7 b6 b5 b4 b3 b2 b1 b0 |
| |----+----| |----+----| |
| | | |
| | +-------- Partition ID (0=wholedev, 1-15 partition) |
| | |
| +-------------------- Logical Volume number |
| |
| The device naming scheme is: |
| /dev/cciss/c0d0 Controller 0, disk 0, whole device |
| /dev/cciss/c0d0p1 Controller 0, disk 0, partition 1 |
| /dev/cciss/c0d0p2 Controller 0, disk 0, partition 2 |
| /dev/cciss/c0d0p3 Controller 0, disk 0, partition 3 |
| |
| /dev/cciss/c1d1 Controller 1, disk 1, whole device |
| /dev/cciss/c1d1p1 Controller 1, disk 1, partition 1 |
| /dev/cciss/c1d1p2 Controller 1, disk 1, partition 2 |
| /dev/cciss/c1d1p3 Controller 1, disk 1, partition 3 |
| |
| CCISS simple mode support |
| ------------------------- |
| |
| The "cciss_simple_mode=1" boot parameter may be used to prevent the driver |
| from putting the controller into "performant" mode. The difference is that |
| with simple mode, each command completion requires an interrupt, while with |
| "performant mode" (the default, and ordinarily better performing) it is |
| possible to have multiple command completions indicated by a single |
| interrupt. |
| |
| SCSI tape drive and medium changer support |
| ------------------------------------------ |
| |
| SCSI sequential access devices and medium changer devices are supported and |
| appropriate device nodes are automatically created. (e.g. |
| /dev/st0, /dev/st1, etc. See the "st" man page for more details.) |
| You must enable "SCSI tape drive support for Smart Array 5xxx" and |
| "SCSI support" in your kernel configuration to be able to use SCSI |
| tape drives with your Smart Array 5xxx controller. |
| |
| Additionally, note that the driver will engage the SCSI core at init |
| time if any tape drives or medium changers are detected. The driver may |
| also be directed to dynamically engage the SCSI core via the /proc filesystem |
| entry which the "block" side of the driver creates as |
| /proc/driver/cciss/cciss* at runtime. This is best done via a script. |
| |
| For example: |
| |
| for x in /proc/driver/cciss/cciss[0-9]* |
| do |
| echo "engage scsi" > $x |
| done |
| |
| Once the SCSI core is engaged by the driver, it cannot be disengaged |
| (except by unloading the driver, if it happens to be linked as a module.) |
| |
| Note also that if no sequential access devices or medium changers are |
| detected, the SCSI core will not be engaged by the action of the above |
| script. |
| |
| Hot plug support for SCSI tape drives |
| ------------------------------------- |
| |
| Hot plugging of SCSI tape drives is supported, with some caveats. |
| The cciss driver must be informed that changes to the SCSI bus |
| have been made. This may be done via the /proc filesystem. |
| For example: |
| |
| echo "rescan" > /proc/scsi/cciss0/1 |
| |
| This causes the driver to query the adapter about changes to the |
| physical SCSI buses and/or fibre channel arbitrated loop and the |
| driver to make note of any new or removed sequential access devices |
| or medium changers. The driver will output messages indicating what |
| devices have been added or removed and the controller, bus, target and |
| lun used to address the device. It then notifies the SCSI mid layer |
| of these changes. |
| |
| Note that the naming convention of the /proc filesystem entries |
| contains a number in addition to the driver name. (E.g. "cciss0" |
| instead of just "cciss" which you might expect.) |
| |
| Note: ONLY sequential access devices and medium changers are presented |
| as SCSI devices to the SCSI mid layer by the cciss driver. Specifically, |
| physical SCSI disk drives are NOT presented to the SCSI mid layer. The |
| physical SCSI disk drives are controlled directly by the array controller |
| hardware and it is important to prevent the kernel from attempting to directly |
| access these devices too, as if the array controller were merely a SCSI |
| controller in the same way that we are allowing it to access SCSI tape drives. |
| |
| SCSI error handling for tape drives and medium changers |
| ------------------------------------------------------- |
| |
| The linux SCSI mid layer provides an error handling protocol which |
| kicks into gear whenever a SCSI command fails to complete within a |
| certain amount of time (which can vary depending on the command). |
| The cciss driver participates in this protocol to some extent. The |
| normal protocol is a four step process. First the device is told |
| to abort the command. If that doesn't work, the device is reset. |
| If that doesn't work, the SCSI bus is reset. If that doesn't work |
| the host bus adapter is reset. Because the cciss driver is a block |
| driver as well as a SCSI driver and only the tape drives and medium |
| changers are presented to the SCSI mid layer, and unlike more |
| straightforward SCSI drivers, disk i/o continues through the block |
| side during the SCSI error recovery process, the cciss driver only |
| implements the first two of these actions, aborting the command, and |
| resetting the device. Additionally, most tape drives will not oblige |
| in aborting commands, and sometimes it appears they will not even |
| obey a reset command, though in most circumstances they will. In |
| the case that the command cannot be aborted and the device cannot be |
| reset, the device will be set offline. |
| |
| In the event the error handling code is triggered and a tape drive is |
| successfully reset or the tardy command is successfully aborted, the |
| tape drive may still not allow i/o to continue until some command |
| is issued which positions the tape to a known position. Typically you |
| must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example) |
| before i/o can proceed again to a tape drive which was reset. |
| |
| There is a cciss_tape_cmds module parameter which can be used to make cciss |
| allocate more commands for use by tape drives. Ordinarily only a few commands |
| (6) are allocated for tape drives because tape drives are slow and |
| infrequently used and the primary purpose of Smart Array controllers is to |
| act as a RAID controller for disk drives, so the vast majority of commands |
| are allocated for disk devices. However, if you have more than a few tape |
| drives attached to a smart array, the default number of commands may not be |
| enought (for example, if you have 8 tape drives, you could only rewind 6 |
| at one time with the default number of commands.) The cciss_tape_cmds module |
| parameter allows more commands (up to 16 more) to be allocated for use by |
| tape drives. For example: |
| |
| insmod cciss.ko cciss_tape_cmds=16 |
| |
| Or, as a kernel boot parameter passed in via grub: cciss.cciss_tape_cmds=8 |