From: Jeff Garzik <jgarzik@pobox.com>
To: Luben Tuikov <tluben@rogers.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: requeuing a Scsi_Cmnd?
Date: Mon, 12 May 2003 20:20:57 -0400 [thread overview]
Message-ID: <3EC03A69.1060302@pobox.com> (raw)
In-Reply-To: <3EBFE408.4010607@rogers.com>
Luben Tuikov wrote:
> James Bottomley wrote:
>
>> On Sun, 2003-05-11 at 15:25, Jeff Garzik wrote:
>>
>>> This question applies to 2.4 as well as 2.5 (I believe the strategies
>>> are different for the two?)
>>>
>>> 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. So, my LLD
>>> would need to requeue and resend most of the recently-aborted
>>> Scsi_Cmnds.
>>
>>
>>
>> You keep finding these unhandled condidions, sigh. The correct thing to
>> do (since this is a situation identical to QErr set) is to return a
>> check condition to the failing command and to return a status of TASK
>> ABORTED for all the others (SPC3). Of course, the SCSI-2 behaviour was
>> just to expect all tasks to be silently aborted on QErr=1. Neither of
>> these, of course, is coded into the mid-layer.
>
>
> Iff TAS is set and if TST is 001, and there is more than one initiator
> whose task are being nuked, then this is correct.
>
> Jeff didn't give much information, but it sounds like ABORT/CLEAR TASK SET.
> Anyway, no point in speculating.
I'm working on a SCSI low-level driver that drives SATA host
controllers. For ATAPI, it's mainly a passthru. The headache comes in
the translation of SCSI->ATA, and in the error handling. The SCSI->ATA
translator can be effectively considered a SCSI simulator (or at least
that's how I look at it), so like iSCSI I'm creating a software target,
and I want my target to be compliant to spec. (Which spec, you ask?
Well, initially SCSI-2, but long term James has convinced me SCSI-3)
So for my specific example, I'm passed a bunch of Scsi_Cmnds. I queue
them. And then according to spec, an error on the active command will
cause the entire queue to abort. Clearly, I do not want to error-out
the other probably-valid commands, only the specific one that caused the
error. So, the remaining ones need to be retried.
Jeff
next prev parent reply other threads:[~2003-05-13 0:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-11 20:25 requeuing a Scsi_Cmnd? Jeff Garzik
2003-05-12 5:43 ` Luben Tuikov
2003-05-12 14:44 ` James Bottomley
2003-05-12 18:12 ` Luben Tuikov
2003-05-12 20:30 ` James Bottomley
2003-05-13 0:20 ` Jeff Garzik [this message]
2003-10-30 23:48 ` Andre Hedrick
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=3EC03A69.1060302@pobox.com \
--to=jgarzik@pobox.com \
--cc=James.Bottomley@steeleye.com \
--cc=linux-scsi@vger.kernel.org \
--cc=tluben@rogers.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.