Request Sense Handling of Deferred Errors

Penokie, George George.Penokie at lsi.com
Tue Apr 12 13:26:46 PDT 2011


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

Ralph is correct. The list does not include deferred errors, therefore, if
these was a deferred error then the parameter data would containing sense
data with the sense key set to NO SENSE and the additional sense code set to
NO ADDITIONAL SENSE INFORMATION as defined in step 6. No amount of weasel
wording is going to get around that.
It's also clear that under no case will a deferred error cause a CC on a
REQUEST SENSE command.
If you don't like it the way it is then bring in a proposal to add deferred
errors into the list on page 373 and to add it that deferred errors will now
be cleared without reporting a CC.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
Sent: Tuesday, April 12, 2011 2:10 PM
To: t10 at t10.org
Subject: Re: Request Sense Handling of Deferred Errors
Okay! We have clarified the situation regarding the original message,
to whit the following statement is not strictly correct: "In the event
that the device server detects a deferred error condition, and then
subsequently receives a Request Sense command, should the deferred
error cause a Check Condition status to be returned for the Request
Sense command?" The presence of a deferred error is not sufficient to
cause the REQUEST SENSE command to receive a CHECK CONDITION status.
The new question (i.e., should the REQUEST SENSE command be affected
by the presence of deferred error sense data?) is more challenging.
If the answer is yes, then the ordered list at the top of page 373
(see SPC-4 r30) needs to reflect this, probably via the addition of
an new entry.
Right or wrong, this is a normative change and cannot be made without
a T10 vote.
Those favoring the addition might take solace in the fact that the
current 4) entry in the list specifically mentions a recovered error
(detected during the processing of the REQUEST SENSE command). I
suspect that some experts would see this as a description of one
particular instance of a deferred error, which necessarily leads
to the question of why this specific case is special.
Let's see how many SCSI gnomes this notion brings out of the
electronic woodwork.
All the best,
.Ralph
On 4/12/2011 1:12 PM, Richard Deglin - SISA wrote:
Nevertheless, the description of REQUEST SENSE does NOT include deferred
errors in the list of returnable sense data. SPC4r30, page 373. This is a
"shall" clause and I interpret it as meaning that REQUEST SENSE shall not
return deferred error sense data because it is not explicitly listed. Of
course, it is always possible that the different sections regarding sense
data in SPC are in conflict or are ambiguous, and T10 perhaps needs to
consider this and resolve the issues.
Rich Deglin
Senior Firmware Engineer, SAS SSD
Samsung Information Systems America
Office	 408 544 5816
Cell	  408 410 6584
________________________________
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Knight, Frederick
Sent: Tuesday, April 12, 2011 6:10 AM
To: Truong Nguyen - SISA; t10 at t10.org<mailto:t10 at t10.org>
Subject: RE: Request Sense Handling of Deferred Errors
NO.   This can be confusing, as there are 2 places where sense data is
returned.  One, is the autosense data that is associated with a command.  The
second is the data buffer that is returned in response to the REQUEST SENSE
command.
>From the definition:
3.1.158 sense data: Data describing an error or exceptional condition that a
device server delivers to an application
client in the same I_T_L_Q nexus transaction (see 3.1.67) as the status or as
parameter data in response to
a REQUEST SENSE command (see 6.29). The format of sense data is defined in
4.5.
The RED text is the first (autosense), the GREEN text is the second
(parameter data buffer) - notice the "OR" between the two types of sense
data.
So, when there is a deferred error, and a REQUEST SENSE command is received,
the parameter data buffer that is returned will contain sense data that
describes the deferred error.  The autosense data associated with the REQUEST
SENSE command will be associated with the GOOD status returned for the
command itself.
Basically, a successful REQUEST SENSE command returns GOOD status (with no
autosense data); AND it returns a parameter data buffer that happens to
contain data that is in the format of sense data that describes the event
(deferred error in your example).
If the REQUEST SENSE command has a problem (an invalid field in the CDB for
example), then the command will return an error status with autosense data
that describes the problem with the command (INVALID FIELD IN CDB).  In this
case, there is NO parameter data buffer to be returned, since the command
failed.  This is what 6.29 describes.
		Fred Knight
From: Truong Nguyen - SISA [mailto:tru.nguyen at sisa.samsung.com]
Sent: Monday, April 11, 2011 11:33 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: Request Sense Handling of Deferred Errors
The Request Sense command definition in subclause 6.29 SPC4r30 states that
the "device server shall return Check Condition status for a Request Sense
command only to report exception conditions specific to the Request Sense
command itself".
Deferred errors may be indicated by returning Check Condition status as
defined in subclause 4.5.5 in SPC4r30.
In the event that the device server detects a deferred error condition, and
then subsequently receives a Request Sense command, should the deferred error
cause a Check Condition status to be returned for the Request Sense command?
It would seem not, but some clarification would be appreciated.
Thanks,
Truong Nguyen
Samsung Information Systems America



More information about the T10 mailing list