public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Andreas Herrmann <aherrman@de.ibm.com>
Cc: Linux SCSI <linux-scsi@vger.kernel.org>
Subject: Re: Proper handling of data underrun
Date: Fri, 08 Apr 2005 22:44:53 +1000	[thread overview]
Message-ID: <42567CC5.7090407@torque.net> (raw)
In-Reply-To: <20050408083702.GA6645@lion28.boeblingen.de.ibm.com>

Andreas Herrmann wrote:
> Hi,
> 
> Documentation/scsi/scsi_mid_low_api.txt says:
> 
>     resid        - an LLD should set this signed integer to the ...
> 
>     <snip>
> 
>     underflow    - LLD should place (DID_ERROR << 16) in 'result' if ...

     underflow    - LLD should place (DID_ERROR << 16) in 'result' if
                    actual number of bytes transferred is less than this
                    figure. Not many LLDs implement this check and some
                    that do just output an error message to the log
                    rather than report a DID_ERROR. Better for an LLD
                    to implement 'resid'.

Andreas,
The last sentence is were the stress should be. It implies
the LLD should use one or the other, preferably resid.

Historically 'underflow' has been there the longest but was
insufficient to distinguish between serious underflows
(e.g. on a READ of a block device) and informative underflows
(e.g. fetching a mode page with an arbitrarily large buffer).

So 'resid' was added later and conveys more information and
doesn't jump to conclusions that it is a serious error.
Perhaps 'underflow' should be marked as deprecated.

>     <snip>
> 
> ZFCP is setting resid and DID_ERROR if an underrun is indicated in the
> FCP-response.
> 
> In some error situations it occurs that the storage box reports a BUSY
> or TASK_SET_FULL scsi state as well as data underrun in the
> FCP-response.

Is any data conveyed or is the underflow value the same
as the requested length?

> Now zfcp sets DID_ERROR in host_byte as suggested in
> scsi_mid_low_api.txt. And the BUSY/TASK_SET_FULL state is returned in
> stauts_byte.
> 
> Problem is:
> Due to the its fastfail-operation the scsi-stack won't do any
> retry for this kind of failed commands because DID_ERROR is
> evaluated before BUSY/TASK_SET_FULL.
> 
> What is the proper handling of situations where the device reports a
> BUSY/TASK_SET_FULL and a data underrun?

See what happens if 'underflow' is ignored (i.e. not
written to be the LLD) and DID_ERROR is not set in
the host_byte.

Doug Gilbert

  reply	other threads:[~2005-04-08 12:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-08  8:37 Proper handling of data underrun Andreas Herrmann
2005-04-08 12:44 ` Douglas Gilbert [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-04-08 15:03 Andreas Herrmann

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=42567CC5.7090407@torque.net \
    --to=dougg@torque.net \
    --cc=aherrman@de.ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox