Date: September 6, 1990 To: X3T9.2 Membership From: Lawrence J. Lamers, X3T9.2 Secretary John B. Lohmeyer, X3T9.2 Chairman Subject: September 4-5, 1990 X3T9.2 Working Group Meeting John Lohmeyer called the meeting to order at 1:00 p.m., Tuesday, September 4, 1990. He thanked Roger Cummings of Storage Technology for hosting and arranging the meeting. As is customary, the people attending introduced themselves. A copy of the of the X3T9.2 membership list was circulated for attendance and corrections. Copies of the draft agenda and the recent document register were made available to those attending. Information on X3T9.2 and Mailing Subscription Forms were made available. The final agenda was as follows: 1. Caching Proposal (90-021R2) [Milligan] 2. Diagnostic Command Set (90-103R1) [Pickford] {Wednesday a.m.} 3. Packetized SCSI (89-130R1, 90-132) [Stephens] 4. Multi-ported SCSI (89-133R2) [Stephens] Extensions for dual port SCSI (90-136R0) [Houlder] 5. 16/32-bit cable issues (90-48R3) [Penokie] (90-127) [Chan] 6. Reduced Common-Mode Range on Differential SCSI (90-092) [Jessen] 7. SCSI-2 Request for Interpretation #3 re: Exceptions during logging operations (90-111R1, -120R1) [Penokie] 8. SCSI Message Exception Handling (90-128) [Cornaby] 9. Additional SCSI Functions Resulting From a CHECK CONDITION (90-125) [Milligan] 10. Proposal for Messages and Commands Supported Lists [Milligan] (90-126) 11. Message Handling during reconnection [Houlder] 12. Outbound DISCONNECT Message interaction with TTD (90-133) [Lohmeyer] The following people attended the meeting: Name Status Organization ------------------------------ ------ ------------------------------ Mr. Gary W. Arakaki A Advanced Micro Devices Mr. Charles Brill P AMP, Inc. Mr. Ed Young P Archive Corp. Mr. Peter M. Blackford P Astro Cable Company Mr. Wills Xu O C&M Corp. Mr. Raul Ugalde Moncivais O Centro de Invest. Condumex Mr. Jose Manuel Villasenor O Condutel Mr. Stephen R. Cornaby P Conner Peripherals Mr. Chuck Micalizzi A Emulex Corp. Mr. I. Dal Allan P ENDL Mr. Robert Liu P Fujitsu America, Inc. Mr. Kenneth Post P Future Domain Mr. Kurt Chan P Hewlett Packard Co. Mr. Mike Peper A Hewlett Packard Co. Mr. Howard Wang O Hitachi Mr. George Penokie P IBM Corp. Mr. Gary R. Stephens A IBM Corp. Mr. David A. Buesing O IBM Corp. Mr. Lawrence J. Lamers P Maxtor Corp. Mr. John Lohmeyer P NCR Corp. Mr. David Steele S NCR Corp. Mr. Gerald Houlder A Seagate Technology Mr. Paul E. Orland V Solbourne Computer, Inc. Mr. Robert L. Simpson P Sony Corp. of America Mr. D. W. Spence P Texas Instruments Mr. Edward R. Schurig O Texas Instruments Mr. Peter Dougherty P UNISYS Mr. Doug Pickford A Western Digital 28 People Present Status Key: P Principal A Alternate O Observer S Special Interest (frequent visitor) V Visitor The following new documents were distributed at the meeting: Document Doc Date Author Description of Document ------------- -------- --------------- --------------------------------------- X3T9.2/89-133 8/30/90 G. Stephens Logical Model for SCSI-3 (Multiple Rev 2 porting) X3T9.2/90-48 5/9/90 G. Penokie 16/32 bit P/Q and L cable stand alone Rev 4 document X3T9.2/90-120 7/25/90 G. Penokie Draft response to Request for Rev 1 Interpretation #3 on SCSI-2 X3T9.2/90-123 8/31/90 B. Spence Single-Ended Cable Best Case Analysis Rev 1 X3T9.2/90-127 8/16/90 K. Chan 16-bit Connector Retention and 32-bit Physical Layer Thoughts X3T9.2/90-128 7/17/90 S. Cornaby Illegal message handshaking X3T9.2/90-132 8/30/90 G. Stephens SCSI-3 Additions for Packetization/Serial Interface X3T9.2/90-133 9/5/90 J. Lohmeyer SCSI-3 Modifications to Outbound Rev 1 DISCONNECT Message X3T9.2/90-134 8/24/90 J. Fiala Rough draft of cable test parameters, procedures, and philosophies X3T9.2/90-135 9/4/90 B. Spence "November" Working Group Announcement X3T9.2/90-136 8/31/90 G. Houlder Extensions for dual port SCSI RESULTS OF MEETING 1. Caching Proposal (90-021R2) [Milligan] Gene Milligan was unable to attend due to a meeting conflict. He had previously said he did not want to update this proposal until the proposal on supported messages was addressed (90-126). No action was taken on the caching proposal. 2. Diagnostic Command Set (90-103R1) [Pickford] {Wednesday a.m.} Doug presented his latest revision incorporating the changes suggested at the last working group. There was an in-depth discussion on off-track seeking. Doug agreed to add a Diagnostic Seek command, using a modulo 256 field for movement off-track. The document is structured well; there were no negative technical comments. John Lohmeyer pointed out that the document needs some non-technical editing, especially in the model. Doug agreed to provide an RTF file so that Larry Lamers can convert it for availability on the SCSI BBS. Doug noted that he would be out of the country for about 6 weeks, so he will not be available for feedback and will not be able to attend the next plenary meeting. He may not be present for the Austin Working Group either. People wishing to reach Doug regarding his proposal may do so via his secretary. 3. Packetized SCSI (89-130R1, 90-132) [Stephens] Gary Stephens brought copies of 90-132, which is a replacement for 89-130. This document contains sections 0 through 6 with both parallel and serial/packetized protocols. Gary noted that he had spent some effort in making the notation consistent and incorporating previous suggestions from the working group. Gary objected to the current strategy of dividing SCSI-3 into multiple documents. He cited difficulties in using IPI, especially in keeping references between documents consistent. The editors responded that no method is good for a 600+ page document. They expected the advantages of splitting it into multiple documents to outweigh the disadvantages. Dal objected to packetizing the parallel interface. Since the parallel interface is relatively short, the benefit of packetizing is minimal. He argued that the packetized protocol should focus on serial SCSI with the objective of working on the Fiber Channel interface. Members of X3T9.2 were encouraged to study 90-132 for a more thorough discussion at the "November" working group meeting. 4. Multi-ported SCSI (89-133R2) [Stephens] Extensions for dual port SCSI (90-136R0) [Houlder] Gary Stephens gave an overview of the changes made in revision 2 of 89-133. Terminology has been changed to reflect working group inputs. The "host" is now the "initiating controller". The contents of this document are also included in 90-132. Gerry Houlder gave an overview of 90-136, which provides for simpler dual- ported targets. An I/O process completes entirely on the same port -- no new mechanism is added to identify I/O processes across ports as in 89-133. Dal Allan argued that multi-port is too complex for SCSI applications that are simply moving up from older device interfaces such as SMD. He argued that multi-porting should be bundled with serial/packetizing and not defined for parallel SCSI. Part of the basis for this direction is the upper limits on system size with parallel cables. It was suggested that 90-132 be used as the basis for a SCSI-3 Serial Physical Level document with no parallel information. This would be an alternative to the SCSI-3 Physical Level project which will document the parallel interface. An item was added to the next plenary meeting agenda to discuss whether and how the split should be made. Dal Allan accepted an action item to develop a project proposal for a SCSI-3 Serial Physical Layer interface. John Lohmeyer requested that Dal use 90-105R1 as a base document since it includes the sections required in the latest SD-3. The group then focused on reviewing Gerry Houlder's document, which identified several issues. The first issue was whether the reset condition (RST signal) affects one or both ports. Gerry preferred that it only affect the port on which the reset condition occurs. This implies that the target must maintain separate mode parameters, operating conditions, and sync/wide agreements for each port. It also implies that the reset condition is not handled the same as a power- on reset. George Penokie objected. His design treats the reset condition identically to a power-on reset and cannot preserve the other port's state. The solution was to allow both implementations. Dual-ported devices that are incapable of preserving the other port's state will report unit attention condition using the same ASC as for power-on reset. There was some discussion about whether a bit in the INQUIRY data should be defined to report which implementation is present. No requirement was established. The BUS DEVICE RESET message will only affect the port on which it is received. A BUS DEVICE RESET OTHER PORT message will be defined to reset the other port (only). An ASC will be added to indicate that the device was reset by the other port. Note: If it is necessary to reset both ports, issue a BUS DEVICE RESET OTHER PORT message followed by a BUS DEVICE RESET message. The CLEAR QUEUE message will only affect the one port on which it is received. A CLEAR QUEUE OTHER PORT message will be defined to clear the queue on the other port (only). Gary Stephens pointed out that it will be necessary to define the effect of every message in a dual-ported environment. A bit will be defined in the INQUIRY data to indicate whether the device is dual-ported. The group could not establish a reason to identify which port is which in the INQUIRY data. Dual-ported devices will need to provide at least one set of mode parameters for each port. Device reservations will affect both ports. A unit reservation on one port will cause RESERVATION CONFLICT status to be reported on the other port. Devices may be designed so that they must occupy the same SCSI ID on both ports or they may have different SCSI IDs. Dual-ported devices must contain sufficient hardware logic to respond properly to protocol on both ports. If it is active on one port, it must still respond correctly to protocol on the other port. Gerry planned to revise his document to reflect the working group input. 5. 16/32-bit cable issues (90-48R4) [Penokie] (90-127) [Chan] George Penokie presented the revision 4 additions to his document that incorporate rules for parity checking during SELECTION phase. The group suggested that the rules also should apply to RESELECTION phase with a slight variation as there is no single-initiator option for RESELECTION phase. A revision 5 document will be included in the mailing including the RESELECTION change and will include the entire 90-48 document, not just the change pages. David Steele questioned whether 32 devices are really viable since each device is presently allowed 2 mA of leakage current which would exceed the 48 mA driver current specification at VOL. Dal noted that Jean Kodama raised this issue ages ago and it still has not been addressed. Obviously, the driver current specification and/or receiver leakage current specification must change. Testing is also needed to determine the transmission line effects. 6. Reduced Common-Mode Range on Differential SCSI (90-092) [Jessen] Chuck Micalizzi announced that a low-power differential SCSI working group meeting will be held September 26, 1990 at: Sheraton Inn 4545 MacArthur Blvd. Newport Beach, CA (714) 833-0570 The meeting is scheduled to start at 9:00 a.m. Chuck requested RSVPs at (714) 662-5600 x3166 by September 17. 7. SCSI-2 Request for Interpretation #3 re: Exceptions during logging operations (90-111R1, -120R1) [Penokie] George Penokie explained the changes in revision 1 of his 90-120 document. He said that the document mostly repeats information found in SCSI-2, but some information is interpolated/extrapolated from the document. John Lohmeyer said that if information is interpolated or extrapolated, then the response should be treated as a "Class C" response under the X3 rules. He accepted an action item to investigate Technical Information Bulletins prior to the October meeting. 8. SCSI Message Exception Handling (90-128) [Cornaby] Steve Cornaby said that message-by-message exception handling that leads to significant overhead. Normal sequences, especially the queue tag messages, should be post-processed to improve on-bus performance. He proposed that certain easily-decoded messages be permitted to be post-processed (after disconnection). In particular, Steve wanted all two-byte messages (message code 2Xh) to be post processed. Dal Allan pointed out that Steve could do this without changing the standard. If an exception occurs, recover by sending CHECK CONDITION status. This error handling may not be fully compliant, but it would be difficult to detect and would not "break" the initiator. Steve's proposal would require initiator changes to benefit from the new protocol. Dal also pointed out that Steve's problem is likely to be solved by new protocol chips before SCSI-3 is approved. He objected to "short-term" solutions being put into the standard. Larry Lamers said that the NEXUS IN/OUT phases proposed by Gary Stephens are a more complete solution than Steve's proposal. NEXUS IN/OUT permits all messages to be post-processed. Steve countered that going to NEXUS IN/OUT is too big a change. The discussion ended with Steve saying he would discuss the working group suggestions with his colleagues before deciding whether to pursue the issue further. 9. Additional SCSI Functions Resulting From a CHECK CONDITION (90-125) [Milligan] This proposal was discussed in Gene Milligan's absence at Gerry Houlder's request. The topic also was added to the plenary agenda. There was some support for the idea of adding a Disable All Queuing (DAQ) bit to the Control Mode Page, but there was significant resistance to including the Automatic Reservation on Check Condition (ARC) bit. ARC provides an alternate way of doing extended contingent allegiance with other initiators receiving RESERVATION CONFLICT status instead of BUSY status. The condition is ended via a RELEASE command instead of a RELEASE RECOVERY message. There did not seem to be any justification for adding redundant protocol. 10. Proposal for Messages and Commands Supported Lists [Milligan] (90-126) Due to the short meeting time and Gene Milligan's absence this proposal was not discussed. It was placed on the agenda for the next plenary meeting. 11. Message Handling during reconnection [Houlder] Gerry Houlder decided to not pursue this topic. The condition is more academic than practical. 12. Outbound DISCONNECT Message interaction with TTD (90-133) [Lohmeyer] John Lohmeyer presented his document which redefines the behavior of the outbound DISCONNECT message for I/O processes that have previously transferred a TTD message. John had accepted an action item at the last plenary meeting to prepare this proposal as an adjunct to his 90-62R4 proposal, which was accepted. There is no change in the outbound DISCONNECT protocol for I/O processes that have not transferred a TTD message. For I/O processes that have transferred a TTD message, the outbound DISCONNECT now would cause the target to remain disconnected until the initiator reconnects using a CONTINUE I/O PROCESS message. Two wording improvements were suggested and John prepared revision 1 of his document during the discussion. There was a lengthy discussion of the effects of a TTD message with George Penokie suggesting that a TTD message should cause the target to dedicate itself to the initiator. Dal questioned how George could read this into John's document. He asked George to provide a wording change that would make it clear that this is not the case. TTD should only affect bus reconnections for the I/O process and not imply an effect on any other I/O process. Gary Stephens joined into the fray and it gradually became clear that the problem was an architecture vs. implementation issue. Targets that do not have segmented buffers and multi-tasking may need to dedicate themselves to the TTD I/O process. (Or they can let the initiators manage the buffer resource via reservations, etc.) Targets that do have segmented-buffer facilities should not be precluded by the architecture from doing additional work while part of their buffer is dedicated to the TTD I/O process. The conclusion was that no change is needed in 90-62R4. It permits George's implementation without requiring George's implementation. Multi-tasking implementations are also permitted.