Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | This driver is for Compaq's SMART Array Controllers. |
2 | ||
3 | Supported Cards: | |
4 | ---------------- | |
5 | ||
6 | This 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 P600 | |
18 | * SA P800 | |
19 | * SA E400 | |
9dc7a86e MM |
20 | * SA P400i |
21 | * SA E200 | |
22 | * SA E200i | |
1883c5ab | 23 | * SA E500 |
24aac480 MM |
24 | * SA P212 |
25 | * SA P410 | |
26 | * SA P410i | |
27 | * SA P411 | |
28 | * SA P812 | |
77ca7286 MM |
29 | * SA P712m |
30 | * SA P711m | |
1da177e4 | 31 | |
6c080f1a SC |
32 | Detecting drive failures: |
33 | ------------------------- | |
1da177e4 | 34 | |
6c080f1a SC |
35 | To get the status of logical volumes and to detect physical drive |
36 | failures, you can use the cciss_vol_status program found here: | |
37 | http://cciss.sourceforge.net/#cciss_utils | |
1da177e4 LT |
38 | |
39 | Device Naming: | |
40 | -------------- | |
41 | ||
6c080f1a SC |
42 | If nodes are not already created in the /dev/cciss directory, run as root: |
43 | ||
44 | # cd /dev | |
45 | # ./MAKEDEV cciss | |
46 | ||
1da177e4 LT |
47 | You need some entries in /dev for the cciss device. The MAKEDEV script |
48 | can make device nodes for you automatically. Currently the device setup | |
49 | is as follows: | |
50 | ||
51 | Major numbers: | |
52 | 104 cciss0 | |
53 | 105 cciss1 | |
54 | 106 cciss2 | |
55 | 105 cciss3 | |
56 | 108 cciss4 | |
57 | 109 cciss5 | |
58 | 110 cciss6 | |
59 | 111 cciss7 | |
60 | ||
61 | Minor numbers: | |
62 | b7 b6 b5 b4 b3 b2 b1 b0 | |
63 | |----+----| |----+----| | |
64 | | | | |
65 | | +-------- Partition ID (0=wholedev, 1-15 partition) | |
66 | | | |
67 | +-------------------- Logical Volume number | |
68 | ||
69 | The device naming scheme is: | |
70 | /dev/cciss/c0d0 Controller 0, disk 0, whole device | |
71 | /dev/cciss/c0d0p1 Controller 0, disk 0, partition 1 | |
72 | /dev/cciss/c0d0p2 Controller 0, disk 0, partition 2 | |
73 | /dev/cciss/c0d0p3 Controller 0, disk 0, partition 3 | |
74 | ||
75 | /dev/cciss/c1d1 Controller 1, disk 1, whole device | |
76 | /dev/cciss/c1d1p1 Controller 1, disk 1, partition 1 | |
77 | /dev/cciss/c1d1p2 Controller 1, disk 1, partition 2 | |
78 | /dev/cciss/c1d1p3 Controller 1, disk 1, partition 3 | |
79 | ||
80 | SCSI tape drive and medium changer support | |
81 | ------------------------------------------ | |
82 | ||
83 | SCSI sequential access devices and medium changer devices are supported and | |
84 | appropriate device nodes are automatically created. (e.g. | |
85 | /dev/st0, /dev/st1, etc. See the "st" man page for more details.) | |
86 | You must enable "SCSI tape drive support for Smart Array 5xxx" and | |
87 | "SCSI support" in your kernel configuration to be able to use SCSI | |
88 | tape drives with your Smart Array 5xxx controller. | |
89 | ||
90 | Additionally, note that the driver will not engage the SCSI core at init | |
91 | time. The driver must be directed to dynamically engage the SCSI core via | |
92 | the /proc filesystem entry which the "block" side of the driver creates as | |
93 | /proc/driver/cciss/cciss* at runtime. This is because at driver init time, | |
94 | the SCSI core may not yet be initialized (because the driver is a block | |
95 | driver) and attempting to register it with the SCSI core in such a case | |
96 | would cause a hang. This is best done via an initialization script | |
fff9289b | 97 | (typically in /etc/init.d, but could vary depending on distribution). |
1da177e4 LT |
98 | For example: |
99 | ||
100 | for x in /proc/driver/cciss/cciss[0-9]* | |
101 | do | |
102 | echo "engage scsi" > $x | |
103 | done | |
104 | ||
105 | Once the SCSI core is engaged by the driver, it cannot be disengaged | |
106 | (except by unloading the driver, if it happens to be linked as a module.) | |
107 | ||
108 | Note also that if no sequential access devices or medium changers are | |
109 | detected, the SCSI core will not be engaged by the action of the above | |
110 | script. | |
111 | ||
112 | Hot plug support for SCSI tape drives | |
113 | ------------------------------------- | |
114 | ||
115 | Hot plugging of SCSI tape drives is supported, with some caveats. | |
116 | The cciss driver must be informed that changes to the SCSI bus | |
f4a93bcd MM |
117 | have been made. This may be done via the /proc filesystem. |
118 | For example: | |
1da177e4 LT |
119 | |
120 | echo "rescan" > /proc/scsi/cciss0/1 | |
121 | ||
f4a93bcd MM |
122 | This causes the driver to query the adapter about changes to the |
123 | physical SCSI buses and/or fibre channel arbitrated loop and the | |
1da177e4 LT |
124 | driver to make note of any new or removed sequential access devices |
125 | or medium changers. The driver will output messages indicating what | |
126 | devices have been added or removed and the controller, bus, target and | |
f4a93bcd MM |
127 | lun used to address the device. It then notifies the SCSI mid layer |
128 | of these changes. | |
1da177e4 LT |
129 | |
130 | Note that the naming convention of the /proc filesystem entries | |
131 | contains a number in addition to the driver name. (E.g. "cciss0" | |
132 | instead of just "cciss" which you might expect.) | |
133 | ||
134 | Note: ONLY sequential access devices and medium changers are presented | |
135 | as SCSI devices to the SCSI mid layer by the cciss driver. Specifically, | |
136 | physical SCSI disk drives are NOT presented to the SCSI mid layer. The | |
137 | physical SCSI disk drives are controlled directly by the array controller | |
138 | hardware and it is important to prevent the kernel from attempting to directly | |
139 | access these devices too, as if the array controller were merely a SCSI | |
140 | controller in the same way that we are allowing it to access SCSI tape drives. | |
141 | ||
3da8b713 | 142 | SCSI error handling for tape drives and medium changers |
143 | ------------------------------------------------------- | |
144 | ||
145 | The linux SCSI mid layer provides an error handling protocol which | |
146 | kicks into gear whenever a SCSI command fails to complete within a | |
147 | certain amount of time (which can vary depending on the command). | |
148 | The cciss driver participates in this protocol to some extent. The | |
149 | normal protocol is a four step process. First the device is told | |
150 | to abort the command. If that doesn't work, the device is reset. | |
151 | If that doesn't work, the SCSI bus is reset. If that doesn't work | |
152 | the host bus adapter is reset. Because the cciss driver is a block | |
153 | driver as well as a SCSI driver and only the tape drives and medium | |
154 | changers are presented to the SCSI mid layer, and unlike more | |
155 | straightforward SCSI drivers, disk i/o continues through the block | |
156 | side during the SCSI error recovery process, the cciss driver only | |
157 | implements the first two of these actions, aborting the command, and | |
158 | resetting the device. Additionally, most tape drives will not oblige | |
159 | in aborting commands, and sometimes it appears they will not even | |
6c28f2c0 | 160 | obey a reset command, though in most circumstances they will. In |
3da8b713 | 161 | the case that the command cannot be aborted and the device cannot be |
162 | reset, the device will be set offline. | |
163 | ||
164 | In the event the error handling code is triggered and a tape drive is | |
165 | successfully reset or the tardy command is successfully aborted, the | |
166 | tape drive may still not allow i/o to continue until some command | |
167 | is issued which positions the tape to a known position. Typically you | |
168 | must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example) | |
169 | before i/o can proceed again to a tape drive which was reset. | |
170 |