Date: 07-May-93 21:15 PDT From: INTERNET:GFRAZIER@ausvm6.vnet.ibm.com Subj: Message from Internet Sender: gfrazier@ausvm6.vnet.ibm.com Received: from relay1.UU.NET by ihc.compuserve.com (5.65/5.930129sam) id AA25551; Sat, 8 May 93 00:15:04 -0400 Received: from ncrcom.DaytonOH.NCR.COM by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA13230; Sat, 8 May 93 00:14:40 -0400 Received: from ncrwic by ncrcom.DaytonOH.NCR.COM id fe16663; 7 May 93 18:30 EDT Received: by ncrwic.WichitaKS.NCR.COM; 7 May 93 16:29:55 CDT Received: by donald.WichitaKS.NCR.COM; 7 May 93 16:32:13 CDT Received: by ncrwic.WichitaKS.NCR.COM; 7 May 93 16:25:28 CDT Received: from vnet.ibm.com by ncrcom.DaytonOH.NCR.COM id aa08975; 7 May 93 16:34 EDT Received: from AUSVM6 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 7755; Fri, 07 May 93 16:08:43 EDT Date: Fri, 7 May 93 14:49:04 CDT From: GFRAZIER@ausvm6.vnet.ibm.com To: scsi@WichitaKS.NCR.COM Message-Id: <9305071634.aa08975@ncrcom.DaytonOH.NCR.COM> X3T9.2/93-065 rev. 2 At the April plenary, the following SCSI-3/SCSI-2 compatibility problem was posed. When a SCSI-3 target returns a CHECK CONDITION, it freezes its queue for the task set until it receives a CLEAR ACA message from the initiatiator with the check condition. Also, during the ACA condition, the target will reject all commands without an ACA tag. SCSI-2 initiators, however, do not send these ACA messages nor tags. Therefore, they will lock up after any check condition and will require a reset to recover. Three alternative solutions were discussed: A) Clear ACA with an untagged command. B) Use the Change Definition command. C) Use the Mode Select command. The proposed wording for alternative A) was rejected because the group could not agree on the exact wording and because ACA was not the only compatibility problem. SCSI-3 has also defined additional status bytes, and other incompatibilities may be discovered in the future. added in the future. The problem was sent back to the working group for a solution. In hopes of reaching a solution at the Sante Fe work group, I have attemped to summarize the tradeoffs of the three alternatives. Alternative A -- Special Case in SIP Since the only place where SCSI-2 and SCSI-3 compatibility is an issue is in parallel SCSI, then the SOMETHING SIMILAR TO the following wording could be included in SIP: In the presence of an ACA condition for an I_T_X nexus, a target shall treat the receipt on any untagged command from the I_T_X nexus as an ACA tagged command followed by a clear ACA message. Advantages: - Targets do not have to implement Change Definition command nor new Mode Select options. - Targets do not need to save different operation modes for each initiator. - All Targets implement SCSI-3/SCSI-2 compatibility in an identical manner. Disadvantages: - Does not eliminate all compatibility problems such as new status bytes and reserved LUN field in the command. Alternative B -- Change Definition The Change Definition command would provide SCSI-2/SCSI-3 compatibility only if the SCSI-3 devices assume SCSI-2 mode upon or power up. Without this requirement, then the SCSI-2 initiator may not be able to issue a Change Definition command due to an ACA condition which it cannot clear. If this definition is chosen, then some or all of the following is necessary: 1) Define a new Operating Definition Parameter for SCSI-3 (e.g. 04h). This parameter is used in the Implemented Operating Definition page (81h) returned with the Inquiry command, and in the Definition Parameter field in the Change Definition command. 2) Include a statement or implementors note stating that SCSI-3 devices should assume SCSI-2 mode upon power up. 3) Include an implementors note listing the changes in behavior upon entering SCSI-3 mode. (e.g. ACA, Status bytes, new messages, tags, etc.) Advantage: Can be made to resolve ALL incompatibilities--not just ACA. Disadvantage: Requires targets to implement multiple operating modes. Requires targets to operate in multiple modes simultaneously to support multi-initiator systems. Alternative C -- Mode Select As the Change Definition alternative, this method would provide compatibility only if the SCSI-3 devices assume SCSI-2 mode upon power up. This option provides the capability of changing subsets of SCSI-3 features instead of all of them or none of them. A strawman proposal for this option is to use the Control Mode page: -------------------------------------------------------------------- Bit:| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | --------------------------------------------------------------------| | 0 | PS |RESERVD| PAGE CODE (0Ah) | |-----|--------------------------------------------------------------| | 1 | PAGE LENGTH (06h) | |-----|--------------------------------------------------------------| Byte: | 2 | RESERVED | |-----|--------------------------------------------------------------| | 3 | Queue Algorithm Modifier | **************| QErr | DQue | |-----|--------------------------------------------------------------| | 4 | EECA | **************************** | RAENP |UAAENP| EAENP | |-----|--------------------------------------------------------------| | 5 | RESERVED | |-----|--------------------------------------------------------------| | 6 | (MSB) | |-----| AEN HOLDOFF PERIOD | | 7 | (LSB) | |-----|--------------------------------------------------------------| Depending on the number of options, the fields marked with asterisks could be used to code options to include Clear ACA upon receipt of untagged command Use SCSI-2 status bytes only Use SCSI-2 messages only Ignore LUN field in command block ... Advantage: Can selectively resolve incompatibilities one at a time. Disadvantage: Requires targets to implement multiple operating modes. Requires targets to operate in multiple modes simultaneously to support multi-initiator systems. By posting this note before the Santa Fe meeting, I hope to increase the probability of reaching consensus on a recommendation for the plenary. If you have comments before the meeting, please send them. Thank you. Giles Frazier IBM AWS Austin Austin, Texas (512) 838-1802 gfrazier@ausvm6.vnet.ibm.com