Accredited Standards Committee X3, Information Processing Systems Doc. No.: X3T9.2/ Date: Project: Ref. Doc.: X3T9.2/92-245 Reply to: Mr. Del Shoemaker Digital Equipment Corp. 3020 Hamaker Ct. Suite 501 Fairfax, VA 22031 Ph: (703) 207-6359 Fx: (703) 207-6356 Mr. Randell Jesup Commodore Business Machines (Engineering Dept). Address unknown Subject: Response to Public Review Comment on BSR X3.***, X3T9.2/90-186 draft CAM standard. Dear Mr. Jesup: Thank you for your interest in the draft CAM standard, BSR X3.***, X3T9.2/90-186. Your comments to the draft are sincerely appreciated, and due to your input, it has been decided to rework parts of the draft CAM standard. Your comments dealing with section 10 of the CAM document can not be answered at this time. Due to recently recognized implementation problems with section 10, (target mode). Section 10 of the draft CAM standard will be reworked to eliminate the implementation problems. The comments dealing with other sections of the CAM are answered on the attachment. Please send a written statement to the X3 Secretariat (Attn: Lynn Barra) within fifteen days saying whether you accept or reject this response. If you do not respond within fifteen days, the Secretariat will assume that you have withdrawn the comment. Sincerely, Del Shoemaker, Chair X3T9 cc: Lynn Barra, X3 Secretariat John Lohmeyer, X3T9.2 Chair Feb 2 12:13 1993 Page 2 Attachment: Due to the number of question posed, the format of the responses are your exact questions followed by the CAM working group's answers. Question: There is no definition of XPT_NOP. Answer: This was an oversight and will be corrected when the document is updated. Question: How "timely" must the SIM timeout mechanism be? Is +.99.. seconds allowed? Are +1.x seconds, or +10 seconds, or any arbitrary (but finite) time after the specified time allowed? If they aren't allowed, that may be a problem, as most OS timer mechanisms don't guarantee any specific time other than longer than you asked for (because of task priorities, etc). Also, on some systems there may be a requirement to function before the system is totally initialized, and at that time timing facilities/interrupts may not be available (I'm told at least on UN*X variant has this problem). Answer: The timeouts are a safety net for the drivers. The granularity is measured in seconds and the SIM must be allowed to clean up after a command timeout is detected. While the time allowed for the SIM is not specified, the SIM must be timely in its actions. When a timeout is detected, the actions that a SIM takes to resolve the timeout are up to the SIM, for the particular bus/target/lun. There are numerous issues presented to a SIM when a timeout is detected. Some of problems that a SIM takes into consideration are tags, has the command completed while timeout detected, has the target negotiated synchronous data transfers, etc. Due to number of different states a target/lun can be in when a timeout is detected it is impossible for the CAM standard to specify a time or actions that a SIM must adhere to. For the problem of a system not having a timer mechanism when it is booting, it is an operating system specific issue. This can not be addressed in the CAM standard. Systems that are not fully initialized still have mechanisms available to a SIM which it can use to determine periods of time. Feb 2 12:13 1993 Page 3 Question: When aborting a timed-out request, how can this be safely done in all instances? Exactly what action should the SIM take? Some cases are easy (IO not started yet), some may be hard or take a while (data transfer in progress that can't be interrupted), and some may be impossible, perhaps (what if the target is disconnected - must/can you hold the CCB until it reconnects so you can send an Abort? What if it never reconnects? Answer: The timeout value is from selection time for this CCB not when the SIM has received it. If the target is still making progress with the command (data transfer in progress and target/lun has gone to status phase/command complete) it is up to the SIM to determine what action to take. It can drive attention to get the target to notice and the target must go to MESSAGE OUT (SCSI-2 5.2.1) then the initiator can send an ABORT message. The SIM could also cancel the ABORT since the target has gone to status phase command complete. If the target is disconnected, the initiator can select the target and send an ABORT message. Question: In 6.6, paragraph 5, the spec states that a driver can change it's events mask by another call using the same callback value. What about the pdrv_buf and buffer length? I've been told that those are supposed to be updated as well. This needs to be reflected in the spec. Answer: This was an oversight and will be corrected when the document is updated. Question: In a number of places, the CAM spec says "shall return a non-zero CAM Status". Shouldn't that say that is "shall return a CAM Status of other than Request in Progress", or "shall return a non-zero CAM Status (status other than Request in Progress)"? Using "zero" requires that the reader already have read the CAM status table, which occurs later in the chapter, to understand the meaning. I understand that this may be being revised, so by the time this is answered, the question may be moot. Answer: This was an oversight and will be corrected when the document is updated. Feb 2 12:13 1993 Page 4 Question: In 6.3.2, it states that Callback on Completion is for Execute SCSI CCB's. I think it also applies to CCB's passed to the SIM via Enable Lun. Answer: The callback on completion, on Enable Lun CCB's passes the CCB value as a reference. The CCB is not returned. Enable Lun with 0 CCB's returns the CCB's. The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: A number of XPT/SIM commands list CAM statuses to be returned. Are other statuses allowed? I assume so, since none of them mention Invalid Path ID. Answer: Yes, any status can be returned, if the status applies. Question: There is a CAM status of LUN Already Enabled. Does this mean that an Enable LUN for an already-enabled LUN _must_ be returned with that error? Note that 10.1 (Enable Lun) mentions a number of errors, but they do not include that one. Also, nowhere in 10.1, 10.2, or 10.3 does it say that an Enable LUN of an already-enabled LUN is invalid. For example, it could be used to add more CCB's to the list of CCB's for the LUN. If it is to be disallowed, it should be so stated. If it is allowed, does it replace the previous set of CCB's, or is it added to them? (Replace seems more correct to me.) Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: 10.1 (Enable LUN) mentions a CAM status of Invalid Request as being returned if "there is currently a nexus established with an initiator that shall be terminated first". I assume that would only happen on an Enable LUN for an already-enabled LUN. In that case, what should happen to the other CCB's already queued for the LUN? Feb 2 12:13 1993 Page 5 Answer: More context is needed from you. The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: It's very unclear in the spec as to whether processor mode target operation supports only the 4 commands mentioned in 10.3, or whether those are an example, or whether the SIM is required to support those but not all others. Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: Typo: 10.3.2, 7th paragraph, starts like this: "If an Inquiry CDB is and there..." Answer: The typo will be corrected. It should read like this: "If an Inquiry CDB is received and there is an ...." Feb 2 12:13 1993 Page 6 Question: If the only way to change or add CCB's to a enabled LUN is to Enable LUN with number of CCB's = 0, and then Enable LUN again to add the new set, then doesn't this open a hole where the LUN could be selected and it will return that the lun is invalid? If you are able to add/change CCB's to an Enabled LUN, this is not a problem (see question 8). Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: In a few places it is stated that 0xff is the path ID of the XPT itself. I'm told that any CCB's for path 0xff other than Path Inquiry should be rejected with Invalid Path ID. Is this correct? If so, should a note to this effect be included in the text? Answer: Yes, Invalid Path ID should be returned. The CAM document will be updated to reflect this. Question: Is there a reason that Set Device Type doesn't allow setting more than the first byte of the inquiry data? If a device exists, and Set Device Type is called for that path/id/lun, what data should be returned as inquiry data? What if it doesn't exist? In 7.x (OSD Operation), for DOS only the first byte must be retained. What about other OS's? Doesn't this limit of 1 byte of data conflict with 8.2.1 (Get Device Type), which states that 36 bytes of inquiry data will be copied? Answer: The one byte field for Set Device Type/Get Device type allows the conservation of memory. If a device exists, then if more information is needed by the drivers, then it is their responsibility to issue an INQUIRY. We believe you mean Get Device Type for your second sentence. To determine if one byte or 36 bytes of inquiry data is stored, the Path Inquiry command should be issued ( 8.2.2). If the storage area for the inquiry data is 36 bytes, you are required to return all valid data stored for the inquiry, and NULLs after that. Ie. stored inquiry data returned from the device is 20 bytes, return 20 valid bytes and 16 NULL's. If the device does not exist, status will be Feb 2 12:13 1993 Page 7 SCSI Device Not installed. The 1 byte limit does not conflict with 8.2.1. The 36 bytes will only be copied if there is a valid buffer pointer. The Get Device Type returns CAM_REQ_CMP if only there is a device of that type in the path specified. Question: In Execute SCSI IO, how is residual length calculated? Is it requested - actual, or actual - requested? The text never makes it clear. (I understand that this is a known problem.) Answer It is requested - actual, the updated CAM document will be specific. Question: CAM Flags in all commands are listed as OSD. However, they are fully defined in table 9.2, implying that they are not OS-dependant. Answer: They are not operating system dependent, and the specification will be changed to reflect this. Question: In Execute SCSI IO (9.1), VU Field and VU Flags are shown, and listed as being defined in the vendor specification. Which vendor is this? OS, XPT, SIM, driver? Perhaps it means OSD, not vendor? Or is it reserved to the SIM? Answer: The VU Field and VU Flags are for the SIM vendor. Question: Can Message Buffer Pointer/Length in a SCSI IO request (table 9-1) be ignored in processor target mode? Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Feb 2 12:13 1993 Page 8 Question: I'm told that an XPT is required to pass all CCB's to the SIM. Is this correct (I think so), and if so where is it said? If it must pass them, are there any actions it must perform (such as setting status to CAM_REQ_CMP) before it is passed? Any after sim_action() returns? What is the status if a request is handled by XPT successfully, but the SIM has an error in handling it? Must it be passed to the SIM if the XPT has some sort of failure in handling it (can't allocate memory, for example)? Must it pass all CCB's it gets, even if it's an unknown type and not a vendor-unique? Answer: Yes, the XPT is required to pass all defined CCB's to a SIM if path is valid, unless directed to the XPT (5.2.1 and 6.1). If the function code is not supported, the XPT can post a CCB status of Invalid Request, and return the CCB. The XPT is a transport/router and must not change the CCB's. It is the responsibility of the SIM for all status of CCB's received. When the CCB is sent from a driver the status is Request in Progress as it is passed to the XPT and will remain so until the SIM has acted upon it and is ready with completion status. Relevant sections are: 3.1, 3.3, 4.1.2, 4.1.15, 5.2.1, 6.1, 7.1, 7.1.6.1, 7.2.3 If the SIM has an error handling the request, then there is an correct status that should be applied by the SIM. For all valid paths the XPT should not have a failure passing the CCB to a SIM. It should not be allocating memory because it should not have and reference to a passed CCB. For unknown types the CCB status should be Request Invalid, all others are passed, unless directed to the XPT (PATH INQUIRY). Question: Exactly what is meant by "validating" processor-mode target CCB's at Enable LUN time? 10.3 states that any invalid request shall be returned and the LUN not enabled. Does this mean that valid requests _aren't_ returned, but the LUN is still not enabled? Must this validation occur before or after replying the Enable LUN? Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Feb 2 12:13 1993 Page 9 Question: Request Sense is listed as one of the commands to be supported in 10.3. Doesn't this cause a problem, in that sense info is supposed to be maintained on an I_T_x basis (at least)? Or perhaps this is meant to be the sense data returned for the lun for all initiators when not I_T_x sense data exists? If so, is the SIM required to maintain a separate I_T_x-based list of sense data, if any, for sense data generated inside the SIM, and use the CCB-list request-sense data if it has no sense data for that initiator? Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: There's an assumption in the processor-mode target description that CCB's that have had their callback called are to be automatically reused by setting CCB_Available to 1, without calling xpt_action (or anything else). Is my reading of this assumption correct? Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: If an Enable LUN with number of CCB's of 0 is sent, can the SIM release any stored I_T_x sense data? Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: In 10.3, shouldn't Test Unit Ready be added to the list of "normal" processor mode commands, since it's mandatory for all devices? Answer: The processor mode (target mode) section of the specification has Feb 2 12:13 1993 Page 10 implementation problems and will be reworked in the next update of the document. Question: Should 10.3 mention that unless commands {x,y,z...} are supported, the device will not be a SCSI-2 compliant device? (Test Unit Ready, Request Sense, Inquiry, etc). Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: What the SIM can or should or must do on data overrun/underrun is unclear. Perhaps it must be unclear, or OSD, but this issue should be mentioned. Certainly some of the cases should NOT generate errors (underrun on DATA_IN). Some of them are arguable. For one I've been told that the only solution is a hard Reset(!) (overrun on DATA_OUT). I have serious problems with generating hard resets when other activity, including in disconnected devices may be occuring. My preferred solution would be to transfer garbage data and assert ATN, until I get a message out, and then send an Abort or Abort Tag message. Neither is good, I think this one is less bad. This should only come up (I hope) due to a driver bug, a target bug, or maybe a flakey bus (maybe). Answer: On data overrun/underrun it is up to the SIM vendor to decide what to do. Proper status must be placed into the CCB. Question: If one is using target processor-mode to implement a processor device using Send and Receive (so you can communicate with an initiator that doesn't do target mode), how can you accept the Receive and disconnect it until you have data for the initiator that sent it? Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Feb 2 12:13 1993 Page 11 Question: There's no way to tag a Recieve command in processor mode as being for a specific initiator - it's first-come, first-served. Doesn't this pose a problem in using processor mode to talk to more than 1 initiator? Basically, the driver is giving data to a random initiator, making it very hard to implement a more-than-2 node VLAN (which is a 'goal' of SCSI-2 processor mode devices). Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: In processor mode, is there any way to find out which initiator executed the command that caused the CCB to be replied? I don't see anything about this in the spec (10.3) Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: When a target processor-mode CCB has been replied by the SIM, and before the driver sets CCB Available again, may the driver change the CDB for the CCB? I assume it can't be changed while it's marked as available, or can it? Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: 10.3 states that CCB's shall be examined at Enable LUN time for (among other things) "valid data pointers". A) What does this mean? B) what if the driver changes data pointers/lengths while the CCB is not available? Feb 2 12:13 1993 Page 12 Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document. Question: In processor mode, when a Receive command is executed, how should mismatches in the data size be handled? What about for Send? Answer: The processor mode (target mode) section of the specification has implementation problems and will be reworked in the next update of the document.