public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Luben Tuikov <luben@splentec.com>
To: tonyb@cybernetics.com
Cc: linux-scsi@vger.kernel.org
Subject: Re: ide-scsi command status bug
Date: Tue, 16 Jul 2002 21:04:25 -0400	[thread overview]
Message-ID: <3D34C299.982829BF@splentec.com> (raw)
In-Reply-To: 000301c226c0$ffcd0dc0$e0019d89@cybernetics.com

Tony Battersby wrote:
> 
> Hello,
> 
> I have tracked down a problem with incorrect status being returned for a
> command sent through sg and ide-scsi.  I am using vanilla 2.4.17.  Here is
> what is happening:
> 
> The device returns CHECK CONDITION for a command sent to it from sg and
> ide-scsi.
> The following line executes in idescsi_end_request() in ide-scsi.c:
> pc->scsi_cmd->result = (CHECK_CONDITION << 1) | (DID_OK << 16);
> ide-scsi calls the callback completion function.
> An internal request sense is queued.
> The request sense completes successfully.
> The following line executes in idescsi_end_request() in ide-scsi.c:
> pc->scsi_cmd->result = (DID_OK << 16)
> ide-scsi calls the callback completion function for the request sense
> command.
> 
> In my userspace program, sg_io_hdr_t { status, masked_status } are both
> zero, but sg_io_hdr_t { driver_status } & DRIVER_SENSE is set and the sense
> data is valid.  It appears to me as if the status from the request sense
> command overwrote the original CHECK CONDITION status.  I verified this by
> forcing all request sense commands to return a status of 0x01 (reserved bit
> set) in idescsi_end_request() in ide-scsi.c, and sure enough, I got a status
> of 0x01 for the failed command in sg_io_hdr_t { status }.

You are relying on specific Linux SCSI core behaviour
rather than the spec. SPC-2, 7.20.1, specifies that if REQUEST
SENSE completed successfully, i.e. the sense data is valid, then
status GOOD is returned. If the status is CHECK CONDITION
for a completed REQUEST SENSE command then the sense data may NOT
be valid.

Simply: if you issue REQUEST SENSE and the command completes and
returns valid sense data, then you should get GOOD status.

You should NOT filter REQUEST SENSE and set status to CHECK CONDITION!
 
> I have not tested any other kernel versions.  I am working around the
> problem for now by faking a CHECK CONDITION status when driver_status &
> DRIVER_SENSE in my program.

In userspace you can pretty much make up your own rules.

-- 
Luben

  parent reply	other threads:[~2002-07-17  1:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-08 20:49 ide-scsi command status bug Tony Battersby
2002-07-09  0:36 ` Douglas Gilbert
2002-07-17  1:04 ` Luben Tuikov [this message]
2002-07-17 13:33   ` Tony Battersby

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=3D34C299.982829BF@splentec.com \
    --to=luben@splentec.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tonyb@cybernetics.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox