[202] in linux-scsi channel archive
Re: SCSI Reset Functions.
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Tue May 23 11:24:28 1995
From: "Eric Youngdale" <eric@aib.com>
Date: Tue, 23 May 1995 10:16:58 -0400
In-Reply-To: "Leonard N. Zubkoff" <lnz@dandelion.com>
"SCSI Reset Functions." (May 22, 11:15pm)
To: "Leonard N. Zubkoff" <lnz@dandelion.com>
Cc: linux-scsi@vger.rutgers.edu, drew@boulder.openware.com
On May 22, 11:15pm, Leonard N. Zubkoff wrote:
> Subject: SCSI Reset Functions.
> From: "Eric Youngdale" <eric@aib.com>
> Date: Mon, 22 May 1995 10:27:45 -0400
>
> For the moment, I've changed my current implementation to try a Bus Device
> Reset, and if there are two Bus Device Resets without a successful SCSI
> command, then the next one causes a full Host Adapter and SCSI Bus Reset.
I
> think this is a reasonable way to go until the higher levels implement
multiple
> forms of reset.
Yes, the bus device reset is known to work with at least some
controllers, so this much should be safe.
> I did some testing of this last night and found 3 commands per lun led to
the
> best performance, which makes me highly suspicious that there is a problem
with
> what the card is being asked to do. It just doesn't make sense that such
a
> small queue would be optimal. I need to look at the precise commands
being
> requested and see what's happening.
No, 3 seems reasonable to me. The basic idea is that you have two
commands tagged together, you avoid a cycle of bus arbitration, and the
second command can start executing much sooner than it would have if tagged
queueing were not enabled.
The reason that the DPT driver does better with 64 CMD/LUN is that
it apparently does command re-ordering with it's own elevator algorithm in
order to improve performance. If your board does not do this, then you
gain nothing by raising CMD/LUN above 2 or 3.
Michael is quite correct in that setting CMD/LUN this high will
lock out tape drives - the solution is quite simple, but I am temporarily
down as my laptop hard drive is dying, and I am waiting for the replacement
to arrive.
> I think I've now figured out part of my confusion. I took the following
from
> scsi.h:
>[...]
> to mean that I was responsible for restarting all the outstanding commands
at
> the driver level (i.e. sending them to the card again without informing
the
> high level). From examining other drivers like the NCR 53c810 one, I
found
> that most drivers set the result to DID_RESET and then called the
completion
> routine. It hit me today that perhaps that was the meaning of "restarting
all
> the commands". In retrospect, this makes sense as the higher levels need
to
> reset timeouts etc., but it wasn't apparent when I first read this.
You have to remember that these were written from the perspective
of the mid-level code. These messages are received from the low-level
driver, and it is in effect a way for the low level driver to tell the
mid-level code what to expect.
To me "automatically restarting" means that the board itself
remembers the commands and automatically restarts them. In principle,
your driver could do the same thing, provided that the board itself does
not do this as well.
> This is sort of what some of the SCSI_RESET_* options are for.
For
> example, SCSI_RESET_SUCCESS indicates that all of the outstanding
commands
> for the bus have automatically been restarted, so that we do not need to
> do anything. SCSI_RESET_PENDING indicates that the outstanding commands
> have not been restarted, and the mid level code should restart all
commands
> that were on the bus. Even then, I think the meaning of the various
> options needs to be spelled out a bit more so that each one has a very
> precise meaning.
>
> So what does "automatically been restarted" mean here? Is my conclusion
above
> correct, that setting DID_RESET and calling the completion routine is the
way
> one restarts them? I think this much of my confusion comes from what the
> higher levels will do with a given DID_XXXXX result code.
Here "automatically restarted" means that the mid level code does
not need to do anything in order for the command to continue executing, but
this is from the perspective of the code that called the low-level reset
function itself. Setting DID_RESET and calling the completion function
is in fact one way of "automatically restarting" the commands is a way of
restarting them. In theory, one could also attempt to requeue them, but
this would be a bit harder, since the DID_RESET approach more or less does
what you need it to do.
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
