page 1 of 4 May 15, 1988 X3T9.2/88-057R0 To: X3T9.2 Committee (SCSI) From: James McGrath (Quantum) Subject: Handling Illegal Pages in the MODE SELECT/SENSE Commands An examination of how the standard handles other illegal bit and field values for the MODE SELECT/SENSE commands reveals the following: MODE SELECT PF - not checked (compatibility problems with SCSI-1/CCS). SP - returns a CHECK CONDITION status, sense key ILLEGAL REQUEST if saved pages are requested of, but are not supported by, the target. Parameter List Length - returns a CHECK CONDITION status, sense key ILLEGAL REQUEST if a descriptor, header, or page would be divided. Reserved Page code - no checking defined. [1] Not implemented Page Code - no checking defined. [2] Changes to non-changable parameters - returns CHECK CONDITION status. Changes to changable parameters that are outside the supported range - either returns CHECK CONDITION status or rounds the values. MODE SENSE DBD - no checking. PC - returns a CHECK CONDITION status, sense key ILLEGAL REQUEST if saved pages are requested of, but are not supported by, the target. Appears to imply that changable, current, and default pages must be supported by the target. Reserved Page Code - no checking defined. [3] Not implemented Page Code - returns either a CHECK CONDITION status, sense key ILLEGAL REQUEST, or returns a page length of zero. [4] Changable parameters requested when no parameters on the page are changable - returns either no data at all or a zero length page. [4] [5] Allocation Length - no checking. Thus in most cases the values are checked and a CHECK CONDITION status is returned if illegal values are detected. Resolving the undefined cases and changing some of the non-standard cass appears to be relatively simple: [1] & [2] - it would appear to make sense to return a CHECK CONDITION if an initiator attempted to change a page that either was reserved in the standard ([1]) or was defined by the standard, but not implemented by that target ([2]). [3] - if a page is reserved in the standard, then the initiator is never really justified in requesting it, so return a CHECK CONDITION status. page 2 of 4 [4] - this is the harder one. If a page is not implemented, then the initiator should discover this somehow, and a CHECK CONDITION appears the most reasonable. See the discussion on modifying mode parameters. [5] - the return of no data is totally inconsistent with everything. Once again, a CHECK CONDITION status should be returned. Modifying Mode Parameters The committee has debated (at length) the relative merits of loose vs tight coupling of mode page data alterations. The above discussion points out that both at a higher level of the command architecture (CDB fields) and a lower level (range of parameters supported), we have so far stuck to returning a CHECK CONDITION status on errors. In addition to this argument for a common architectural approach, returning a CHECK CONDITION status leads to a cleaner software implementation. Since the pages supported by the target can always be determined by requesting 3Fh as the page code of a MODE SENSE command, one justification for not returning a CHECK CONDITION status (that the initiator was essentially "polling" the target to see what pages are supported, and did not want to receive an error condition) is quite weak. In general, an initiator which would send down a series of parameters to pages that might not be implemented (even might not be defined by the standard!) and not want to be notified of errors really does not care if the parameters sent are obeyed by the target. While I am a target bigot, and dislike the initiator excessively instructing the target, if the initiator feels that it has better information than the target, then it should be interested to know if the target has accepted this information, or will totally ignore it. Requested Resolution While I favor making invalid parameter passing a grounds for returning a CHECK CONDITION status, the other approach can be defended. What cannot be defended is the standard supporting two incompatible techniques. While the market may currently demand that target manufacturers address both requirements, by setting a definitive standard the future products will be cleaner, and as time marches on the older, "non-standard" implementations will fade away. The longest journey begins with but a single step. page 3 of 4 The modifications listed below can be used to affect either system in a consistent manner. The committee should adopt one or the other. The issue should not be referred to the working group again, since it has already been discussed there twice. Both proposals have the following as a common element: Delete the fourth paragraph of section 7.1.8.2 (Changable Values), which currently reads as: If none of the parameters are changable within a page, the target may or may not return bytes 0 and 1 of the page. If the target returns these two bytes, the page length value shall be set to zero by the target. I. CHECK CONDITIONS on Errors Insert after the fifth paragraph of section 7.1.6 (MODE SELECT): If the initiator sends a page code that is reserved or not implemented by the target, then the command shall be terminated with a CHECK CONDITION status, the sense key set to ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD IN PARAMETER LIST [we might want to change this sense code]. Replace the following sentence in the fifth paragraph of section 7.1.8 (MODE SENSE): When the page code value requested is not supported by the target, the target may return the unimplemented page in the mode sense data with the page length set to zero. with: If the page code is reserved or not implemented by the target, then the command shall be terminated with a CHECK CONDITION status, the sense key set to ILLEGAL REQUEST, and the additional sense code set to INVALID FIELD IN PARAMETER LIST [we might want to change this sense code]. II. No CHECK CONDITIONS on Errors Insert after the fifth paragraph of section 7.1.6 (MODE SELECT): If the initiator sends a page code that is reserved or not implemented by the target, then that page of parameters shall be ignored by the target. page 4 of 4 Replace the following sentence in the fifth paragraph of section 7.1.8 (MODE SENSE): When the page code value requested is not supported by the target, the target may return the unimplemented page in the mode sense data with the page length set to zero. with: When the page code value requested is either reserved or not implemented by the target, then the target shall return that page in the mode sense data with the page length set to zero. Some outstanding issues of MODE SELECT/MODE SENSE that this proposal does not address (in the interest of getting a final quick resolution) are whether the default and changable values are optional or mandatory (and is optional, how to handle errors if they are requested anyway) and whether parameter values can change if a CHECK CONDITION status is returned (we have decided the answer is no for certain cases, but have not expended that to cover all cases).