Re: requeuing a Scsi_Cmnd?

[James Bottomley <James.Bottomley@steeleye.com>]

On Mon, 2003-05-12 at 13:12, Luben Tuikov wrote:
> Uuuuh... Shouldn't this be fixed?

Not really, its design behaviour.  BUSY or QUEUE_FULL return means the
actual device couldn't accept the command, so we push back on the block
queue and suspend until a returning I/O frees the queue.  DID_BUS_BUSY
indicates transient failures in the host side which are eligible for
immediate requeueing

> The problem with this is that on BUSY, the LLDD _may_ get the task
> which got this condition out of order...  Furthermore, there's no

This would be why we don't support barriers.

> such thing as BUS BUSY anymore, it's an SPI left over.  In case
> where the transport is unavailable, a service response of
> SERVICE DELIVERY OR TARGET FAILURE should be returned*.
> Currently SCSI Core has no facility to return a ``service response''.

The service response are what the DID_ attributes are about.  At the end
of the day, though, the mid layer will either 

1. Fail the command
2. retry immediately, or
3. retry after another command returns.

That's what the large set of case statements in
scsi_error.c:scsi_decide_disposition() is about.

James