sense data for status GOOD

sense data for status GOOD

[Douglas Gilbert]

The folk at t10.org slipped this innocuous looking
addition into sam5r04 section 5.3.1 on status codes.

"Sense data may be delivered in the buffer defined by
the Sense Data argument of the Execute Command
procedure call (see 5.1) for any status code."

Previously sense data was only valid for status
CHECK_CONDITION [0x2] (and the obsolete
COMMAND_TERMINATED [0x22]). The quoted section in
the previous paragraph means that sense data could
arrive with any status code.

And now with draft sbc3r22 there is an example:
status=GOOD, sense_key=COMPLETED (recently added)
additional_sense_qualifier="INSPECT REFERRALS
SENSE DESCRIPTORS". Referrals are new and explained
in sbc3r22. IMO only a very small audience would
be interested in them. However it does indicate
a new trend.


So the question for the Linux scsi subsystem is
does it (or can it without many changes) convey
"non CHECK_CONDITION" sense data back up from
an initiator (LLD) to code that might care?

Doug Gilbert

Re: sense data for status GOOD

[Boaz Harrosh]

On 03/30/2010 07:01 PM, Douglas Gilbert wrote:
> The folk at t10.org slipped this innocuous looking
> addition into sam5r04 section 5.3.1 on status codes.
> 
> "Sense data may be delivered in the buffer defined by
> the Sense Data argument of the Execute Command
> procedure call (see 5.1) for any status code."
> 
> Previously sense data was only valid for status
> CHECK_CONDITION [0x2] (and the obsolete
> COMMAND_TERMINATED [0x22]). The quoted section in
> the previous paragraph means that sense data could
> arrive with any status code.
> 
> And now with draft sbc3r22 there is an example:
> status=GOOD, sense_key=COMPLETED (recently added)
> additional_sense_qualifier="INSPECT REFERRALS
> SENSE DESCRIPTORS". Referrals are new and explained
> in sbc3r22. IMO only a very small audience would
> be interested in them. However it does indicate
> a new trend.
> 
> 
> So the question for the Linux scsi subsystem is
> does it (or can it without many changes) convey
> "non CHECK_CONDITION" sense data back up from
> an initiator (LLD) to code that might care?
> 

scsi_cmnd->sense_buffer has an hard coded max_size and no associated
current_size member. the scsi-ml, given a CHECK_CONDITION, will
analyse the ->sense_buffer and determine it's size, then will copy
the content and set the size into request's sense members. All this
you already know.

Now what do you want to happen?
A. Only LLD knows when sense is available through host specific flags.
  In that case:
   I propose a new scsi_set_sense() that will just set the proper
   request members. It should be called only if != CHECK_CONDITION,
   since in that case it will just be over-written by the scsi-ml again.
   (Or not that can be changed as well).
   [This is a simple change, but needs LLD specific code every time]

B. The protocol defines when a sense is available, by status + cmnd
   combination, the sense is set by the target, the LLD has no special
   knowledge if sense is present or not. In this case scsi-ml can just
   inspect for these conditions and copy sense up the stack as before.

Next step is for some ULD, to actually inspect these fields.

> Doug Gilbert
> 

It does not look too complicated either way.

Boaz