By keeping to a minimum the functions essential to communicate via this protocol, a wide range of peripheral devices of varying capability can operate in the same environment. Because subsets of the full architecture may be implemented, optional functions are noted.
The command descriptor block always has an operation code as its first byte and a control byte as its last byte.
For all commands, if there is an invalid parameter in the command descriptor block, then the target shall terminate the command without altering the medium.
The group code specifies one of the following groups:
NOTICE: The logical unit number field is included in the command descriptor block for compatibility with some SCSI-1 devices. This field may be reclaimed in SCSI-3. New implementations should use the outbound IDENTIFY message, which is mandatory in SCSI-2, to establish the I_T_L nexus.
A six-byte command descriptor block contains a 21-bit logical block address. The ten-byte and the twelve-byte command descriptor blocks contain 32-bit logical block addresses. Logical block addresses in additional parameter data have their length specified for each occurrence. See the specific command descriptions.
Commands that use one byte for the transfer length allow up to 256 blocks of data to be transferred by one command. A transfer length value of 1 to 255 indicates the number of blocks that shall be transferred. A value of zero indicates 256 blocks.
In commands that use multiple bytes for the transfer length, a transfer length of zero indicates that no data transfer shall take place. A value of one or greater indicates the number of blocks that shall be transferred.
Refer to the specific command description for further information.
The flag bit should be set to zero if the link bit is zero. If link bit is zero and the flag bit is one, the target shall return CHECK CONDITION status. The sense key shall be set to ILLEGAL REQUEST.
If the flag bit is zero and the link bit is one, and if the command completes successfully, the target shall send the LINKED COMMAND COMPLETE message. If the flag bit is one and the link bit is one, and if the command completes successfully, the target shall send the LINKED COMMAND COMPLETE (WITH FLAG) message.
The link bit is used to continue the I/O process across multiple commands. Implementation of the link bit is optional. A link bit of one indicates that the initiator requests a continuation of the I/O process and that the target should enter the command phase upon successful completion of the current command.
If the link bit is one, and if the command completes successfully, the target shall return INTERMEDIATE or INTERMEDIATE-CONDITION MET status and shall then send one of the two messages defined by the flag bit.
If either of the link and flag bits are set to one, and the target does not implement linked commands, it shall return CHECK CONDITION status. The sense key shall be set to ILLEGAL REQUEST.
The STATUS phase normally occurs at the end of a command but in some cases may occur prior to transferring the command descriptor block.
7.3.1 GOOD: This status indicates that the target has successfully completed the command.
7.3.2 CHECK CONDITION: This status indicates that a contingent allegiance condition has occurred (see 7.6).
7.3.3 CONDITION MET: This status or INTERMEDIATE-CONDITION MET is returned whenever the requested operation is satisfied (see the SEARCH DATA and PREFETCH commands).
7.3.4 BUSY: This status indicates that the target is busy. This status shall be returned whenever a target is unable to accept a command from an otherwise acceptable initiator (i.e. no reservation conflicts). The recommended initiator recovery action is to issue the command again at a later time.
7.3.5 INTERMEDIATE: This status or INTERMEDIATE-CONDITION MET shall be returned for every successfully completed command in a series of linked commands (except the last command), unless the command is terminated with CHECK CONDITION, RESERVATION CONFLICT, or COMMAND TERMINATED status. If INTERMEDIATE or INTERMEDIATE-CONDITION MET status is not returned, the series of linked commands is terminated and the I/O process is ended.
7.3.6 INTERMEDIATE-CONDITION MET: This status is the combination of the CONDITION MET and INTERMEDIATE statuses.
7.3.7 RESERVATION CONFLICT: This status shall be returned whenever an initiator attempts to access a logical unit or an extent within a logical unit that is reserved with a conflicting reservation type for another SCSI device (see the RESERVE and RESERVE UNIT commands). The recommended initiator recovery action is to issue the command again at a later time.
7.3.8 COMMAND TERMINATED: This status shall be returned whenever the target terminates the current I/O process after receiving a TERMINATE I/O PROCESS message (see 6.6.22). This status also indicates that a contingent allegiance condition has occurred (see 7.6).
7.3.9 QUEUE FULL: This status shall be implemented if tagged queuing is implemented. This status is returned when a SIMPLE QUEUE TAG, ORDERED QUEUE TAG, or HEAD OF QUEUE TAG message is received and the command queue is full. The I/O process is not placed in the command queue.
The initiator has one set of active pointers that includes a command pointer, a data pointer, and a status pointer. In addition, the initiator has one set of saved pointers for each I/O process that it is able to concurrently manage. The initiator sets up the saved pointers to point to the appropriate bytes for the I/O process and copies the saved pointers to the active pointers. It then arbitrates for the SCSI bus, and upon winning arbitration, selects the target. Once the target is selected, the target assumes control of the I/O process.
During the SELECTION phase, the initiator asserts the ATN signal to inform the target that the initiator wishes to send a message. The target enters the MESSAGE OUT phase and transfers the IDENTIFY message from the initiator. This message informs the target of which logical unit is to be used. At this point, an I_T_L nexus has been established for the I/O process. This nexus associates the initiator's pointers with the I/O process.
The target switches to the COMMAND phase and transfers the command descriptor block from the initiator. In this case, the command descriptor block contains a READ command. The target interprets the command and switches to the DATA IN phase, transfers the data, switches to STATUS phase, sends GOOD status, switches to MESSAGE IN phase, and transfers a COMMAND COMPLETE message. After successfully sending the COMMAND COMPLETE message, the target goes to the BUS FREE phase by releasing the BSY signal and the I/O process ends.
After the target has received the READ command (and has determined that there will be a delay), it disconnects from the SCSI bus by sending a DISCONNECT message and by going to the BUS FREE phase.
After the target retrieves the requested data from the peripheral device it arbitrates for the SCSI bus. Upon winning arbitration, it reselects the initiator and sends an IDENTIFY message to the initiator via the MESSAGE IN phase. This revives the I_T_L nexus so that the initiator can retrieve the correct set of pointers for the I/O process. The initiator restores the active pointers to their most recent saved values (which, in this case, are the initial values) and the target continues (as in the single command example) to finish the I/O process.
If target wishes to disconnect after transferring part of the data (e.g. while crossing a cylinder boundary), it may do so by sending a SAVE DATA POINTER message and a DISCONNECT message to the initiator and then disconnecting. When reconnection is completed, the current data pointer is restored to its value immediately prior to the SAVE DATA POINTER message.
On those occasions when an error or exception condition occurs and the target elects to repeat the information transfer, the target may repeat the transfer by either issuing a RESTORE POINTERS message or by disconnecting without issuing a SAVE DATA POINTER message. When reconnection is completed, the most recent saved pointer values are restored.
The commands are not entirely independent. When using the relative address bit (see 9.1.11), the address of the last logical block accessed by one of the commands is available to the next command. Thus one can search for a particular data pattern using a SEARCH DATA command and then read the logical block containing the data pattern with a READ command linked to the SEARCH DATA command. One can also read a logical block at a specified displacement from the block containing the data pattern.
A LINKED COMMAND COMPLETE or LINKED COMMAND COMPLETE (WITH FLAG) message is sent from the target to the initiator to indicate that a linked command completed. The initiator then updates the saved pointers for the nexus so that subsequent transfers from the target reference the next command of the series. Command processing of linked and single commands is similar except that relative addressing is permitted in linked commands.
For example, a successful completion of a SEARCH DATA EQUAL command causes the target to continue with the linked READ command from the initiator. If the relative address bit in the READ command has been set to one, and the address field of the READ command is set to zero, the target transfers the successfully searched block to the initiator.
7.5 Command processing considerations and exception conditions
The following subclauses describe some exception conditions and errors associated with command processing and the sequencing of commands.
The parameters that can be changed by modifying the operating definition of a logical unit include the vendor identification, the device type, the device model, the SCSI compliance level, the SCSI specification level, the command set, and other parameters. The low-level hardware parameters including signal timing and parity definitions cannot be changed by modifying the operating definition. The present operating definition of a logical unit with respect to an initiator can be determined at any time by execution of an INQUIRY command. In some vendor-specific cases, it may also be necessary to perform other commands including MODE SENSE and READ CAPACITY.
Each logical unit begins with a particular operating definition. If the logical unit supports the CHANGE DEFINITION command, the present operating definition can be changed to any other operating definition supported by the logical unit. The actual details of the operating definition of a logical unit are vendor-specific. If the operating definition is changed to one that does not include the CHANGE DEFINITION command, the target should continue to accept the CHANGE DEFINITION command.
If an error occurs during execution of a CHANGE DEFINITION command, the original operating definition remains in effect after the command is executed. The new operating definition becomes active only after successful execution of the CHANGE DEFINITION command.
Since new operating definitions may preclude the execution of I/O processes that are already in progress, the target may disconnect to allow completion of any I/O processes that are in progress. Operating definition changes that may cause conflicts with the normal operation from other initiators shall be indicated to those initiators by generating a unit attention condition for each other initiator. The additional sense code shall be set to CHANGED OPERATING DEFINITION.
An initiator may request a list of the operating definitions that the target supports and descriptive text for each operating definition using the INQUIRY command.
An incorrect initiator connection also occurs on an initial connection when an initiator:
A target that detects an incorrect initiator connection shall abort all I/O processes for the initiator on the logical unit or target routine and shall return CHECK CONDITION status. The sense key shall be set to ABORTED COMMAND and the additional sense code shall be set to OVERLAPPED COMMANDS ATTEMPTED.
If an initiator reconnects to an I/O process and a soft reset condition has occurred, the target shall meet the requirements of 6.2.2.2.
The logical unit may not be valid because:
Rounding of parameter values, when permitted, shall be performed as follows - A target that receives a parameter value that is not an exact supported value shall adjust the value to one that it supports and shall return CHECK CONDITION status with a sense key of RECOVERED ERROR. The additional sense code shall be set to ROUNDED PARAMETER. The initiator is responsible to issue an appropriate command to learn what value the target has selected.
Parameters affecting the use of asynchronous event notification are contained in the control mode page (see 8.3.3.1).
The four uses of asynchronous event notification are:
An example of the first case above is a device that implements a write cache. If the target is unable to write cached data to the medium, it may use an asynchronous event notification to inform the initiator of the failure. An extended contingent allegiance condition may also be established during the same I_T_L nexus used for the asynchronous event notification (see 6.6.9).
An example of the third case above is a device that supports removable media. Asynchronous event notification may be used to inform an initiator of a not-ready-to-ready transition (medium changed) or of an operator initiated event (e.g. activating a write protect switch or activating a start or stop switch).
An example of the fourth case above is a sequential-access device performing a REWIND command with the immediate bit set to one. Asynchronous event notification may be used to inform an initiator that the beginning of medium has been reached. Completion of a CD-ROM AUDIO PLAY command started in the immediate mode is another example of this case.
Notification of an asynchronous event is performed using the SEND command with the AEN bit set to one. The information identifying the condition being reported shall be returned during the DATA OUT phase of the SEND command. See 12.2.2 for further information on the format of the data sent.
An error condition or unit attention condition shall be reported once per occurrence of the event causing it. The target may choose to use an asynchronous event notification or to return CHECK CONDITION status on a subsequent command, but not both. Notification of command-related error conditions shall be sent only to the processor that initiated the I/O process.
The asynchronous event notification protocol can be used to notify processor devices that a system resource has become available. If a target chooses to use this method, the sense key in the sense data sent to the processor device shall be set to UNIT ATTENTION.
The asynchronous event notification protocol shall be sent only to SCSI devices that return processor device type with an AENC bit of one in response to an INQUIRY command. The INQUIRY command should be issued to logical unit zero of each SCSI device responding to selection. This procedure shall be conducted prior to the first asynchronous event notification and shall be repeated whenever the device deems it appropriate or when an event occurs that may invalidate the current information. (See 6.6.21, SYNCHRONOUS DATA TRANSFER REQUEST message, for examples of these events.)
Each SCSI device that returns processor device type with an AENC bit of one shall be issued a TEST UNIT READY command to determine that the SCSI device is ready to receive an asynchronous event notification. An SCSI device returning CHECK CONDITION status is issued a REQUEST SENSE command. This clears any pending unit attention condition. An SCSI device that returns processor device type with an AENC bit of one and returns GOOD status when issued a TEST UNIT READY command shall accept a SEND command with an AEN bit of one.
While the contingent allegiance condition exists, if the target is unable to maintain separate sense data, the target shall respond to any other requests for access to the logical unit or target routine from another initiator with a BUSY status. Execution of all tagged I/O processes for the I_T_L nexus for which the contingent allegiance condition exists shall be suspended until the contingent allegiance condition is cleared.
While the extended contingent allegiance condition exists, the target shall respond to any other request for access to the logical unit from another initiator with BUSY status. Execution of all I/O processes for the logical unit for which the extended contingent allegiance condition exists shall be suspended until the RELEASE RECOVERY message is received by the target.
An extended contingent allegiance condition may also be generated using an asynchronous event notification protocol. When the event is detected, the bus device that detected the event assumes the initiator role and transmits a SEND command with an AEN bit of one to the appropriate device(s) (see 12.2.2).
If the device wishes to generate an extended contingent allegiance condition during an asynchronous event notification, it shall send an INITIATE RECOVERY message following the IDENTIFY message (and following any queue tag message) and prior to the COMMAND phase of the SEND command. An extended contingent allegiance condition can be generated for only one I_T_L nexus at a time. The extended contingent allegiance condition is cleared when a RELEASE RECOVERY message is received from the device to which the INITIATE RECOVERY message was sent. The generation of a hard reset condition, or receipt of a BUS DEVICE RESET message, shall also clear the extended contingent allegiance condition.
During an extended contingent allegiance, only untagged I/O processes from the SCSI device to which the INITIATE RECOVERY message was sent shall be executed by the target for the logical unit. If the initiator sends a queue tag message, the target shall respond with QUEUE FULL status. After the extended contingent allegiance condition is cleared, any commands remaining in the command queue shall be executed.
There are two methods for implementation of queuing, tagged and untagged. Tagged queuing allows a target to accept multiple I/O processes from each initiator for each logical unit. Untagged queuing allows a target to accept one I/O process from each initiator for each logical unit or target routine. Untagged queuing may be supported by SCSI-1 or SCSI-2 devices. Tagged queuing is new in SCSI-2.
A target may support both tagged and untagged queuing. An initiator may not mix the use of tagged and untagged queuing for I/O processes to a logical unit, except during a contingent allegiance or extended contingent allegiance condition when only untagged initial connections are allowed. An initiator that elects to use tagged queuing does not preclude another initiator on the same SCSI bus from using untagged queuing.
An I/O process may be initiated any time the BUS FREE phase exists, even if an I/O process from a different initiator is active. If the disconnect privilege is not granted in the IDENTIFY message of the current I/O process, the target may either suspend all other I/O processes or it may return BUSY status to the current I/O process.
The I_T_x nexus sufficiently specifies the relationship so that the target can reconnect to the initiator to restore the pointers for I/O process as long as only one I/O process per I_T_x nexus is issued. It is the responsibility of the initiator to assure that only one such I/O process is issued at any time (see 7.5.2).
The command queue is setup by the target for each supported logical unit. Initiators may add or delete I/O processes to the queue. When adding an I/O process, the initiator may specify fixed order of execution, allow the target to define the order of execution, or specify that the I/O process is to be executed next.
If the disconnect privilege is not granted in the IDENTIFY message for a tagged I/O process, the target shall return BUSY status.
The queue tag messages (see 6.6.17) allow the initiator to establish a unique I_T_L_Q nexus to identify each I/O process. The I_T_L_Q nexus allows the target to reconnect to a specific I/O process, and allows the initiator to restore the set of pointers for that I/O process. An initiator may have several I/O processes ongoing to the same or different logical units as long as each has a unique nexus.
If only SIMPLE QUEUE TAG messages are used, the target may execute the commands in any order that is deemed desirable within the constraints of the queue management algorithm specified in the control mode page (see 8.3.3.1).
If ORDERED QUEUE TAG messages are used, the target shall execute the commands in the order received with respect to other commands received with ORDERED QUEUE TAG messages. All commands received with a SIMPLE QUEUE TAG message prior to a command received with an ORDERED QUEUE TAG message, regardless of initiator, shall be executed before that command with the ORDERED QUEUE TAG message. All commands received with a SIMPLE QUEUE TAG message after a command received with an ORDERED QUEUE TAG message, regardless of initiator, shall be executed after that command with the ORDERED QUEUE TAG message.
A command received with a HEAD OF QUEUE TAG message is placed first in the queue, to be executed next. A command received with a HEAD OF QUEUE TAG message shall be executed prior to any queued I/O process. Consecutive commands received with HEAD OF QUEUE TAG messages are executed in a last- in-first-out order.
An I/O process received without a queue tag message, while there are any tagged I/O commands in the command queue from the same initiator, is an incorrect initiator connection (see 7.5.2), unless there is a contingent allegiance or extended contingent allegiance condition.
A series of linked commands constitute a single I/O process. These commands are assigned the queue tag established in the initial connection. A command received with a HEAD OF QUEUE TAG message shall not suspend a series of linked commands for which the target has begun execution.
The RESERVE and RELEASE commands should be sent with an ORDERED QUEUE TAG message. Use of the HEAD OF QUEUE TAG message with these commands could result in reservation conflicts with previously issued commands.
There are two methods of dealing with the command queue following a contingent allegiance condition. The method used is specified in the control mode page by the queue error management bit (see 8.3.3.1).
The first method allows the execution of tagged I/O processes to resume when the contingent allegiance or extended contingent allegiance condition is cleared. The target returns BUSY status to other initiators while the contingent allegiance or extended contingent allegiance condition exists. During this time, all tagged I/O processes are suspended. All I/O processes used for recovery operations shall be untagged. The queue may be modified by removing all or selected I/O processes from the queue as part of the recovery procedure.
If commands are combined by the queuing algorithm such that the exception condition affects more than one command, then a contingent allegiance condition shall be generated for all affected commands.
The second method aborts all I/O processes when the contingent allegiance or extended contingent allegiance condition is cleared. A unit attention condition shall be generated for all other initiators and the additional sense code shall be set to COMMANDS CLEARED BY ANOTHER INITIATOR.
A device that does not support tagged I/O processes (e.g. not implemented, disabled by the Dque bit in the control mode page, or switched to an operating definition that does not include tagged I/O processes) it shall respond to any queue tag message with a MESSAGE REJECT message. The target shall continue the I/O process as if it were an untagged I/O process.
Tagged queuing may also be temporarily disabled during certain initialization periods or to control internal resource utilization. During these periods the target may return QUEUE FULL status or it may respond to any queue tag message with a MESSAGE REJECT message.
Several messages may be used to clear part or all of the command queue. Please refer to the ABORT, ABORT TAG, BUS DEVICE RESET, and CLEAR QUEUE messages in clause 6 for details.
When the target removes I/O processes from the queue for execution, a physical latency period may occur. At the end of this period, when the target is prepared to transfer the appropriate data, the target begins an ARBITRATION phase and, upon winning, enters a RESELECTION phase. After a successful reselection, the target sends the IDENTIFY message followed by a SIMPLE QUEUE TAG message with the queue tag value originally sent by the initiator. The initiator uses the I_T_L_Q nexus to identify the correct set of pointers and control blocks associated with the I/O process and to establish the necessary conditions for data transfer. The target begins data transfer. When the data transfer is successfully completed, the target returns GOOD status and terminates the I/O process with a COMMAND COMPLETE message.
If a target supports an optimizing algorithm the actual order in which the I/O processes are executed could be as shown in table 29.
As an example of the operation of the HEAD OF QUEUE TAG I/O process, consider that a new I/O process, identified by a HEAD OF QUEUE TAG message with a queue tag of 08h, is transmitted to the target while the ordered I/O process 03h is being executed. The I/O process 03h continues execution, but the new HEAD OF QUEUE TAG I/O process is placed in the queue for execution before all subsequent I/O processes. In this case, the queue for execution after the ordered I/O process 03h was executed would appear as shown in table 30.
The unit attention condition shall persist on the logical unit for each initiator until that initiator clears the condition as described in the following paragraphs.
If an INQUIRY command is received from an initiator to a logical unit with a pending unit attention condition (before the target generates the contingent allegiance condition), the target shall perform the INQUIRY command and shall not clear the unit attention condition. If the INQUIRY command is received after the target has generated the contingent allegiance condition for a pending unit attention condition, then the unit attention condition on the logical unit shall be cleared, and the target shall perform the INQUIRY command.
If any other command is received after the target has generated the contingent allegiance condition for a pending unit attention condition, the unit attention condition on the logical unit shall be cleared, and if no other unit attention condition is pending the target shall perform the command. If another unit attention condition is pending, the target shall not perform the command and shall generate another contingent allegiance condition.
If a REQUEST SENSE command is received from an initiator with a pending unit attention condition (before the target generates the contingent allegiance condition), then the target shall either:
If the target has already generated the contingent allegiance condition for the unit attention condition, the target shall perform the second action listed above.
If an initiator issues a command other than INQUIRY or REQUEST SENSE while a unit attention condition exists for that initiator (prior to generating the contingent allegiance condition for the unit attention condition), the target shall not perform the command and shall report CHECK CONDITION status unless a higher priority status as defined by the target is also pending (e.g. BUSY or RESERVATION CONFLICT).
If, after generating the contingent allegiance condition for a pending unit attention condition, the next command received from that initiator on the logical unit is not REQUEST SENSE, then that command shall be performed and the unit attention condition shall be cleared for that initiator on the logical unit and the sense data is lost (see 7.6).
If a target becomes a temporary initiator to issue a SEND command with an AEN bit of one, which informs the initiator (temporary target) of the unit attention condition, and the SEND command completes with GOOD status, then the target shall clear the unit attention condition for that initiator on the logical unit (see 7.5.5).
7.1 Command implementation requirements
The first byte of all SCSI commands shall contain an operation code as defined in this International Standard. Targets shall implement all commands with a mandatory operation code (see 7.1.2) both in clause 8 and in the appropriate clause for their device type.
7.1.1 Reserved
Reserved bits, fields, bytes, and code values are set aside for future standardization. Their use and interpretation may be specified by future extensions to this standard. A reserved bit, field, or byte shall be set to zero, or in accordance with a future extension to this standard. A target that receives a reserved bit, field, or byte that is not zero or receives a reserved code value shall terminate the command with CHECK CONDITION status and the sense key shall be set to ILLEGAL REQUEST. It shall also be acceptable for a target to interpret a bit, field, byte, or code value in accordance with a future extension to this International Standard.
7.1.2 Operation code types
The operation code types are defined in table 20.
Table 20 - Operation code type
+=============-===============================================================+
| Operation | Description |
| code type | |
|-------------+---------------------------------------------------------------|
| M | Mandatory - Commands so designated shall be implemented in |
| | order to meet the minimum requirement of this International |
| | Standard. |
| | |
| O | Optional - Commands so designated, if implemented, shall be |
| | implemented as defined in this International Standard. |
| | |
| V | Vendor-specific - Operation codes so designated are available|
| | for vendor defined commands. See the vendor specifications |
| | where compatibility is desired. |
| | |
| R | Reserved - Operation codes so designated shall not be used. |
| | They are reserved for future extensions to this |
| | International Standard. |
+=============================================================================+
7.2 Command descriptor block
A command is communicated by sending a command descriptor block to the target. For several commands, the command descriptor block is accompanied by a list of parameters sent during the DATA OUT phase. See the specific commands for detailed information.
Table 21 - Typical command descriptor block for six-byte commands
+======-========-========-========-========-========-========-========-========+
| Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|Byte | | | | | | | | |
|======+=======================================================================|
| 0 | Operation code |
|------+-----------------------------------------------------------------------|
| 1 | Logical unit number | (MSB) |
|------+------------------------------ ---|
| 2 | Logical block address (if required) |
|------+--- ---|
| 3 | (LSB) |
|------+-----------------------------------------------------------------------|
| | Transfer length (if required) |
| 4 | Parameter list length (if required) |
| | Allocation length (if required) |
|------+-----------------------------------------------------------------------|
| 5 | Control |
+==============================================================================+
Table 22 - Typical command descriptor block for ten-byte commands
+======-========-========-========-========-========-========-========-========+
| Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|Byte | | | | | | | | |
|======+=======================================================================|
| 0 | Operation code |
|------+-----------------------------------------------------------------------|
| 1 | Logical unit number | Reserved |
|------+-----------------------------------------------------------------------|
| 2 | (MSB) |
|------+--- ---|
| 3 | |
|------+--- Logical block address (if required) ---|
| 4 | |
|------+--- ---|
| 5 | (LSB) |
|------+-----------------------------------------------------------------------|
| 6 | Reserved |
|------+-----------------------------------------------------------------------|
| 7 | (MSB) Transfer length (if required) |
|------+--- Parameter list length (if required) ---|
| 8 | Allocation length (if required) (LSB) |
|------+-----------------------------------------------------------------------|
| 9 | Control |
+==============================================================================+
Table 23 - Typical command descriptor block for twelve-byte commands
+======-========-========-========-========-========-========-========-========+
| Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|Byte | | | | | | | | |
|======+=======================================================================|
| 0 | Operation code |
|------+-----------------------------------------------------------------------|
| 1 | Logical unit number | Reserved |
|------+-----------------------------------------------------------------------|
| 2 | (MSB) |
|------+--- ---|
| 3 | |
|------+--- Logical block address (if required) ---|
| 4 | |
|------+--- ---|
| 5 | (LSB) |
|------+-----------------------------------------------------------------------|
| 6 | (MSB) |
|------+--- ---|
| 7 | Transfer length (if required) |
|------+--- Parameter list length (if required) ---|
| 8 | Allocation length (if required) |
|------+--- ---|
| 9 | (LSB) |
|------+-----------------------------------------------------------------------|
|10 | Reserved |
|------+-----------------------------------------------------------------------|
|11 | Control |
+==============================================================================+
7.2.1 Operation code
The operation code (see table 24) of the command descriptor block has a group code field and a command code field. The three-bit group code field provides for eight groups of command codes. The five-bit command code field provides for thirty-two command codes in each group. Thus, a total of 256 possible operation codes exist. Operation codes are defined in the subsequent subclauses.
Table 24 - Operation code
+=====-========-========-========-========-========-========-========-========+
| Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|=====+==========================+============================================|
| | Group code | Command code |
+=============================================================================+
7.2.2 Logical unit number
The logical unit number is defined in the IDENTIFY message (6.6.7). The target shall ignore the logical unit number specified within the command descriptor block if an IDENTIFY message was received. It is recommended that the logical unit number in the command descriptor block be set to zero.
7.2.3 Logical block address
The logical block address on logical units or within a partition on device volumes shall begin with block zero and be contiguous up to the last logical block on that logical unit or within that partition.
7.2.4 Transfer length
The transfer length field specifies the amount of data to be transferred, usually the number of blocks. For several commands the transfer length indicates the requested number of bytes to be sent as defined in the command description. For these commands the transfer length field may be identified by a different name. See the following descriptions and the individual command descriptions for further information.
7.2.5 Parameter list length
The parameter list length is used to specify the number of bytes sent during the DATA OUT phase. This field is typically used in command descriptor blocks for parameters that are sent to a target (e.g. mode parameters, diagnostic parameters, log parameters, etc.). A parameter length of zero indicates that no data shall be transferred. This condition shall not be considered as an error.
7.2.6 Allocation length
The allocation length field specifies the maximum number of bytes that an initiator has allocated for returned data. An allocation length of zero indicates that no data shall be transferred. This condition shall not be considered as an error. The target shall terminate the DATA IN phase when allocation length bytes have been transferred or when all available data have been transferred to the initiator, whichever is less. The allocation length is used to limit the maximum amount of data (e.g. sense data, mode data, log data, diagnostic data, etc.) returned to an initiator.
7.2.7 Control field
The control field is the last byte of every command descriptor block. The control field is defined in table 25.
Table 25 - Control field
+=====-========-========-========-========-========-========-========-========+
| Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|=====+=================+===================================+========+========|
| | Vendor-specific | Reserved | Flag | Link |
+=============================================================================+
The flag bit specifies which message the target shall return to the initiator if the link bit is one and the command completes without error. Implementation of the flag bit is optional.
NOTE 46 The flag bit is typically used to cause an interrupt in the initiator between linked commands.
7.3 Status
The status byte and status byte code are defined in tables 26 and 27. A status byte shall be sent from the target to the initiator during the STATUS phase at the completion of each command unless the command is terminated by one of the following events:
Table 26 - Status byte
+=====-========-========-========-========-========-========-========-========+
| Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
|=====+=================+============================================+========|
| | Reserved | Status byte code |Reserved|
+=============================================================================+
Table 27 - Status byte code
+==================================-==============================+
| Bits of status byte | Status |
|----------------------------------| |
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
|-----+---+---+---+---+---+---+----+------------------------------|
| R | R | 0 | 0 | 0 | 0 | 0 | R | GOOD |
| R | R | 0 | 0 | 0 | 0 | 1 | R | CHECK CONDITION |
| R | R | 0 | 0 | 0 | 1 | 0 | R | CONDITION MET |
| R | R | 0 | 0 | 1 | 0 | 0 | R | BUSY |
| R | R | 0 | 1 | 0 | 0 | 0 | R | INTERMEDIATE |
| R | R | 0 | 1 | 0 | 1 | 0 | R | INTERMEDIATE-CONDITION MET |
| R | R | 0 | 1 | 1 | 0 | 0 | R | RESERVATION CONFLICT |
| R | R | 1 | 0 | 0 | 0 | 1 | R | COMMAND TERMINATED |
| R | R | 1 | 0 | 1 | 0 | 0 | R | QUEUE FULL |
|----------------------------------| |
| All other codes | Reserved |
|-----------------------------------------------------------------|
| Key: R = Reserved bit |
+=================================================================+
A definition of the status byte codes is given below.
7.4 Command examples
The following subclauses give examples of typical command processing in the SCSI environment.
7.4.1 Single command example
An I/O process containing one untagged READ command is used in this clause to illustrate a simple I/O process on the SCSI bus. This example does not include error or exception conditions.
7.4.2 Disconnect example
In the above single command example, the length of time necessary to obtain the data may require a time-consuming physical positioning operation. In order to improve system throughput, the target may disconnect from the initiator, thereby freeing the SCSI bus to allow other I/O process to occur.
7.4.3 Linked command example
An I/O process may contain multiple commands linked together. Upon completing a linked command successfully, the target automatically proceeds to the next linked command for the I/O process. All commands in a series of linked commands are addressed to the same nexus and are part of a single I/O process.
7.5.1 Programmable operating definition
Some applications require that the operating definition of a logical unit be modified to meet the special requirements of a particular initiator. The program-controlled modification of the operating definition is typically provided to allow operating systems to change the operating definition of a more recently developed targets to one that is more compatible with the operating system. This ability requires that the system comply with the low-level hardware definitions of SCSI-2.
7.5.2 Incorrect initiator connection
An incorrect initiator connection occurs on a reconnection if:
NOTES
47 An incorrect initiator connection may be indicative of a serious error and, if not detected, could result in an I/O process operating with a wrong set of pointers. This is considered a catastrophic failure on the part of the initiator. Therefore, vendor-specific error recovery procedures may be required to guarantee the data integrity on the medium. The target may return additional sense data to aid in this error recovery procedure (e.g. sequential-access devices may return the residue of blocks remaining to be written or read at the time the second command was received).
48 Some targets may not detect an incorrect initiator connection until after the command descriptor block has been received. 7.5.3 Selection of an invalid logical unit
The target's response to selection of a logical unit that is not valid is described in the following paragraphs.
7.5.4 Parameter rounding
Certain parameters sent to a target with various commands contain a range of values. Targets may choose to implement only selected values from this range. When the target receives a value that it does not support, it either rejects the command (CHECK CONDITION status with ILLEGAL REQUEST sense key) or it rounds the value received to a supported value. The target shall reject unsupported values unless rounding is permitted in the description of the parameter.
NOTE 49 Generally, the target should adjust maximum-value fields down to the next lower supported value than the one specified by the initiator. Minimum- value fields should be rounded up to the next higher supported value than the one specified by the initiator. In some cases, the type of rounding (up or down) is explicitly specified in the description of the parameter.
7.5.5 Asynchronous event notification
Implementation of asynchronous event notification is optional. This protocol can be used to inform processor devices that an asynchronous event has occurred. A SEND command with an AEN bit of one is issued to a processor device with a subsequent data phase that includes the REQUEST SENSE information. SCSI devices that respond to an INQUIRY command as a processor device type with asynchronous event notification capability may be notified of asynchronous events using this protocol. An SCSI device has to be capable of acting as an initiator in order to perform asynchronous event notification.
NOTE 50 Asynchronous event notification cannot be used with a device that acts as a temporary initiator (e.g. devices executing COPY commands) since they are not identified as a processor device.
NOTE 51 An SCSI device which can use asynchronous event notification at initialization time should provide means to defeat these notifications. This can be done with a switch or jumper wire. Devices that implement saved parameters may alternatively save the asynchronous event notification permissions either on a per SCSI device basis or as a system-wide option. In any case, a device conducts a survey with INQUIRY commands to be sure that the devices on the SCSI bus are appropriate destinations for SEND commands with an AEN bit of one. (The devices on the bus or the SCSI ID assignments may have changed.)
7.5.6 Unexpected reselection
An unexpected reselection occurs if an SCSI device attempts to reconnect to an I/O process for which a nexus does not exist. An SCSI device should respond to an unexpected reselection by sending an ABORT message.
7.6 Contingent allegiance condition
The contingent allegiance condition shall exist following the return of CHECK CONDITION or COMMAND TERMINATED status. The contingent allegiance condition shall be preserved for the I_T_x nexus until it is cleared. The contingent allegiance condition shall be cleared upon the generation of a hard reset condition, or by an ABORT message, a BUS DEVICE RESET message, or any subsequent command for the I_T_x nexus. While the contingent allegiance condition exists the target shall preserve the sense data for the initiator.
7.7 Extended contingent allegiance condition
Implementation of extended contingent allegiance is optional. The extended contingent allegiance condition extends the contingent allegiance condition for an I_T_x nexus. This condition is generated by the target sending an INITIATE RECOVERY message to the initiator following CHECK CONDITION or COMMAND TERMINATED status and prior to the COMMAND COMPLETE message. This condition shall be preserved until it is cleared by a BUS DEVICE RESET message, a RELEASE RECOVERY message, or a hard reset condition.
NOTES
52 It is not required to generate an extended contingent allegiance condition for every CHECK CONDITION or COMMAND TERMINATED status that occurs. Simple errors not requiring an extended recovery may be dealt with by using the contingent allegiance protocol.
53 During the existence of the extended contingent allegiance condition, appropriate error recovery sequences may be executed. Such commands can correct data, modify or delete queued commands, perform LOG SENSE commands and obtain diagnostic information. Extended contingent allegiance is recommended for error conditions that may require execution of multiple-step error-recovery protocols without interference from other initiators. 7.8 Queued I/O processes
The implementation of queuing for I/O processes is optional. Queuing of I/O processes allows a target to accept multiple I/O processes.
7.8.1 Untagged queuing
Untagged queuing allows a target to accept a command from an initiator for a logical unit or target routine while I/O processes from other initiators are being executed. Only one command for each I_T_x nexus shall be accepted at a time.
7.8.2 Tagged queuing
Tagged queuing allows a target to accept multiple I/O processes from the same or different initiators until the logical unit's command queue is full. If an I/O process is received and the command queue is full, the target shall terminate the I/O process with QUEUE FULL status.
NOTE 54 Initiators should not issue another I/O processes following a reservation request until that request is honoured by the target. This prevents possible sequencing errors or file system corruption.
7.8.3 Example of queued I/O process
This example of queuing I/O processes illustrates the execution of a number of commands. After each command, the state of the queue kept in the target is shown to indicate the function actually performed by the queuing.
7.8.3.1 Typical sequences for tagged queuing
An I/O process using tagged queuing uses the following sequences for normal execution. The initiator first arbitrates for the SCSI bus, and after successfully obtaining the SCSI bus, selects the appropriate SCSI device. The ATN signal is asserted during the SELECTION phase to indicate that a MESSAGE OUT phase is requested by the initiator. The first message byte transferred is an IDENTIFY message.
The ATN signal continues to be asserted during the MESSAGE OUT phase to indicate that the initiator has another message. The second message byte transferred is the first byte of the appropriate queue tag message, in this case a SIMPLE QUEUE TAG message. The third and last message byte is transmitted containing the second byte of the queue tag message, the queue tag.
As it is transferred, the ATN signal is negated to indicate that no more message bytes are available. The target then transfers the command descriptor block. Assuming the command requires disconnection, the target transmits a DISCONNECT message to the initiator and then enters the BUS FREE phase. The target places the command, identified by the I_T_L_Q nexus, at the appropriate place in the command queue.
7.8.3.2 Example of tagged queuing
An example of the execution of five queued I/O processes is described to demonstrate how tagged queuing operates. All tagged I/O processes are from one initiator to a single logical unit of a single target. The five I/O processes are defined in table 28. The target is a direct-access device. At the time the I/O processes are first being executed, it is assumed that the actuator is in position to access logical block 10 000.
Table 28 - Commands in order received by target
+===========-=============-=============-============-=============-==========+
| Command | Queue tag | Queue tag | Logical | Transfer | Status |
| | message | value | block | length | |
| | | | address | | |
|-----------+-------------+-------------+------------+-------------+----------|
| READ | SIMPLE | 01h | 10 000 | 1 000 | Queued |
| READ | SIMPLE | 02h | 100 | 1 | Queued |
| READ | ORDERED | 03h | 1 000 | 1 000 | Queued |
| READ | SIMPLE | 04h | 10 000 | 1 | Queued |
| READ | SIMPLE | 05h | 2 000 | 1 000 | Queued |
+=============================================================================+
The optimum order would require that those blocks close to the actuator position be the first blocks accessed, followed by those increasingly far from the actuator position. However, the command with queue tag 03h is an ordered I/O process, so that all simple I/O processes transferred previously must be executed before, while all simple I/O processes transferred after the ordered I/O process must be executed after the ordered I/O process.
Table 29 - Commands in order of execution
+===========-=============-=============-============-=============-==========+
| Command | Queue tag | Queue tag | Logical | Transfer | Status |
| | message | value | block | length | |
| | | | address | | |
|-----------+-------------+-------------+------------+-------------+----------|
| READ | SIMPLE | 01h | 10 000 | 1 000 | Queued |
| READ | SIMPLE | 02h | 100 | 1 | Queued |
| READ | ORDERED | 03h | 1 000 | 1 000 | Queued |
| READ | SIMPLE | 05h | 2 000 | 1 000 | Queued |
| READ | SIMPLE | 04h | 10 000 | 1 | Queued |
+=============================================================================+
I/O processes with queue tag values 01h and 02h are executed in the order received since the actuator is already in position to execute I/O process 01h. I/O process 02h must be executed before I/O process 04h or 05h because the ordered I/O process 03h was transmitted after I/O processes 01h and 02h but before I/O processes 04h and 05h. I/O process 03h is then executed after I/O process 02h. The I/O processes 04h and 05h are executed after the ordered I/O process 03h. I/O process 05h is executed before I/O process 04h because the actuator is in position to access block 2 000 after executing I/O process 03h. I/O process 04h is executed last.
Table 30 - Modified by HEAD OF QUEUE TAG message
+===========-=============-=============-============-=============-==========+
| Command | Queue tag | Queue tag | Logical | Transfer | Status |
| | message | value | block | length | |
| | | | address | | |
|-----------+-------------+-------------+------------+-------------+----------|
| READ | ORDERED | 03h | 1 000 | 1 000 | Executing|
| READ |HEAD OF QUEUE| 08h | 0 | 8 | Queued |
| READ | SIMPLE | 05h | 2 000 | 1 000 | Queued |
| READ | SIMPLE | 04h | 10 000 | 1 | Queued |
+=============================================================================+
To obtain maximum performance gains using tagged queuing requires careful implementation of the queuing algorithms in the target. In addition, initiators should allow a maximum number of simple I/O processes to be executed with a minimum number of ordered I/O processes. RESERVE and RELEASE commands, SET LIMITS commands, and appropriate software locking conventions should be used to guarantee the proper relationship between the commands executed and the data stored on the peripheral devices. These conventions are not defined by this standard.
7.9 Unit attention condition
The target shall generate a unit attention condition for each initiator on each valid logical unit whenever the target has been reset by a BUS DEVICE RESET message, a hard reset condition, or by a power-on reset. The target shall also generate a unit attention condition on the affected logical unit(s) for each initiator whenever one of the following events occurs:
NOTES
56 Targets may queue unit attention conditions on logical units. After the first unit attention condition is cleared, another unit attention condition may exist (e.g. a power on condition followed by a microcode change condition).
57 See 7.5.3 for requirements concerning selection of an invalid logical unit.