Proper handling of data underrun

Proper handling of data underrun

[Andreas Herrmann]

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 ...

    <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.

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?


Regards,

Andreas

Re: Proper handling of data underrun

[Douglas Gilbert]

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

Re: Proper handling of data underrun

[Andreas Herrmann]

Douglas Gilbert <dougg@torque.net> wrote:

>      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.

Ok.
BTW, resid is used in scsi_lib.c to set rq->data_len.
Who is actually evaluating this field -- the block layer 
(I have seen some usage in elevator.c)?

> 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.

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

Value is the same as the requested length.

> 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.

Yes I will give it a try.
Thanks.


Regards,

Andreas