Re: requeuing a Scsi_Cmnd?

[Luben Tuikov <tluben@rogers.com>]

Jeff Garzik wrote:
> 
> Suppose I am passed several Scsi_Cmnd structures via ->queuecommand. TCQ 
> depth is >1.  An event causes the entire queue to be aborted, but I know 
> that the majority of the queue was actually ok.

If the event was generated by the application client/SCSI Core,
then the normal logic applies -- either cancel all commands,
or cancel those which were not completed and finish those
which were.  I personally prefer the first option (unconditionally
cancel all commands on abort/clear task set) since this is what
the the spec says.

If the event was generated by other means, i.e. NOT by
the application client/SCSI Core, you can error out the
unfinished commands and return ok for the finished ones
(i.e. finish them).

>  So, my LLD would need 
> to requeue and resend most of the recently-aborted Scsi_Cmnds.
> 
> How do I tell the SCSI layer to requeue and resend a Scsi_Cmnd [almost] 
> immediately?

Return BUSY for the task(s) or TASK SET FULL for the task(s), which
you want to be requeued almost immediately.  There's a difference
between those two status codes as to their meaning, as per the spec.

In 2.4, if you return BUSY, the command is tried almost immediately,
and if you return TASK SET FULL, it is also tried but things
get too convoluted... so you're better off with BUSY.

In 2.5, BUSY and TASK SET FULL are treated the same, so you can
either go by the spec and return whichever makes sense, or
just return BUSY and you'll be fine for 2.4 and 2.5.

On a side note: remember that, as far as SCSI Transports
are concerned, after a task is cancelled (initiator sends
ABORT TASK to the TARGET) successfully, the target should
NOT send any status/response for that task, as the initiator
is NOT expecting ANY responses for a cancelled task
(across a transport, i.e. ``below'' a LLDD).

-- 
Luben