SG_IO problem on tape devices

SG_IO problem on tape devices

[Arne Wiebalck]

Hi all,

I got a problem using the SG_IO ioctl with our tape drives. 
In order to examine errors on our drives in more detail, I 
would like to make the sense bytes available to the 
application using the REQUEST_SENSE command.

However, there's a discrepancy between the kernel output in
/var/log/messages and what I see using SG_IO within my 
application: while the kernel sees

kernel: st0: Error with sense data: scsi1 : destination target 0, lun 0
kernel:         command = Space 01 00 0d d5 00
kernel: Info fld=0x1, Current st0: sense key Medium Error
kernel: Additional sense: Read retries exhausted
kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x12 0x00 0x00
0x00 0x00 0x11 0x01 0x00 0x00 0x00 0x00 0x37 0xf7 0x10 0x01 0x00 0x00
0xf7 0x37

(which is realistic) the ioctl reports something like

70 00 00 00 00 00 00 12  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  10 02

(since the first bit is not set, the sense bytes are not even valid,
as far as I understand).

So, could it be that the sense bytes are already cleared when I request
them? They cleared/set by the next SCSI cmd, I assume? But shouldn't
they be valid even then?

I also tried the sg3-utils to query the drive's sense bytes, and they
report (almost) the same sense bytes as SG_IO inside my application
does. Sending an INQUIRY cmd using sg3_utils works fine, btw.

Maybe that's all a plain usage error, so please find the code I use
below.

Anything obvious I am doing wrong here? All comments appreciated. 

Cheers,
 Arne

P.s.: As I am not subscribed to the list, please CC your answer to me.

---------------------------------


#define REQUEST_SENSE_CMD 0x3
#define REQUEST_SENSE_ALLOC_LEN 0xfc  /* maximum alloc length */
#define REQUEST_SENSE_SENSEB_LEN 32
#define REQUEST_SENSE_CMDLEN 6

                unsigned char sense_b[REQUEST_SENSE_SENSEB_LEN];
                unsigned char dxfer_b[REQUEST_SENSE_ALLOC_LEN];
                unsigned char rsCmdBlk[] = {REQUEST_SENSE_CMD, 0, 0, 0,
REQUEST_SENSE_ALLOC_LEN, 0};
                struct sg_io_hdr io_hdr;

                memset(sense_b, 0, sizeof(sense_b));
                memset(dxfer_b, 0, sizeof(dxfer_b));
                memset(&io_hdr, 0, sizeof(struct sg_io_hdr));

                io_hdr.interface_id = 'S';

                io_hdr.cmdp = rsCmdBlk;
                io_hdr.cmd_len = REQUEST_SENSE_CMDLEN;
                io_hdr.timeout = 30000;

                io_hdr.sbp = sense_b;
                io_hdr.mx_sb_len = sizeof(sense_b);

                io_hdr.dxfer_direction = SG_DXFER_FROM_DEV;
                io_hdr.dxferp = (unsigned char*)dxfer_b;
                io_hdr.dxfer_len = REQUEST_SENSE_ALLOC_LEN;

                if (ioctl(tapefd, SG_IO, &io_hdr) < 0) {
                       /* handle error */
                } else {
                       /* examine sense bytes */                        
                }       
      
---------------------------- 

Re: SG_IO problem on tape devices

[Kai Makisara]

On Tue, 3 Jun 2008, Arne Wiebalck wrote:

> Hi all,
> 
> I got a problem using the SG_IO ioctl with our tape drives. 
> In order to examine errors on our drives in more detail, I 
> would like to make the sense bytes available to the 
> application using the REQUEST_SENSE command.
> 
> However, there's a discrepancy between the kernel output in
> /var/log/messages and what I see using SG_IO within my 
> application: while the kernel sees
> 
> kernel: st0: Error with sense data: scsi1 : destination target 0, lun 0
> kernel:         command = Space 01 00 0d d5 00
> kernel: Info fld=0x1, Current st0: sense key Medium Error
> kernel: Additional sense: Read retries exhausted
> kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x12 0x00 0x00
> 0x00 0x00 0x11 0x01 0x00 0x00 0x00 0x00 0x37 0xf7 0x10 0x01 0x00 0x00
> 0xf7 0x37
> 
> (which is realistic) the ioctl reports something like
> 
> 70 00 00 00 00 00 00 12  00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00  10 02
> 
> (since the first bit is not set, the sense bytes are not even valid,
> as far as I understand).
> 
> So, could it be that the sense bytes are already cleared when I request
> them? They cleared/set by the next SCSI cmd, I assume? But shouldn't
> they be valid even then?
> 
Yes, the standard says that the sense data after CHECK CONDITION shall be 
preserved until it is transferred and cleared after that. This means that, 
in this case, the st driver only sees the sense data. The subsequent 
REQUEST SENSE commands receive the NO SENSE key, which is what you get.

