SKSV bit requirements inadvertently changed between SPC-2 and SPC-3

Ralph Weber roweber at IEEE.org
Wed Sep 17 07:13:50 PDT 2008


Formatted message: <A HREF="r0809174_f.htm">HTML-formatted message</A>

Kevin,
Since this change was published in SPC-3, a proposal is going
to be needed to change it back. Any complaints about the reversal
will surly surface when CAP discusses said proposal.
All the best,
.Ralph
Kevin D Butt wrote:
>
> I believe that I have found an inadvertent change between SPC-2 and 
> SPC-3 that is still in SPC-4.  This came about in the addition of the 
> descriptor format of the sense data.	The change is related to the 
> SKSV bit when the sense key is ILLEGAL REQUEST.
>
> SPC-3 states:
> A sense-key specific valid (SKSV) bit set to one indicates the SENSE 
> KEY SPECIFIC field contains valid information as
> defined in this standard. An SKSV bit set to zero indicates that the 
> SENSE KEY SPECIFIC field is not as defined by this
> standard.
>
> SPC-3 states in 4.5.2.4.2 Field pointer sense key specific data that
> If the sense key is ILLEGAL REQUEST, then the SENSE KEY SPECIFIC field 
> shall be [as shown in the table].
>
> This brought in a SHALL that requires SKSV bit to be set to one and 
> the field pointer to be filled in.  In SPC-2 this was optional.
>
> The SPC-2 text reads:
> 7.20.3 Sense-key specific
> A sense-key specific valid (SKSV) bit of one indicates the SENSE-KEY 
> SPECIFIC field contains valid information as
> defined in this standard. The SKSV bit and SENSE-KEY SPECIFIC field 
> are optional. The definition of this field is determined
> by the value of the SENSE KEY field. This field is reserved for sense 
> keys not described below. An SKSV value
> of zero indicates that this field is not as defined by this standard.
>
> If the sense key is ILLEGAL REQUEST and the SKSV bit is set to one, 
> then the SENSE-KEY SPECIFIC field shall be as
> defined as shown in table 103. The FIELD POINTER field indicates which 
> parameters in the CDB or the data parameters
> are in error.
>
> It seems this came about because the descriptor format, by definition, 
> has the SKSV bit set to one.	I think it was not a conscience decision 
> to require this for the fixed format.
>
> Do you agree this was unintentional and what should be done about it now?
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-2869 / 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/ 



More information about the T10 mailing list