All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Arne Wiebalck <arne.wiebalck@cern.ch>, linux-scsi@vger.kernel.org
Subject: Re: SG_IO problem on tape devices
Date: Tue, 03 Jun 2008 22:06:20 -0400	[thread overview]
Message-ID: <4845F89C.7000505@torque.net> (raw)
In-Reply-To: <1212524159.3329.18.camel@localhost.localdomain>

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

  reply	other threads:[~2008-06-04  2:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-03  7:59 SG_IO problem on tape devices Arne Wiebalck
2008-06-03 16:52 ` Kai Makisara
2008-06-03 17:37   ` Boaz Harrosh
2008-06-03 20:15 ` James Bottomley
2008-06-04  2:06   ` Douglas Gilbert [this message]
2008-06-04 16:46   ` AW: " Arne Wiebalck
2008-06-30  8:43   ` Arne Wiebalck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4845F89C.7000505@torque.net \
    --to=dougg@torque.net \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=arne.wiebalck@cern.ch \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.