Re: SG_IO problem on tape devices

[Kai Makisara <Kai.Makisara@kolumbus.fi>]

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