X3T9.2/88-114 Thomas Wicklund Ciprico, Inc 2955 Xenium Lane Plymouth, MN 55441 612-559-2034 Comments on SCSI-2, Revision 5 document. NOTE: I haven't done a lot of work with the SCSI committee, so am not as familiar with the standard as others. Therefore, if some of these comments involve issues which have been argued extensively, please disregard them. I don't mean to re-open any old disputes. Many of the following are in the form of questions rather than suggestions. They are areas which I found unclear or feel should be expanded on but don't know what to add. I'm listing my comments in the order of the document rather than by importance. Sorry for not using the underscore / strikeout notation, but at present I can't easily generate text in that form. - The heading to section 10 is not consistent with the other sections. It reads "Command Descriptions for Printer Devices" and should read "Printer Devices". - Section ordering: Section 7 places Diagnostic pages (7.3) before mode parameters (7.5). Section 8 places mode parameters (8.3) before diagnostic pages (8.4). The ordering should be consistent throughout the document if possible. - Mode parameter section headings: The section headings for mode parameters are inconsistent (section 7.5, 8.3, 9.3, etc). Headings include "Mode parameter pages for ...", "Mode Parameters", "MODE SELECT/MODE SENSE Parameters", "Mode Page Parameters", and others. I suggest a consistent format. - Page 1-2: The standard starts out refering to "SCSI" and "SCSI-2". One page 1-2 it then begins to use "SCSI" to mean both standards. Later in the document (I don't remember the exact location), SCSI-2 is again used. This should be consistent, with one name chosen and used throughout. I suggest "SCSI-2" since this is the common name used in the industry. - Section 2: The term "AWG" is used in the document. Does this need to reference a standard for wire size, or is this considered a generic term? Do the various floppy standards referenced later need to be included here? Also tape standards, ESDI, SMD, and any others that might be mentioned? - Page 3-1: Definitions are needed for the following. I don't know the proper definition for some so can't provide a suggested wording: AWG? Initiator: I suggest a cleaner wording: "An SCSI device (usually a host system) which requests that an operation be performed by another SCSI device (a target)." Logical unit number: Should this read "An encoded three-bit or eleven-bit identifier for the logical unit"? Extended identify still exists. Alternately add "sub-logical unit number" and possibly "sub-logical unit". Queue or tagged queue: For queued commands. I'm not sure what's needed at present. T L nexus (used on page 6-17 in the ECA description). - Page 4-1: I'm uncomfortable with the terms "A Cable" and "B Cable" instead of "the A Cable" and "the B Cable" in much of the utext. It sounds like this section was written by a non-native speaker of English. - Page 4-3: The term "A Cable cable" reads rather poorly. Is there a better term? - Page 4-4, 4-5, high density cable drawings: The second line of each figure title should change from "(A Cable/B)" to "(A Cable / B Cable)". - Page 4-13, Table 4-6: The "+ACKB" line has a spurrious ")". - Wide data transfers, general comment: There is no defined way to detect that the B Cable is not connected. As presently written, lack of a B Cable is detected by lack of REQB / ACKB pulses during a data transfer. This seems a rather late time to detect a configuration problem. Does it make sense to add some sort of B cable detect during the selection sequence? I'm not sure what to use or how, but I see an implementation problem here. - Page 5-10, section 5.2.1: In the third paragraph, words should be added similar to below, assuming I'm reading the existing standard correctly: "The initiator shall assert the ATN signal before negating BSY during a selection phase." Also in the same paragraph, should something be said about what happens to the command which is executing? Does going to an unexpected BUS FREE abort the command or does the target try again? - Page 5-11, section 5.2.2: I can't find any way to detect that a target implements hard or soft reset. This looks like a problem if other initiators are to really continue operating. I think other all initiators and targets would have to be designed and chosen to implement soft RESET if continued operation after reset is to occur. If there is a way to detect which RESET is implemented, it should be documented in this section or an appendix. Reading through the description of soft RESET and things which must be done to allow for it, I wonder if it's worth the complexity which is added. - Page 5-12, Soft RESET, item 5: The initiator considers the I O process complete when it negates ACK. The target also uses the negation of ACK. If RESET occurs exactly as ACK is being negated, could the initiator consider the process complete but the target not? Is this a problem? - Page 5-16: There are no vendor unique messages (other than extended messages). Is this intentional? I don't have a need for vendor unique messages, am just pointing out their lack. - Page 5-18: ABORT TAG: It isn't clear when an ABORT TAG message is allowed. From the text, an initiator may raise ATN at any random time (including in the middle of a data transfer) and send an ABORT TAG message to cancel either the current command or a different command. Is this the intended behavior? - Page 5-19: BUS DEVICE RESET: Why should this message always be a hard RESET while the RESET signal may be hard or soft? It doesn't make sense. - Page 5-24, QUEUE TAG Messages: The reference to section 6.5.2 looks like it should be changed to 6.9.2 and the title changed appropriately. - Page 5-25, editor's note at the top: I suggest that the target be able to send any of the three queue tag messages on reconnect or that one of the three be picked as a RECONNECT QUEUE TAG message. It doesn't make sense to define a new message number, but also doesn't make sense to force the target to remember which type of queue tag message was used. - Page 6-2, UNIT ATTENTION and sense data: How does this interact with queued commands? Are there problems with stacking sense data or error recovery? I have some concern that the target has to stop whenever an error occurs until the initiator processes the error. - Page 6-15, section 6.6: The AEN data format table is not specified. Where is this located? - Page 6-16, Contingent Allegiance: Commands to other logical units are allowed with a Contingent Allegiance condition. Are there any cases of a COPY command executed with Disconnect not allowed which could hang the SCSI bus? - Page 6-16, Extended Contingent Allegiance: While it's nice to say that ECA doesn't need to be generated for every CHECK CONDITION status, in does need to be for every command which might possibly want to use ECA recovery. This is because ECA is generated before the initiator knows what the error was. Would it make sense to allow ECA to be generated after REQUEST SENSE data is returned (send the INITIATE RECOVERY message after GOOD status from REQUEST SENSE). I see some problems, such as normal Contingent Allegiance must be redefined to be in effect a bit longer during the REQUEST SENSE command, and I'm sure there's several conditions I haven't thought of (soft RESET being one which I'm sure would have to change). I'm not particularly advocating the above, but it seems wasteful to generate ECA every time a correctable ECC error occurs when you really want ECA for some other condition. - Page 6-17, ECA: The second to the last page states that "the T L nexus shall send an INITIATE RECOVERY message following the AEN data and prior to the COMMAND COMPLETE message." As written, this might be either before or after the status associated with the AEN data. Is this intended, or should it be modified to be more exact? I'm thinking of the many interpretations of the current SCSI standard which cause no end of trouble trying to anticipate just about anything happening at any time. - Page 7-1, Table 7-1: Remove the key at the bottom. Mandatory and Optional are not listed here. - Page 7-3, Table 7-3: The entry for value 00 is "Operating Definition". This doesn't make sense. Should the word "Default" be added back in? - Page 7-6, COPY command: It's never been clear to me how a third party copy is implemented. It looks like the copy manager issues read and write commands. An appendix describing this would be nice. If the copy command involves another SCSI device, should there be a note that the command must allow DISCONNECT? If it doesn't I don't think it's possible to execute the COPY command. The above also apply to COMPARE. - Page 7-17, Table 7-14: Why does byte 2 have two adjacent reserved fields? Should they be combined? - Page 7-21, Table 7-17: Code 5 should now state "CD-ROM device". - Page 7-23: The references to ASCII data and specification of code values 20h to 7Eh may cause problems with international standardization. Many foreign languages require additional character codes and refer to ISO character standards. Unfortunately, it's been 5 years since I was involved in this area and I'm not sure how it should be worded. If SCSI-2 is going for ISO approval some comments from other national standards groups might be appropriate. - Page 7-28, Log Select Page Control field: I can't find this in the Log Sense CDB or the Log Page descriptor. Where is it? - Page 7-28, order of Log Select pages and parameters: What does the target do if these aren't in order? CHECK CONDITION with what sense? - Page 7-31, table 7-23: Should the first two entries be "Current xxx Values"? It's implied but not stated. - Page 7-37, Mode Sense fields: The terms "parameter" and "field" seem to be used interchangably here. I suggest one or the other be chosen and used consistently. - Page 7-37, Changeable Values: This section first states that "Parameters that are changeable shall be set to one", then states "If any part of a field is changeable all bits in that field shall be set to one." Reading strictly, these conflict. A clearer paragraph might be: "A PC field value of 1h requests the target return the changeable values for the page code specified. The page requested shall be returned containing information that indicates which fields are changeable. All bits of fields that are changeable shall be set to one. All bits of fields that are target defined shall be set to zero." The last sentence about part of a field being changeable can be included if desired, but I don't think it's necessary. - Page 7-38, Changeable Values: The last paragraph of this section states that the target may not return bytes 0 and 1 of a page. Why not state instead: "If all parameters are target defined within a page, the target may nor may not return the page. If the target returns the page, the parameter length value shall be set to zero by the target." Note the following points: 1: The term "parameter length" should be used, not "page length". Parameter length is used in the page descriptors (table 7-34, end of section 7, etc). 2: A literal reading of the existing text allows returning all page bytes except the first two, obviously not intended. - Page 7-38, section 7.2.10.4: There's some text missing from the first paragraph (see 3rd and 4th lines). - Page 7-38, section 7.2.10.5, item (3): What is meant by "no current values have been created"? I would think that one returns saved values as soon as these are available, otherwise default values. - Page 7-48, Table 7-40: The second byte of this command has an undefined bit. I think it's reserved, the table should be fixed. - Diagnostic commands: In the interest of consistency and further obscure language, should be diagnostic commands be renamed to DIAGNOSTIC SELECT and DIAGNOSTIC SENSE? No, this isn't really a serious request. - Page 7-49: Why are RECEIVE DIAGNOSTIC RESULTS pages described here with the command while SEND DIAGNOSTIC pages are described in their own section (7.3). Both should either be with the command or separate. Also on this page, the table titles use the term "RECEIVE DIAGNOSTIC". They should read "RECEIVE DIAGNOSTIC RESULTS" since the latter is the correct command name. - Page 7-49, Supported Page List: Does page code 0 (supported page list) need to be returned in the list of supported pages? It's redundant, but section 7.3 does say "all pages". I anticipate some differring interpretations here. - Page 7-52, the reference to Table 7-21 should be 7-44. - Page 7-60, after table 7-49: What's the "registration authority" comment for? - Page 7-53, request sense information field: In table 7-44 this field is refered to as "information bytes". Should the text refer to "information bytes field" or alternately should the table say "information"? - Page 7-53, request sense information field, item (1): This item specifies unsigned logical block for device types 0, 4, and 5. Type 5 is now CD-ROM devices and should be stated as such. What is returned when MSF addressing is used? Also, add type 7, "Optical memory devices". - Page 7-61, table 7-50: I assume that this table will be turned into a more formal error list. I also assume that additional sense codes will be distributed between standardized, reserved, and vendor unique. I suggest that for each additional sense code, the additional sense code qualifiers be distributed between standardized, reserved, and vendor unique. As a suggestion, standardize additional sense code values of 00h through 7Fh (or perhaps BFh). Leave 80h (or C0h) through FFh as vendor unique. Use the same definition for additional sense code qualifiers. - Page 7-62, ASC 17/04: What does "CIRC" stand for? - Page 7-63, ASC 4E/00: Should this read "Untagged overlapped commands attempted"? - Pages 7-61 .. 7-64: Many of the generic errors (e.g. Command phase error) are not identified for Media Changer Devices. Shouldn't they be added? - Page 6-63, ASC 54/00: This looks like a generic catchall error. It should either be defined for all device types or marked as a historical anomalie with an alternate code specified. I think this comment applies to all ASC values starting with 50h. - Page 7-89, Vital Product Data: First, why is this at the end of the section? I don't think device type dependent VPD exists. Putting it with the Identify command makes it easier to find. This also applies to Log Parameter Pages, which only exist in section 7. Second, the Unit Serial Number page is defined as 80h in table 7-79 on this page. On page 7-94 it is given as 83h. This should be resolved. - Page 11-1, processor devices: Can't a processor device support MODE SELECT / MODE SENSE in order to specify parameters valid for all devices such as Disconnect / Reconnect Parameters, Peripheral Device Parameters, or Common Device-Type Control Parameters? Disconnect / Reconnect make sense if the Send or Receive command implementation does something with the data that's being transferred. Common Device-Type Control Parameters are needed to enable queuing to the processor device. There seems no reason to prohibit this. Therefore, make the following changes: 1. Add MODE SELECT and MODE SENSE to the list in figure 11-1 as optional commands. 2. Change section 11.3 to read: "There are no unique pages defined for processor devices." - Page A-2, SCSI signal sequence example: This example does not include an initial MESSAGE OUT phase. Since MESSAGE OUT is required by this version of the standard (see Figure 5-1, page 5-14) the MESSAGE OUT phase should be included. ************************************************************* - Page 5-22, Section 5.6.9, IGNORE WIDE RESIDUE: This message will be fairly common when transferring parameter fields (e.g. IDENTIFY command, MODE SENSE, etc. I doubt these fields are all multiples of 4 bytes. I wonder if it makes sense to allow omission of the IGNORE WIDE RESIDUE message if 0's pad these fields? Whether this message is required for a data out phase depends on whether the target always knows the length of the data transfer. If so, then it can be omitted and the final initiator bytes ignored. If not, it's required. If defined for a data out phase there is a timing problem -- it appears that ATN must be raised during the last transfer to tell the target that a residue is required, however this sounds difficult to implement, especially during synchronous transfers. Extended Identify: While extended identify is a nice idea in handling more than 8 logical units, it's incompletely implemented in the standard. I see the following areas which don't handle sub-logical unit numbers: - "nexus" notation. The sub logical unit number is implied to be included in the process portion of the identify, but this is ambiguous. - What should an ABORT message after IDENTIFY and before EXTENDED IDENTIFY do? Clear all processes for all sub logical units or just go to BUS FREE phase? - Can EXTENDED IDENTIFY be used with target processes to identify sub-processes? - Section 5.6.18 specifies that queue tag messages immediately follow the IDENTIFY message. This should read "IDENTIFY (or EXTENDED IDENTIFY if present)". I think that EXTENDED IDENTIFY needs to be either fully integrated into the standard or removed. Unfortunately, it seems to be necessary on the off chance that over 8 logical units exist but rarely implemented so has become an orphan feature. Tag Length Concerns: SCSI-2 uses tagged commands to execute multiple commands per logical unit. However, the tag messages only use an 8 bit tag. This limits a target to 256 simultaneous commands (assuming a typical single LUN device). The primary advantages of command queuing is offloading the host computer (by allowing it to send commands to the device immediately) and sorting / optimization by the device. Many systems, including fairly small UNIX systems, can generate far more than 256 commands. Peak loads of 300-400 commands are typical under UNIX System V when synchronizing the file system. Large systems can generate far more commands (the largest I've encountered so far is 50,000). Since system capacities continue to grow, I wonder if a 256 command limit soon become a problem. I'd prefer to see three byte tag messages with a 2 byte tag value. At the very least, this should be included in the SCSI-3 list as new messages, however, I think it might be better to look at this change in SCSI-2 rather than going to two forms of the tag commands. Required Identify Message: The standard currently requires a message out phase and identify message after selection and before command transfer. Since SCSI is moving toward embedded interfaces, most devices have one logical unit. The main reason for the initial message out phase is the Identify message. The most common Identify message will be to select logical unit 0 and select the disconnect option, which typically changes infrequently. Since most Identify messages are identical, does it make sense to require this message? Might it be better to select a disconnect mode in a manner similar to synchronous or wide transfer negotiation and only use identify for the exception case of non-logical unit 0 or target processes. My concern is the perception that SCSI has high overhead, which is higher by requiring an extra message or phase. A a specific proposal: 1. Specify that if the initiator does not send an identify message, the target shall use the disconnect setting of the last identify command received (or no disconnect if no identify has been received from that initiator). 2. If the identify message is not sent, logical unit 0 shall be used (overridden by the LUN field of the command for now, but unit 0 when the LUN field is removed). 3. The identify message and/or MESSAGE OUT phase may be omitted by the initiator at its choice with the above defaults. 4. The target may omit the identify message and/or MESSAGE OUT phase on reselect if the initiator did the same. The above is designed for single logical unit devices, which are becoming common. The MESSAGE OUT phase is still required if queuing commands.