From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luben Tuikov Subject: Re: requeuing a Scsi_Cmnd? Date: Mon, 12 May 2003 01:43:48 -0400 Sender: linux-scsi-owner@vger.kernel.org Message-ID: <3EBF3494.6090100@rogers.com> References: <3EBEB1D5.3040300@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from fep02-mail.bloor.is.net.cable.rogers.com ([66.185.86.72]:22413 "EHLO fep02-mail.bloor.is.net.cable.rogers.com") by vger.kernel.org with ESMTP id S261928AbTELFbM (ORCPT ); Mon, 12 May 2003 01:31:12 -0400 In-Reply-To: <3EBEB1D5.3040300@pobox.com> List-Id: linux-scsi@vger.kernel.org To: Jeff Garzik Cc: linux-scsi@vger.kernel.org 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