Descriptor Sense question

[Gerry Houlder]

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1105104_f.htm">HTML-formatted message</a>

(1) Yes, the drive can respond in descriptor format for 02/04xx sense
combinations, according to the standard. Yes, the host will always know
whether the descriptor format is fixed or descriptor type based on the value
of the first bytes (e.g., 70h vs. 72h).
(2) and (3) Request Sense parameter data format is only determined by the
value of the DESC bit. Request Sense response is not affected by the D_SENSE
bit setting.
(4) If a drive is set into descriptor format mode by one host and another
host doesn't understand that format, the host that doesn't underatnd
descriptor format will not be able to correctly interpret the sense bytes
that are returned in the status packet of SAS commands (i.e., the autosense
bytes). A properly managed system shall not allow this situation.
I have some questions regarding the Descriptor Sense format.  In SPC4 (I’m
looking at rev 29),
>
>
> *4.5.1 Sense data introduction*
>
> *…*
>
> *The RESPONSE CODE field shall be set to 70h in all unit attention
> condition sense data in which:*
>
> *a) the ADDITIONAL SENSE CODE field is set to 29h; or*
>
> *b) the additional sense code is set to MODE PARAMETERS CHANGED.*
>
>
>
>
>
>
>
> I interpret this to mean that the various types of resets (POR, bus reset,
> etc.) as well as mode parameters changed should be in fixed format…
>
> Seems clear enough that sense bytes sent for subsequent host commands
> following these particular unit attentions may (or may not) be in
Descriptor
> Format, and the onus is on the host to understand that.
>
>
>
> 1.	   I was wondering if the drive (target) were coming ready (sending
> 02/04/01 K/C/Qs), say on a POR, may those sense bytes be sent with
> Descriptor format?
>
> During that time, the drive would not be honoring mode sense commands, so I
> was curious to know how the host would know…
>
> I suppose looking at the response code (70h vs 72h, for example)…?
>
>
>
>
>
> My second set of questions is regarding the request sense command itself…
> if the drive (target) were not SPC4 compliant, and thus did not support the
> D_SENSE bit in control mode page 0x0A, and thus did not support the DESC
bit
>
>
> In the request sense cdb, I see according to table 263 in section 6.29 that
> it will ignore the DESC bit and continue sending sense bytes in Fixed
> Format:
>
>
>
> Table 263 - DESC bit
>
> …
>
> Note: Device servers that are compliant with SPC-3 are capable of ignoring
> a DESC bit that is set to one.
>
>
>
>
>
> So this makes sense to me I think… if the D_SENSE bit in mode page 0x0A is
> 0 (CLEAR), and a request sense command with DESC bit is 1 (SET)… then the
> SPC-3 compliant drive will return sense bytes in fixed format… and the host
> will have to honor that, I assume.
>
>
>
> 2.	   Now if the drive were SPC-4 compliant, but the D_SENSE bit in
> mode page 0x0A is 0 (CLEAR), but the request sense command’s DESC bit is
> 1(SET)… what does that mean?	Does the request sense command’s DESC bit
take
> precedence over the D_SENSE bit in the mode page?
>
> 3.	   Next, what about the other configuration… if the D_SENSE bit in
> mode page 0x0A is 1 (SET), and a request sense command’s DESC bit is 0
> (CLEAR)… again, does the command’s DESC bit take precedence?
>
>
>
>
>
> 4.	   What about cases where some hosts are SPC-4 compliant, and others
> are SPC-3 compliant… If the SPC-4 compliant host were to set the D_SENSE
> bit, and expect sense bytes in Descriptor Format… then the SPC-3 host I
> assume would not be able to speak with the drive?
>
>
>
>
>
>
>
>
>
> Thanks in advance.
>
>
>
>
>
>
>
> -Rajiv Madabhushi
>
> Pliant Technology
>
> (408 321-0320, x108
>