status as in SAM2

status as in SAM2

[Luben Tuikov]

Hello there.

Given SCpnt->result and that queuecommand() has
returned with error or done() was called,
how can I find out the status byte as per SAM2,
given SCpnt->result?

Is it just ``status_byte(SCpnt->result)''?
(macro defined in scsi.h)

TIA,
-- 
Luben

Re: status as in SAM2

[Douglas Gilbert]

Luben Tuikov wrote:
> 
> Hello there.
> 
> Given SCpnt->result and that queuecommand() has
> returned with error or done() was called,
> how can I find out the status byte as per SAM2,
> given SCpnt->result?
> 
> Is it just ``status_byte(SCpnt->result)''?
> (macro defined in scsi.h)

Luben,
The actual scsi status (bits as defined in SAM-2 and
elsewhere) is given by the expression:
   (0xff & SCpnt->result)

Traditionally linux has used a one bit shifted and masked
version of this called internally the "status_byte" which
is the macro you referred to:
   #define status_byte(result) (((result) >> 1) & 0x1f)

It masks "vendor" bits (in SCSI 2) which were bits 0, 6 
and 7. This is dangerous since SAM-2 now uses bit 6:
   0x40  ----> Task Aborted
and states all bit patterns other than those in Table 22
(Status codes) [SAM-2 draft T10/1157-D revision 23] are
reserved. I guess that stops vendors using bits 0 and
7. Has anyone every seen those bits used?


Perhaps it is time (in lk 2.5) to get rid of the current
status_byte macro "cleverness", change it to:
   #define status_byte(result) ((result) & 0xff) 
and change the "offset" defines for CHECK_CONDITION and
friends in include/scsi/scsi.h to their SAM-2 values.
Alternatively new defines could be introduced prefixed
with "SCSI_" for the standard values. The sg driver is
the only scsi interface that I'm aware of that exposes
the result of the status_byte() macro to the user space
and it could be set up not to surprise existing applications.


Doug Gilbert

Re: status as in SAM2

[Luben Tuikov]

Thanks Douglas,

I looked in the low-level scsi device drivers (LLDD)
and it seems to me that not all bother to set
the status byte right (even more so for emulated
scsi like the 3ware).

For compatibility I use something like this:

status = (uint8_t) ((status_byte(SCpnt->result) << 1) & 0xFF);

but I'd _much_ rather use the form you suggested:

status = SCpnt->result & 0xFF;

but am not sure if the position of the status byte
will change within the 32 bit result.

It would even be better if the device server status
byte has it's own byte variable in SCpnt, so that
LLDD writers feel ``encouraged'' to set it explicitly,
rather than the mid-level try and guess its value
using scsi_sense_valid(), and the driver byte...

> Perhaps it is time (in lk 2.5) to get rid of the current
> status_byte macro "cleverness", change it to:
>    #define status_byte(result) ((result) & 0xff)

I'm all for it!

Thanks,
-- 
Luben
P.S. A new breed of SCSI HBA heavily rely
on the device server status byte being reported right,
and I'm kind of set back to see that the LLDD don't
report it always... But I guess that depends on
the underlying hardware (device server)...