1This driver is for Compaq's SMART Array Controllers. 2 3Supported Cards: 4---------------- 5 6This driver is known to work with the following cards: 7 8 * SA 5300 9 * SA 5i 10 * SA 532 11 * SA 5312 12 * SA 641 13 * SA 642 14 * SA 6400 15 * SA 6400 U320 Expansion Module 16 * SA 6i 17 * SA 6422 18 * SA P600 19 * SA P400 20 * SA P400i 21 * SA E200 22 * SA E200i 23 24If nodes are not already created in the /dev/cciss directory 25 26# mkdev.cciss [ctlrs] 27 28Where ctlrs is the number of controllers you have (defaults to 1 if not 29specified). 30 31Device Naming: 32-------------- 33 34You need some entries in /dev for the cciss device. The mkdev.cciss script 35can make device nodes for you automatically. Currently the device setup 36is as follows: 37 38Major numbers: 39 104 cciss0 40 105 cciss1 41 106 cciss2 42 etc... 43 44Minor numbers: 45 b7 b6 b5 b4 b3 b2 b1 b0 46 |----+----| |----+----| 47 | | 48 | +-------- Partition ID (0=wholedev, 1-15 partition) 49 | 50 +-------------------- Logical Volume number 51 52The suggested device naming scheme is: 53/dev/cciss/c0d0 Controller 0, disk 0, whole device 54/dev/cciss/c0d0p1 Controller 0, disk 0, partition 1 55/dev/cciss/c0d0p2 Controller 0, disk 0, partition 2 56/dev/cciss/c0d0p3 Controller 0, disk 0, partition 3 57 58/dev/cciss/c1d1 Controller 1, disk 1, whole device 59/dev/cciss/c1d1p1 Controller 1, disk 1, partition 1 60/dev/cciss/c1d1p2 Controller 1, disk 1, partition 2 61/dev/cciss/c1d1p3 Controller 1, disk 1, partition 3 62 63Support for more than 8 controllers 64----------------------------------- 65Originally the driver only supports 8 controllers in the system, 66and this is due to the major numbers assigned to the driver 67(104 thru 111). 68 69The driver can now support up to 32 controllers in the system. 70 71For the ninth controller and beyond, the major numbers will be 72assigned dynamically by the kernel when it is discovered, 73and there is no guarantee what the major number you will get, 74but most likely it will start from 254 and goes down from there. 75 76You can check the assigned major numbers by typing 77 cat /proc/devices 78And look for cciss controllers 79 80Once you have this, you need to create device nodes in 81/dev/cciss directory. The nodes for the first 8 controllers 82should already be created by mkdev.cciss script or 83/etc/makedev.d/cciss script. You can add the major number(s) 84in those scripts, or create the nodes manually by using 85the mknod command. 86 87You can also use mknod_dyn.cciss and rmnod_dyn.cciss scripts 88to create or remove nodes easily. These scripts can be found 89in the Documentation directory. 90 91Then you can mount the devices and create partitions 92(You also need to make nodes for these partitions). 93 94As for the minor number, the disk device will have a minor 95number divisible by 16 (e.g: 0, 16, 32 etc), and the 96partitions on those disk devices will have the minor number 97of the disk device plus the partition number (1-15). 98For example, disk d2 will have minor number 32, and its 99partitions 1 and 2 will have minor numbers 33 and 34. 100 101Look at the mkdev.cciss script for example. 102 103Note: 104 In 2.4 kernel, partition names are hard coded in 105 /usr/src/linux/fs/partitions/check.c 106 and only for the first 8 cciss controllers. The rest 107 will be reported as ccissXX. This should not affect 108 I/O operation or performance. Please apply the 109 cciss_2.4_partition_name.patch to address this. This 110 will not be an issue under 2.5 kernel, since partition 111 names will be handled by the driver. 112 113SCSI tape drive and medium changer support 114------------------------------------------ 115 116SCSI sequential access devices and medium changer devices are supported and 117appropriate device nodes are automatically created. (e.g. 118/dev/st0, /dev/st1, etc. See the "st" man page for more details.) 119You must enable "SCSI tape drive support for Smart Array 5xxx" and 120"SCSI support" in your kernel configuration to be able to use SCSI 121tape drives with your Smart Array 5xxx controller. 122 123Additionally, note that the driver will not engage the SCSI core at init 124time. The driver must be directed to dynamically engage the SCSI core via 125the /proc filesystem entry which the "block" side of the driver creates as 126/proc/driver/cciss/cciss* at runtime. This is because at driver init time, 127the SCSI core may not yet be initialized (because the driver is a block 128driver) and attempting to register it with the SCSI core in such a case 129would cause a hang. This is best done via an initialization script 130(typically in /etc/init.d, but could vary depending on distibution). 131For example: 132 133 for x in /proc/driver/cciss/cciss[0-9]* 134 do 135 echo "engage scsi" > $x 136 done 137 138Once the SCSI core is engaged by the driver, it cannot be disengaged 139(except by unloading the driver, if it happens to be linked as a module.) 140 141Note also that if no sequential access devices or medium changers are 142detected, the SCSI core will not be engaged by the action of the above 143script. 144 145Hot plug support for SCSI tape drives 146------------------------------------- 147 148Hot plugging of SCSI tape drives is supported, with some caveats. 149The cciss driver must be informed that changes to the SCSI bus 150have been made, in addition to and prior to informing the SCSI 151mid layer. This may be done via the /proc filesystem. For example: 152 153 echo "rescan" > /proc/scsi/cciss0/1 154 155This causes the adapter to query the adapter about changes to the 156physical SCSI buses and/or fibre channel arbitrated loop and the 157driver to make note of any new or removed sequential access devices 158or medium changers. The driver will output messages indicating what 159devices have been added or removed and the controller, bus, target and 160lun used to address the device. Once this is done, the SCSI mid layer 161can be informed of changes to the virtual SCSI bus which the driver 162presents to it in the usual way. For example: 163 164 echo scsi add-single-device 3 2 1 0 > /proc/scsi/scsi 165 166to add a device on controller 3, bus 2, target 1, lun 0. Note that 167the driver makes an effort to preserve the devices positions 168in the virtual SCSI bus, so if you are only moving tape drives 169around on the same adapter and not adding or removing tape drives 170from the adapter, informing the SCSI mid layer may not be necessary. 171 172Note that the naming convention of the /proc filesystem entries 173contains a number in addition to the driver name. (E.g. "cciss0" 174instead of just "cciss" which you might expect.) This is because 175of changes to the 2.4 kernel PCI interface related to PCI hot plug 176that imply the driver must register with the SCSI mid layer once per 177adapter instance rather than once per driver. 178 179Note: ONLY sequential access devices and medium changers are presented 180as SCSI devices to the SCSI mid layer by the cciss driver. Specifically, 181physical SCSI disk drives are NOT presented to the SCSI mid layer. The 182physical SCSI disk drives are controlled directly by the array controller 183hardware and it is important to prevent the OS from attempting to directly 184access these devices too, as if the array controller were merely a SCSI 185controller in the same way that we are allowing it to access SCSI tape drives. 186 187Monitor Threads 188--------------- 189 190For multipath configurations (acheived via a higher level driver, such 191as the "md" driver) it is important that failure of a controller is detected. 192Ordinarily, the driver is entirely interrupt driven. If a failure occurs 193in such a way that the processor cannot receive interrupts from an adapter, 194the driver will wait forever for i/o's to complete. In a multipath 195configuration this is undesirable, as the md driver relies on i/o's being 196reported as failed by the low level driver to trigger failing over to an 197alternate controller. The monitor threads allow the driver to detect such 198situations and report outstanding i/o's as having failed so that recovery 199actions such switching to an alternate controller can occur. The monitor 200threads periodically sends a trivial "no-operation" command down to 201the controllers and expect them to complete within a a reasonable (short) 202time period. The firmware on the adapter is designed such that no matter 203how busy the adapter is serving i/o, it can respond quickly to a 204"no-operation" command. In the event that a deadline elapses before a no 205operation command completes, all outstanding commands on that controller 206are reported back to the upper layers as having failed, and any new commands 207sent to the controller are immediately reported back as failed. 208 209To enable the monitor threads, the compile time option must be enabled 210(via the usual linux kernel configuration) and the monitor thread must 211be enabled at runtime as well. A system may have many adapters, but 212perhaps only a single pair operating in a multipath configuration. 213In this way, it is possible to run monitoring threads only for those 214adapters which require it. 215 216To start a monitoring thread on the first cciss adapter, "cciss0" with 217a polling interval of 30 seconds, execute the following command: 218 219 echo "monitor 30" > /proc/driver/cciss/cciss0 220 221To change the polling interval, to say, 60 seconds: 222 223 echo "monitor 60" > /proc/driver/cciss/cciss0 224 225(Note, the change will not take effect until the previous polling 226interval elapses.) 227 228To disable the monitoring thread, set the polling interval to 0 seconds: 229 230 echo "monitor 0" > /proc/driver/cciss/cciss0 231 232(Again, the monitoring thread will not exit until the previous polling 233interval elapses.) 234 235The minimum monitoring period is 10 seconds, and the maximum monitoring 236period is 3600 seconds (1 hour). The no-operation command must complete 237with 5 seconds of submission in all cases or the controller will be presumed 238failed. 239