X3T9.2/90-125 Date: 6/30/90 John Lohmeyer Chairman X3T9.2 Subject: Additional SCSI Functions Resulting From a Check Condition. Beginning with the meeting in Colorado Springs, there was discussion of the ramifications of a Check Condition in a multiprocessing environment. Proposals similar to the one I am formally submitting now were discussed in very brief terms. At that time the committee felt that the multi processor environments should be satisfied with the SCSI-2 Contingent Allegiance and Extended Contingent Allegiance definitions. Time has passed, additional designs have been completed and shipped, but the multiprocessor environment is still not satisfied for all system implementors. Implementations which use command linking become unlinked by the Contingent Allegiance definition. Even implementations which use reservations may end up without reservation with the Contingent Allegiance and Extended Contingent Allegiance definitions (since RESERVE or RELEASE may be one of the pending commands blown away by a QErr bit of one). Consider the following excerpts from SCSI-2 Rev 10C: "6.6. Contingent Allegiance Condition ... 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, 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 ... 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. ... After the extended contingent allegiance condition is cleared any commands remaining in the command queue shall be executed." A few observations arise from Section 6. For systems not using Reservations and not using command linking, but using command queuing, the definition is workable. What happens with command linking is not addressed. For systems using Reservations and connected to targets without separate status for each initiator, unexpected BUSY status occurs rather than Reservation Conflict. For multi processor systems of existing design (rather than designed for SCSI) this can cause them to "punt" and issue a BUS DEVICE RESET message or a hard reset condition. Consider further: "7.2.1. CHANGE DEFINITION Command ... (2) The target should not generate extended contingent allegiance conditions by issuing an INITIATE RECOVERY message." Extended Contingent Allegiance is not an option when a Change Definition command has switched the target to SCSI-1. This applies to deferred errors from a SCSI-2 Initiator which has not issued the Change Definition command. For further consideration: "7.3.3.1. Control Mode Page ... A queue error management (QErr) bit of zero specifies that those commands still queued after the target has entered the contingent allegiance or extended contingent allegiance conditions shall continue execution in a normal manner when that condition has terminated (see 6.8). A QErr bit of one specifies that those commands still queued after the target has entered the contingent allegiance or extended contingent allegiance conditions shall be aborted when that condition has terminated. A unit attention condition shall be generated for each initiator which had commands in the queue except the initiator that received the original INITIATE RECOVERY message. When reporting the unit attention condition, the target shall set the additional sense code to TAGGED COMMANDS CLEARED BY ANOTHER INITIATOR." This places a restriction on other Initiators even if the target is richly implemented with separate facilities for each initiator. In addition it requires that other initiators with a non tagged command queued shall receive a TAGGED COMMANDS CLEARED BY ANOTHER INITIATOR sense code or perhaps it requires that non tagged queued not be aborted. Consider further: "7.1.2.2. Using the REQUEST SENSE Command Whenever a contingent allegiance condition (6.6) is established, the initiator that received the error should issue a REQUEST SENSE command to receive the sense data describing what caused the contingent allegiance condition. If the initiator issues some other command, the sense data is lost." When using command queuing the next command may be coming down the path and not interlocked with contingence allegiance. To prevent a loss of sense data the HBA must be an interpretive traffic cop with the right to veto the host. Although I have cited some pitfalls for existing system architectures, I do not mean to imply that the definitions are a problem for all or even many definitions. I merely wish to point out the legitimacy for an additional option in dealing with error conditions in multi processor environments. The proposal adds the optional capability to automatically reserve a unit upon a check condition and to add the capability to disable untagged queuing as well as tagged queuing. These capabilities are achieved by adding Automatic Reservation on Check condition (ARC) and Disable All Queuing (DAQ) bits to the Control Mode Page. Please add an additional option for exception handling by changing the Control Page to: 7.3.3.1. Control Mode Page Table 7-66: Control Mode Page ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | PS |Reserved| Page Code (0Ah) | -----|-----------------------------------------------------------------------| 1 | Page Length (06h) | -----|-----------------------------------------------------------------------| 2 | Reserved | RLEC | -----|-----------------------------------------------------------------------| 3 | Queue Algorithm Modifier |Resserv.| DAQ | QErr | DQue | -----|-----------------------------------------------------------------------| 4 | EECA | ARC | Reserved | RAENP | UAAENP | EAENP | -----|-----------------------------------------------------------------------| 5 | Reserved | -----|-----------------------------------------------------------------------| 6 | | -----|--- Ready AEN Holdoff Period ---| 7 | | ============================================================================== The control mode page (Table 7-66) provides controls over several SCSI-2 features which are applicable to all device types such as tagged queuing, extended contingent allegiance, asynchronous event notification, and error logging. A report log exception condition (RLEC) bit of one specifies that the target shall report log exception conditions as described in 7.3.2. A RLEC bit of zero specifies that the target shall not report log exception conditions. The queue algorithm modifier field (Table 7-67) specifies restrictions on the algorithm used for re-ordering commands that are tagged with the SIMPLE QUEUE TAG message. Table 7-67: Queue Algorithm Modifier =============================================== Value Definition ------- -------------------------------- 0h Restricted re-ordering 1h Unrestricted re-ordering allowed 2h - 7h Reserved 8h - Fh Vendor specific =============================================== A value of zero in this field specifies that the target shall order the actual execution sequence of the queued commands from each initiator such that data integrity is maintained for that initiator. This means that, if the transmission of new commands was halted at any time, the final value of all data observable on the medium shall have exactly the same value as it would have if the commands had been executed in the same received sequence without tagged queuing. The restricted reordering value shall be the default value. A value of one in this field specifies that the target may re- order the actual execution sequence of the queued commands in any manner it selects. Any data integrity exposures related to command sequence order are explicitly handled by the initiator through the selection of appropriate commands and queue tag messages. A disable all queuing (DAQ) bit of zero specifies that the QErr and DQue bits apply only to tagged commands. A (DAQ) bit of one specifies that the QErr bit and DQue bits apply to both tagged and untagged commands. A queue error management (QErr) bit of zero specifies that those commands still queued after the target has entered the contingent allegiance or extended contingent allegiance conditions shall continue execution in a normal manner when that condition has terminated (see 6.8). If DAQ is zero, a QErr bit of one specifies that those tagged commands still queued after the target has entered the contingent allegiance or extended contingent allegiance conditions shall be aborted when that condition has terminated. A unit attention condition shall be generated for each initiator which had commands in the queue except the initiator that received the original CHECK CONDITION, COMMAND TERMINATED status, or INITIATE RECOVERY message. Optionally if the contingent allegiance condition resulted from an unexpected bus free (Editorial Note: should the "unexpected disconnect" in the contingent allegiance definition, SECTION 6.6, be "unexpected bus free"?) the unit attention condition shall be generated for all initiators with a tagged command in the queue. When reporting the unit attention condition, the target shall set the additional sense code to TAGGED COMMANDS CLEARED BY ANOTHER INITIATOR. (Editorial note: There is a discrepancy between this section and Table 7-41. In Table 7-41 there is no sense code "TAGGED COMMANDS CLEARED BY ANOTHER INITIATOR". In that section the related sense code is "COMMANDS CLEARED BY ANOTHER INITIATOR".) If DAQ is one, a QErr bit of one specifies that those commands still queued after the target has entered the contingent allegiance or extended contingent allegiance conditions shall be aborted when that condition has terminated. A unit attention condition shall be generated for each initiator which had commands in the queue except the initiator that received the original CHECK CONDITION, COMMAND TERMINATED status, or INITIATE RECOVERY message. Optionally if the contingent allegiance condition resulted from an unexpected bus free, the unit attention condition shall be generated for all initiators with a tagged command in the queue. When reporting the unit attention condition, the target shall set the additional sense code to COMMANDS CLEARED BY ANOTHER INITIATOR." If DAQ is zero, a disable queuing (DQue) bit of zero specifies that tagged queuing shall be enabled if the target supports tagged queuing. A DQue bit of one specifies that tagged queuing shall be disabled. Any queued, tagged commands for that I_T_x nexus shall be aborted. Any subsequent queue tag message received shall be rejected with a MESSAGE REJECT message and the I/O process shall be executed or rejected as an untagged command (see 6.8.1). If DAQ is one, a disable queuing (DQue) bit of zero specifies that all queuing shall be enabled if the target supports queuing. A DQue bit of one specifies that all queuing (both tagged and untagged) shall be disabled. Any queued commands for that I_T_x nexus shall be aborted. Any subsequent queue tag message received shall be rejected with a MESSAGE REJECT message and the I/O process shall be executed or rejected as an untagged command. An enable extended contingent allegiance (EECA) bit of one specifies that extended contingent allegiance is enabled (see 6.7). An EECA bit of zero specifies that extended contingent allegiance is disabled. An automatic reservation on Check Condition (ARC) bit of zero indicates that reservations should be unaffected by the Check Condition. An ARC bit of one enables an automatic unit reservation to the initiator with which a contingent allegiance exists. The automatic reservation shall be preserved for the I_T_X nexus, until it is cleared by a RELEASE command, a Bus Device Reset message, an Abort message, or a hard reset condition. While the ARC condition exists, the target shall respond to any other request for access to the logical unit with a reservation conflict (see 8.2.12.2). If QErr is zero, extent reservations for other initiators should be honored and those reservations should be preserved until a RELEASE command for that initiator is executed. If QErr is one, extent reservations for other initiators should be honored but those reservations should be released prior to generating a unit attention condition for each initiator which had extent reservations except the initiator that received the original CHECK CONDITION, COMMAND TERMINATED status, or INITIATE RECOVERY message. The RAENP, UAAENP, and EAENP bits enable specific events to be reported via the asynchronous event notification protocol. When all three bits are zero, the target shall not create asynchronous event notifications. A ready AEN permission (RAENP) bit of one specifies that the target may issue an asynchronous event notification upon completing its initialization sequence instead of generating a unit attention condition. A RAENP bit of zero specifies that the target shall not issue an asynchronous event notification upon completing its initialization sequence. IMPLEMENTORS NOTE: If the target's default value for the RAENP bit is one and it does not implement saved parameters or include a hardware switch, then it may not be possible to disable the initialization sequence asynchronous event notification. A unit attention AEN permission (UAAENP) bit of one specifies that the target may issue an asynchronous event notification instead of creating a unit attention condition upon detecting an event which would cause a unit attention condition (other than upon completing an initialization sequence). A UAAENP bit of zero specifies that the target shall not issue an asynchronous event notification instead of creating a unit attention condition. An error AEN permission (EAENP) bit of one specifies that the target may issue an asynchronous event notification upon detecting a deferred error condition instead of waiting to report the deferred error on the next command. An EAENP bit of zero specifies that the target shall not report deferred error conditions via an asynchronous event notification. The ready AEN holdoff period field specifies the minimum time in milliseconds after the target starts its initialization sequence that it shall delay before attempting to issue an asynchronous event notification. This value may be rounded up as defined in 6.5.4. Please let me know if you have any questions about this proposal. G.E. Milligan