summaryrefslogtreecommitdiff
path: root/Documentation/cciss.txt
diff options
context:
space:
mode:
authormike.miller@hp.com <mike.miller@hp.com>2005-11-04 12:30:37 -0600
committerJames Bottomley <jejb@mulgrave.(none)>2005-11-06 14:12:49 -0600
commit3da8b713da723e78a03f0404beedf3cc6f4f860b (patch)
treea09cc4308fcf0087aa607029bd71825b568d97e5 /Documentation/cciss.txt
parent13bf50d1f21b2f11452c4b8a82a91319791f8ba3 (diff)
[SCSI] cciss: scsi error handling
This patch adds SCSI error handling code to the SCSI portion of the cciss driver. Signed-off-by: Stephen M. Cameron <steve.cameron@hp.com> Acked-by: Mike Miller <mike.miller@hp.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'Documentation/cciss.txt')
-rw-r--r--Documentation/cciss.txt29
1 files changed, 29 insertions, 0 deletions
diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt
index 68a711fb82cf..15378422fc46 100644
--- a/Documentation/cciss.txt
+++ b/Documentation/cciss.txt
@@ -133,3 +133,32 @@ 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 coommand, 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.
+