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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