The st driver should return more error information that fits into struct 
mtget. The problem is what should be there? I don't have a clear idea what 
kind of definition would be general enough for the future but not too 
complicated. User input here is needed.

One of the ideas I have had has been to provide the sense data from the 
latest command that provided it. This would be easy to implement and could 
use a sysfs file. (But should this be a general SCSI feature and not a st 
feature?)

-- 
Kai

Re: SG_IO problem on tape devices

[Boaz Harrosh]

Kai Makisara wrote:
> On Tue, 3 Jun 2008, Arne Wiebalck wrote:
> 
>> Hi all,
>>
>> I got a problem using the SG_IO ioctl with our tape drives. 
>> In order to examine errors on our drives in more detail, I 
>> would like to make the sense bytes available to the 
>> application using the REQUEST_SENSE command.
>>
>> However, there's a discrepancy between the kernel output in
>> /var/log/messages and what I see using SG_IO within my 
>> application: while the kernel sees
>>
>> kernel: st0: Error with sense data: scsi1 : destination target 0, lun 0
>> kernel:         command = Space 01 00 0d d5 00
>> kernel: Info fld=0x1, Current st0: sense key Medium Error
>> kernel: Additional sense: Read retries exhausted
>> kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x12 0x00 0x00
>> 0x00 0x00 0x11 0x01 0x00 0x00 0x00 0x00 0x37 0xf7 0x10 0x01 0x00 0x00
>> 0xf7 0x37
>>
>> (which is realistic) the ioctl reports something like
>>
>> 70 00 00 00 00 00 00 12  00 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 00  10 02
>>
>> (since the first bit is not set, the sense bytes are not even valid,
>> as far as I understand).
>>
>> So, could it be that the sense bytes are already cleared when I request
>> them? They cleared/set by the next SCSI cmd, I assume? But shouldn't
>> they be valid even then?
>>
> Yes, the standard says that the sense data after CHECK CONDITION shall be 
> preserved until it is transferred and cleared after that. This means that, 
> in this case, the st driver only sees the sense data. The subsequent 
> REQUEST SENSE commands receive the NO SENSE key, which is what you get.
> 
> The st driver should return more error information that fits into struct 
> mtget. The problem is what should be there? I don't have a clear idea what 
> kind of definition would be general enough for the future but not too 
> complicated. User input here is needed.
> 
> One of the ideas I have had has been to provide the sense data from the 
> latest command that provided it. This would be easy to implement and could 
> use a sysfs file. (But should this be a general SCSI feature and not a st 
> feature?)
> 

You might want to look into using bsg ULD, if it is at all possible for you,
as it has a facility to return the actual sense information of the executed
command, into a user supplied buffer. But that means redoing st in user mode.

($0.017)
Boaz

Re: SG_IO problem on tape devices

[James Bottomley]

On Tue, 2008-06-03 at 09:59 +0200, Arne Wiebalck wrote: 
> Hi all,
> 
> I got a problem using the SG_IO ioctl with our tape drives. 
> In order to examine errors on our drives in more detail, I 
> would like to make the sense bytes available to the 
> application using the REQUEST_SENSE command.
> 
> However, there's a discrepancy between the kernel output in
> /var/log/messages and what I see using SG_IO within my 
> application: while the kernel sees
> 
> kernel: st0: Error with sense data: scsi1 : destination target 0, lun 0
> kernel:         command = Space 01 00 0d d5 00
> kernel: Info fld=0x1, Current st0: sense key Medium Error
> kernel: Additional sense: Read retries exhausted
> kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x12 0x00 0x00
> 0x00 0x00 0x11 0x01 0x00 0x00 0x00 0x00 0x37 0xf7 0x10 0x01 0x00 0x00
> 0xf7 0x37
> 
> (which is realistic) the ioctl reports something like
> 
> 70 00 00 00 00 00 00 12  00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00  10 02
> 
> (since the first bit is not set, the sense bytes are not even valid,
> as far as I understand).
> 
> So, could it be that the sense bytes are already cleared when I request
> them? They cleared/set by the next SCSI cmd, I assume? But shouldn't
> they be valid even then?
> 
> I also tried the sg3-utils to query the drive's sense bytes, and they
> report (almost) the same sense bytes as SG_IO inside my application
> does. Sending an INQUIRY cmd using sg3_utils works fine, btw.
> 
> Maybe that's all a plain usage error, so please find the code I use
> below.
> 
> Anything obvious I am doing wrong here? All comments appreciated. 

