AutoSense Data in SPI-4

ebrown at ebrown at
Tue Sep 4 06:04:19 PDT 2001

* From the T10 Reflector (t10 at, posted by:
* ebrown at
I would appreciate a clarification on the autosense feature of the SPI
status information unit

The following is from section 14.3.5 SPI status information unit of

The SENSE DATA field contains the information specified by the SCSI Primary
Commands-2 standard for presentation by the REQUEST SENSE command. The
proper sense data shall be presented when a SCSI status byte of CHECK
CONDITION is presented as specified by the
SCSI Primary Commands-2 standard.

Does the word 'shall'  indicate this is a requirement for the target

On the other hand we have the following from SAM-2. Autosense

Autosense is the automatic return of sense data to the application client
coincident with the completion of a SCSI command under the conditions
described below. The return of sense data in this way is equivalent to an
explicit command from the application client requesting sense data
immediately after being notified that an ACA condition
has occurred. Inclusion of autosense support in a SCSI protocol standard is

As specified in clause 5, the application client may request autosense
service for any SCSI command. If supported by the protocol and logical unit
and requested by the application client, the device server shall only
return sense data in this manner coincident with the completion of a
command with a status of CHECK CONDITION. After autosense data is sent, the
sense data and the CA (NACA equals zero), if any, shall then be cleared.
Autosense shall not affect ACA (NACA equals one), see 5.8.1.

Protocol standards that support autosense shall require an autosense
implementation to:
a) Notify the logical unit when autosense data has been requested for a
command; and
b) Inform the application client when autosense data has been returned upon
command completion (see clause 5).

It is not an error for the application client to request the automatic
return of sense data when autosense is not supported by the SCSI protocol
or logical unit implementation. If the application client requested the
return of sense data through the autosense facility and the protocol
service layer does not support this feature, then the confirmation returned
by the initiator's service delivery port should indicate that no sense data
was returned. If the protocol service layer supports autosense but the
logical unit does not, then the target should indicate that no sense data
was returned. In either case, sense information shall be preserved and the
application client may issue a command to retrieve it.

Note the requirement 'a' which states that autosense is only required when
requested from the application client.  If we are not requesting it, then
it should not be required (and not presented).

What happens when the application client does not request the autosense but
it is presented?  One suggestion is that the software driver remember the
sense data and wait for the client to issue a Request Sense.  However, the
implementation of autosense has cleared the CA condition and the target is
now free to start all the tagged commands in the task set.  It is quite
probable that these commands may also return sense data. It seems therefore
that the driver must have the capability of remembering the sense data for
all commands.  When does it throw them away?  The target knows to throw
away the results when the next command occurs but the driver cannot proceed
with the same algorithm.

There are many older device drivers and applications that can not be
modified to meet new specifications.  They continue to operate under the
SCSI-2 model for Contingent Allegiance and the use of Request Sense.  In
general the SCSI Request Blocks (SRB) of most operating systems have a
field which indicates if the caller has supplied a sense buffer.  For these
SRBs the autosense works.  However, the software driver should have the
ability to indicate that autosense is disabled on a SRB basis.  The disable
would be set when the sense data buffer is not provided.

I understand that I may have missed some critical discussion about this
topic and therefore would appreciate any references regarding this topic.

Ed Brown
Senior Systems Engineer

ATTO Technology, Inc.
155 Crosspoint Parkway
Amherst,  NY  14068
(716) 691-1999 ext 141

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list