6. SCSI Commands and Status This section defines the SCSI command and status structures and gives several examples. 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. 6.1. Command Implementation Requirements The first byte of all SCSI commands shall contain an operation code as defined in this standard. Targets shall implement all commands with a mandatory operation code (see 6.1.2) both in section 7 and in the appropriate section for their device type. 6.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 standard. 6.1.2. Operation Code Types Operation Code Type Description --------- ------------------------------------------------------------------- M Mandatory - Commands so designated shall be implemented in order to meet the minimum requirement of this standard. O Optional - Commands so designated, if implemented, shall be implemented as defined in this 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 standard. 6.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. 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. Table 6-1: 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 6-2: 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 6-3: 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 | ============================================================================== 6.2.1. Operation Code The operation code (Table 6-4) 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 Sections of this document. The group code specifies one of the following groups: Group 0 - six-byte commands (see Table 6-1) Group 1 - ten-byte commands (see Table 6-2) Group 2 - ten-byte commands (see Table 6-2) Group 3 - reserved Group 4 - reserved Group 5 - twelve-byte commands (see Table 6-3) Group 6 - vendor specific Group 7 - vendor specific Table 6-4: Operation Code ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ============================================================================== | Group Code | Command Code | ============================================================================== 6.2.2. Logical Unit Number The logical unit number is defined in the IDENTIFY message (5.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. 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. 6.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. 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. 6.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. 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. 6.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. 6.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. 6.2.7. Control Field The control field is the last byte of every command descriptor block. The control field is defined in Table 6-5. Table 6-5: 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. 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. IMPLEMENTORS NOTE: The flag bit is typically used to cause an interrupt in the initiator between linked commands. 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. 6.3. Status The status byte and status byte code are specified in Tables 6-6 and 6-7. 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: (1) an ABORT message (2) an ABORT TAG message (3) a BUS DEVICE RESET message (4) a CLEAR QUEUE message (5) a hard reset condition (6) an unexpected disconnect (see 5.1.1) The STATUS phase normally occurs at the end of a command but in some case may occur prior to transferring the command descriptor block. Table 6-6: Status Byte ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ============================================================================== | Reserved | Status Byte Code |Reserved| ============================================================================== Table 6-7: Status Byte Code ============================================================================== Bits of Status Byte ----------------------------- 7 6 5 4 3 2 1 0 Status ------------------------------------------------------------------------------ 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. GOOD. This status indicates that the target has successfully completed the command. CHECK CONDITION. This status indicates that a contingent allegiance condition has occurred (see 6.6). CONDITION MET. This status or INTERMEDIATE-CONDITION MET is returned whenever the requested operation is satisfied (see the SEARCH DATA and PRE- FETCH commands). 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. 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. INTERMEDIATE-CONDITION MET. This status is the combination of the CONDITION MET and INTERMEDIATE statuses. 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. 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 5.6.22). This status also indicates that a contingent allegiance condition has occurred (see 6.6). 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. 6.4. Command Examples The following sections give examples of typical command processing in the SCSI environment. 6.4.1. Single Command Example An I/O process containing one untagged READ command is used in this section to illustrate a simple I/O process on the SCSI bus. This example does not include error or exception conditions. 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. 6.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. 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. 6.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. The commands are not entirely independent. When using the relative address bit (see 8.1.10), 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. 6.5. Command Processing Considerations and Exception Conditions The following sections describe some exception conditions and errors associated with command processing and the sequencing of commands. 6.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 which is more compatible with the operating system. This ability requires that the system comply with the low- level hardware definitions of SCSI-2. 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 at 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. 6.5.2. Incorrect Initiator Connection An incorrect initiator connection occurs on a reconnection if: (1) an initiator attempts to reconnect to an I/O process, and (2) a soft reset condition has not occurred, and (3) the initiator does not send an ABORT, ABORT TAG, BUS DEVICE RESET, CLEAR QUEUE, or TERMINATE I/O PROCESS message during the same MESSAGE OUT phase as the IDENTIFY message. An incorrect initiator connection also occurs on an initial connection when an initiator: (1) attempts to establish an I_T_L_Q nexus when an I_T_L nexus already exists from a previous connection, or (2) attempts to establish an I_T_L nexus when an I_T_L_Q nexus already exists unless there is a contingent allegiance or extended contingent allegiance condition present for the logical unit or target routine. 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 5.2.2.2. IMPLEMENTORS NOTES: (1) 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). (2) Some targets may not detect an incorrect initiator connection until after the command descriptor block has been received. 6.5.3. Selection of an Invalid Logical Unit The target's response to selection of a logical unit which is not valid is described in the following paragraphs. The logical unit may not be valid because: (1) the target does not support the logical unit (e.g., some targets support only one peripheral device). In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to any other command except REQUEST SENSE the target shall terminate the command with CHECK CONDITION status. In response to a REQUEST SENSE command the target shall return sense data. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT SUPPORTED. (2) the target supports the logical unit, but the peripheral device is not currently attached to the target. In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to any other command except REQUEST SENSE the target shall terminate the command with CHECK CONDITION status. In response to a REQUEST SENSE command the target shall return sense data. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT SUPPORTED. (3) the target supports the logical unit and the peripheral device is attached, but not operational. In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. The target's response to any command other than INQUIRY and REQUEST SENSE is vendor specific. (4) the target supports the logical unit but is incapable of determining if the peripheral device is attached or is not operational when it is not ready. In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to a REQUEST SENSE command the target shall return the REQUEST SENSE data with a sense key of NO SENSE unless a prior error condition exists. The target's response to any other command is vendor specific. 6.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. 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. IMPLEMENTORS NOTE: 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. 6.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. IMPLEMENTORS NOTE: 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. Parameters affecting the use of asynchronous event notification are contained in the control mode page (see 7.3.3.1). The four uses of asynchronous event notification are: (1) informing a processor of an error condition encountered after command completion (2) informing all processor devices that a newly initialized device is available (3) informing all processor devices of other unit attention conditions (4) informing all processor devices of other asynchronous events. Other uses of asynchronous event notification are not prohibited, however this protocol is not intended to be used while an I_T_L or I_T_L_Q nexus exists between the processor device (i.e., the initiator of the nexus) and the other SCSI device (i.e., the target of the nexus). Asynchronous event notification is not intended for use with target routines (i.e., an I_T_R or I_T_R_Q nexus). 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 5.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 11.2.2.). The data sent is shown in Table 11-4. 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 used 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 5.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. IMPLEMENTORS NOTE: 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 which 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.) 6.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. 6.6. Contingent Allegiance Condition The contingent allegiance condition shall exist following the return of CHECK CONDITION or COMMAND TERMINATED status and may optionally exist following an unexpected disconnect. 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. 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 queued commands for the logical unit or target routine for which the contingent allegiance condition exists shall be suspended until the contingent allegiance condition is cleared. 6.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. 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 queued commands 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. IMPLEMENTORS NOTES: (1) 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. (2) 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. An extended contingent allegiance condition may also be generated using an asynchronous event notification protocol. When the event is detected, the bus device which detected the event assumes the initiator role and transmits a SEND command with an AEN bit of one to the appropriate device(s) (see 11.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. 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. 6.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 for execution at a later time. 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 or target routine. Untagged queuing allows a target to accept one I/O process from each initiator for each logical unit. A target may be capable of both methods of queuing, but only one method may be used by an initiator at a time. Other initiators may choose the other queuing method; in that case, the target may manage both types of queued commands. Untagged queuing may be supported by SCSI-1 or SCSI-2 devices. Tagged queuing is new in SCSI-2. 6.8.1. Untagged Queuing Untagged queuing allows a target to accept a command from an initiator for a logical unit or target routine while a command from another initiator is being executed. Only one command for each I_T_x nexus shall be accepted at a time. 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 new I/O process, the target may either suspend the active I/O process or it may return BUSY status to the new 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 6.5.2). 6.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. The command queue is setup by the target for each supported logical unit and target routine. 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 5.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 or target routines 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 7.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 an 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 an 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 not suspend an I/O process for which the target has begun execution. 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 6.5.2) unless there is a contingent allegiance or extended contingent allegiance condition. A series of linked commands are a single I/O process, and 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. The TEST UNIT READY and INQUIRY commands are often sent with a HEAD OF QUEUE TAG message, since the information returned has no effect on the condition of the logical unit. Two error recovery options are allowed. The error recovery option to be used is specified in the control mode page (see 7.3.3.1). The first post-recovery option is to continue execution of commands in the queue after the contingent allegiance or extended contingent allegiance condition has cleared. The target returns BUSY status to other initiators while the contingent allegiance or extended contingent allegiance condition exists. During this time all commands in the queue are suspended. All commands used for recovery operations shall be untagged commands. The queue may be modified by removing all or selected commands in the queue as part of the recovery procedure. If commands are combined by the queuing algorithm such that the error affects more than one command, then a contingent allegiance condition shall be generated for all affected commands. The second recovery option clears the queue after the contingent allegiance or extended contingent allegiance condition has been cleared. When the queue is cleared because of this recovery option, 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. Deferred errors are normally related to a command that has already completed. As such, there is no attempt to return the queue tag value assigned to the original command. A device that does not support tagged queuing for any reason (e.g., not implemented, disabled by the DQue bit in the control mode page, or it has been switched to an operating definition that does not include tagged queuing) shall respond to any queue tag message with a MESSAGE REJECT message. The target shall continue the I/O process as if it was an untagged I/O process. Tagged queuing may also be temporarily disabled internal to the SCSI device during certain initialization periods or to control internal resource utilization. During these periods the target may elect to 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 Section 5 for details. 6.8.3. Example of Queued I/O Process An example of I/O process queuing benefits from the consideration of 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. 6.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. 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. 6.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 6-8. 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 10000. Table 6-8: Commands in Order Received by Target Queue Logical Tag Block Transfer Command Queue Tag Message Value Address Length Status ------- ----------------- ----- ------- --------- --------- READ SIMPLE 01h 10000 1000 Queued READ SIMPLE 02h 100 1 Queued READ ORDERED 03h 1000 1000 Queued READ SIMPLE 04h 10000 1 Queued READ SIMPLE 05h 2000 1000 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. If a target supports an optimizing algorithm the actual order in which the I/O processes are executed could be as shown in Table 6-9. Table 6-9: Commands in Order of Execution Queue Logical Tag Block Transfer Command Queue Tag Message Value Address Length Status ------- ----------------- ----- ------- --------- --------- READ SIMPLE 01h 10000 1000 Queued READ SIMPLE 02h 100 1 Queued READ ORDERED 03h 1000 1000 Queued READ SIMPLE 05h 2000 1000 Queued READ SIMPLE 04h 10000 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 2000 after executing I/O process 03h. I/O process 04h is executed last. 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 6-10. Table 6-10: Modified by HEAD OF QUEUE TAG Message Queue Logical Tag Block Transfer Command Queue Tag Message Value Address Length Status ------- ----------------- ----- ------- --------- --------- READ ORDERED 03h 1000 1000 Executing READ HEAD OF QUEUE 08h 0 8 Queued READ SIMPLE 05h 2000 1000 Queued READ SIMPLE 04h 10000 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. 6.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: (1) A removable medium may have been changed. (2) The mode parameters in effect for this initiator have been changed by another initiator. (3) The version or level of microcode has been changed. (4) Tagged commands queued for this initiator were cleared by another initiator. (5) INQUIRY data has been changed. (6) The mode parameters in effect for this initiator have been restored from non-volatile memory. (7) A change in the condition of a synchronized spindle. (8) Any other event occurs that requires the attention of the initiator. IMPLEMENTORS NOTES: (1) 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). The initiator can clear all pending unit attention conditions by repeatedly sending the REQUEST SENSE command until a sense key other than UNIT ATTENTION is returned by the target. (2) See 6.5.3 for requirements concerning selection of an invalid logical unit. 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 may either: (1) report any pending sense data and preserve the unit attention condition on the logical unit or (2) report the unit attention condition, may discard any pending sense data, and clear the unit attention condition on the logical unit for that initiator. 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 6.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 6.5.5). (This page is intentionally blank.)