Yes: SCSI automatically requests sense in response to a check condition.
So, the sense should be attached to the SG_IO command that receives the
error.  You can't do an additional request sense for it because the
sense has already been cleared by the automatic request sense the
mid-layer did.

Does the sense data really not get returned by the SG_IO command that
actually encounters the check condition return?

James

Re: SG_IO problem on tape devices

[Douglas Gilbert]

James Bottomley wrote:
> On Tue, 2008-06-03 at 09:59 +0200, Arne Wiebalck wrote: 
>> Hi all,
>>
>> I got a problem using the SG_IO ioctl with our tape drives. 
>> In order to examine errors on our drives in more detail, I 
>> would like to make the sense bytes available to the 
>> application using the REQUEST_SENSE command.
>>
>> However, there's a discrepancy between the kernel output in
>> /var/log/messages and what I see using SG_IO within my 
>> application: while the kernel sees
>>
>> kernel: st0: Error with sense data: scsi1 : destination target 0, lun 0
>> kernel:         command = Space 01 00 0d d5 00
>> kernel: Info fld=0x1, Current st0: sense key Medium Error
>> kernel: Additional sense: Read retries exhausted
>> kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x12 0x00 0x00
>> 0x00 0x00 0x11 0x01 0x00 0x00 0x00 0x00 0x37 0xf7 0x10 0x01 0x00 0x00
>> 0xf7 0x37
>>
>> (which is realistic) the ioctl reports something like
>>
>> 70 00 00 00 00 00 00 12  00 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 00  10 02
>>
>> (since the first bit is not set, the sense bytes are not even valid,
>> as far as I understand).

That is a poor usage of the word "VALID" in the standard.
See: http://www.t10.org/ftp/t10/drafts/spc4/spc4r14.pdf
section 4.5.3 on "Fixed Format Sense Data".
The VALID bit (byte 0, bit 7) indicates whether there is
valid data in the information field (bytes 3 to 6 inclusive).

What the SG_IO ioctl is reporting is well-formed sense data
saying there is no error, and no additional sense qualifiers.

It has been cleaned out as James explained.

Doug Gilbert

>> So, could it be that the sense bytes are already cleared when I request
>> them? They cleared/set by the next SCSI cmd, I assume? But shouldn't
>> they be valid even then?
>>
>> I also tried the sg3-utils to query the drive's sense bytes, and they
>> report (almost) the same sense bytes as SG_IO inside my application
>> does. Sending an INQUIRY cmd using sg3_utils works fine, btw.
>>
>> Maybe that's all a plain usage error, so please find the code I use
>> below.
>>
>> Anything obvious I am doing wrong here? All comments appreciated. 
> 
> Yes: SCSI automatically requests sense in response to a check condition.
> So, the sense should be attached to the SG_IO command that receives the
> error.  You can't do an additional request sense for it because the
> sense has already been cleared by the automatic request sense the
> mid-layer did.
> 
> Does the sense data really not get returned by the SG_IO command that
> actually encounters the check condition return?
> 
> James

AW: SG_IO problem on tape devices

