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