Sense data contains result codes for all SCSI operations.
>Can somebody put in english what this information is, I would appreciate
>it.
>
>Thanks
>
>--
>==========================================
>Rocke Robertson
>PWGSC-GTIS-CPS
>Voice (613) 748-4604
>Fax (613) 748-4843
>mailto:Roc...@tiger.pwgsc.gc.ca
>==========================================
>
>
Here's my attempt:
Communication between a SCSI system and a SCSI peripheral works by using
SCSI commands. The end of each command indicates if the command was
successful or not. No indication of what went right or wrong is given. The
system may choose to ignore the failure, or go out and ask the peripheral
why the last command failed. The data containing the failure information is
called Sense data. This data is anywhere from 4 to 255 bytes in size. Three
of these bytes are most important:
1. Sense Key, indicates failure category, like 'device not ready' or 'media
error'
2. Additional Sense Code (ASC) -and-
3. Additional Sense Code Qualifier (ASCQ).
The ASC/ASCQ fields have details on what exactly was wrong.
Hope this helps,
Rob
Sense data is data returned on a 'Sense' data request, be that a 'Request Sense'
data request, 'Log Sense' data request or 'Mode Sense' data request.
A 'Request Sense' is usualy executed on receipt of a Check Condition and that usually
is indicative of an error. I believe Sense Data has a (minimum) length requirement of
18 bytes. My IBM drive always returns 32.
Here is the technical bit:
The Request Sense command requests that the Target transfer sense data to the Ini-
tiator.
Sense data is valid for a Check Condition status returned on the prior command and
for most unexpected bus free conditions. The sense data is preserved by the Target
for the Initiator until retrieved by the Request Sense command or until any other
command is received for the same LUN from the same Initiator that issued the
command resulting in the Check Condition status. In the case of the single Initiator
option, the Target assumes that the Request Sense command is from the same Initi-
ator.
If a Request Sense command is received and Unit Attention is active, the Drive
reports any pending sense data and preserves the Unit Attention Condition .
If there is no pending sense data for conditions other than a Unit Attention,
the sense data for the Unit Attention is returned and the Unit Attention condition
is cleared.
--
Folkert Rienstra
(Please don't email me, reply to the group)
visit Gary Field's SCSI Info Central at www.scsifaq.org
"Rob Turk" <rob....@gelrevision.nl> wrote in message news:8h5gk2$csr$1...@thor.wirehub.nl...
| "Rocke Robertson" <roc...@tiger.pwgsc.gc.ca> wrote in message
| news:3935E123...@tiger.pwgsc.gc.ca...
| > Can somebody put in english what this information is, I would appreciate
| > it.
| >
| > Thanks
|
| Here's my attempt:
|
| Communication between a SCSI system and a SCSI peripheral works by using
| SCSI commands. The end of each command indicates if the command was
| successful or not. No indication of what went right or wrong is given. The
| system may choose to ignore the failure, or go out and ask the peripheral
| why the last command failed. The data containing the failure information is
| called Sense data. This data is anywhere from 4 to 255 bytes in size. Three
| of these bytes are most important:
| 1. Sense Key, indicates failure category, like 'device not ready' or 'media error'
That is the 3rd byte (byte 2)
| 2. Additional Sense Code (ASC) -and-
That is the 13th byte (byte 12)
| 3. Additional Sense Code Qualifier (ASCQ).
That is the 14th byte (byte 13)
|
| The ASC/ASCQ fields have details on what exactly was wrong.
Well, 'exactly' is sometimes a whole category of possibilities.
|
| Hope this helps,
|
| Rob
|
|
|
No, you can't be sure that the lower layer does an auto-Request Sense. Best
is to assign a sense data area and fill it with zeroes before issueing a
call. If the command fails, check if the first byte is still zero. If the
lower layer does auto-sense, the first byte will be non-zero. If it's still
zero, do your own Request Sense.
Rob
Rob Turk <rob....@gelrevision.nl> wrote in message
news:8h8sh6$1p0h$1...@thor.wirehub.nl...