[Arne Wiebalck]

 
>On Tue, 2008-06-03 at 09:59 +0200, Arne Wiebalck wrote: 
>> Hi all,
>> 
>> I got a problem using the SG_IO ioctl with our tape drives. 
>> In order to examine errors on our drives in more detail, I 
>> would like to make the sense bytes available to the 
>> application using the REQUEST_SENSE command.
>> 
>> However, there's a discrepancy between the kernel output in
>> /var/log/messages and what I see using SG_IO within my 
>> application: while the kernel sees
>> 
>> kernel: st0: Error with sense data: scsi1 : destination target 0, lun 0
>> kernel:         command = Space 01 00 0d d5 00
>> kernel: Info fld=0x1, Current st0: sense key Medium Error
>> kernel: Additional sense: Read retries exhausted
>> kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x12 0x00 0x00
>> 0x00 0x00 0x11 0x01 0x00 0x00 0x00 0x00 0x37 0xf7 0x10 0x01 0x00 0x00
>> 0xf7 0x37
>> 
>> (which is realistic) the ioctl reports something like
>> 
>> 70 00 00 00 00 00 00 12  00 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 00  10 02
>> 
>> (since the first bit is not set, the sense bytes are not even valid,
>> as far as I understand).
>> 
>> So, could it be that the sense bytes are already cleared when I request
>> them? They cleared/set by the next SCSI cmd, I assume? But shouldn't
>> they be valid even then?
>> 
>> I also tried the sg3-utils to query the drive's sense bytes, and they
>> report (almost) the same sense bytes as SG_IO inside my application
>> does. Sending an INQUIRY cmd using sg3_utils works fine, btw.
>> 
>> Maybe that's all a plain usage error, so please find the code I use
>> below.
>> 
>> Anything obvious I am doing wrong here? All comments appreciated. 
>
> Yes: SCSI automatically requests sense in response to a check condition.
> So, the sense should be attached to the SG_IO command that receives the
> error.  You can't do an additional request sense for it because the
> sense has already been cleared by the automatic request sense the
>mid-layer did.
>
>Does the sense data really not get returned by the SG_IO command that
>actually encounters the check condition return?
>

Thanks for all the quick replies and helpful comments.

I will check what the SCSI command is that sees the error in the first
place, but it is most likely not an SG_IO command. I can't say immediately 
as I'm not the original author of the code, but since the code has been 
written years ago, I have my doubts.

As soon as I have identified the place in the code, I may come back to ask 
for advice on how to access the sense bytes in that specific case ... or 
how to change the code to make that possible at all :)

Since I won't be around for some days, 'coming back' may take some time.

Cheers,
 Arne   

 

Re: SG_IO problem on tape devices

[Arne Wiebalck]

On Tue, 2008-06-03 at 15:15 -0500, James Bottomley wrote:
> On Tue, 2008-06-03 at 09:59 +0200, Arne Wiebalck wrote: 
> > Hi all,
> > 
> > I got a problem using the SG_IO ioctl with our tape drives. 
> > In order to examine errors on our drives in more detail, I 
> > would like to make the sense bytes available to the 
> > application using the REQUEST_SENSE command.
> > 
> > However, there's a discrepancy between the kernel output in
> > /var/log/messages and what I see using SG_IO within my 
> > application: while the kernel sees
> > 
> > kernel: st0: Error with sense data: scsi1 : destination target 0, lun 0
> > kernel:         command = Space 01 00 0d d5 00
> > kernel: Info fld=0x1, Current st0: sense key Medium Error
> > kernel: Additional sense: Read retries exhausted
> > kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x12 0x00 0x00
> > 0x00 0x00 0x11 0x01 0x00 0x00 0x00 0x00 0x37 0xf7 0x10 0x01 0x00 0x00
> > 0xf7 0x37
> > 
> > (which is realistic) the ioctl reports something like
> > 
> > 70 00 00 00 00 00 00 12  00 00 00 00 00 00 00 00
> > 00 00 00 00 00 00 00 00  10 02
> > 
> > (since the first bit is not set, the sense bytes are not even valid,
> > as far as I understand).
> > 
> > So, could it be that the sense bytes are already cleared when I request
> > them? They cleared/set by the next SCSI cmd, I assume? But shouldn't
> > they be valid even then?
> > 
> > I also tried the sg3-utils to query the drive's sense bytes, and they
> > report (almost) the same sense bytes as SG_IO inside my application
> > does. Sending an INQUIRY cmd using sg3_utils works fine, btw.
> > 
> > Maybe that's all a plain usage error, so please find the code I use
> > below.
> > 
> > Anything obvious I am doing wrong here? All comments appreciated. 
> 
> Yes: SCSI automatically requests sense in response to a check condition.
> So, the sense should be attached to the SG_IO command that receives the
> error.  You can't do an additional request sense for it because the
> sense has already been cleared by the automatic request sense the
> mid-layer did.
> 
> Does the sense data really not get returned by the SG_IO command that
> actually encounters the check condition return?

The code does not use SG_IO interface until now. The command that
encounters the error is a read or a write. Is there a way to get the 
sense bytes in such a case (except for replacing all read/write calls
with the corresponding SG_IO commands)?

TIA,
 Arne