[2527] in linux-scsi channel archive
Re: Timeout for aborting a SCSI command is too short.
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Wed Sep 24 02:36:48 1997
Date: Tue, 23 Sep 1997 16:18:27 -0700
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: groudier@club-internet.fr
CC: linux-scsi@vger.rutgers.edu
In-reply-to: <Pine.LNX.3.95.970920102804.896B-100000@localhost> (message from
Gerard Roudier on Sat, 20 Sep 1997 10:49:38 +0200 (MET DST))
Date: Sat, 20 Sep 1997 10:49:38 +0200 (MET DST)
From: Gerard Roudier <groudier@club-internet.fr>
Leonard,
It seems that the middle scsi driver only allows 2 seconds to low-level
drivers to abort a command.
When the device has disconnected the bus for a nexus, it is sane
to inform the device that this nexus is canceled prior to completing
the command.
No behaving so required not to send a new command to the device in
order to avoid overlapped command condition (especially when tags are
not used).
Why did the middle scsi driver forces the timeout to be so short (2s) ?
(Did I miss something?)
A simple strategy for a disconnected command to be properly canceled is
to wait the relection, then to send it an ABORT (or ABORT TAG message if
the command is tagged) and then to complete with error the corresponding
SCSI command.
A 2 seconds time-out for this to be done is not enough for devices like
tapes that may reconnect a long time after having disconnected for a
nexus.
I suggest the abort timeout value to be the same as the corresponding
command time-out value or something deduced from (for example half the
command time-out value).
Regards, Gerard.
I don't think the 2 second timeout is really a problem. The usual host adapter
implementation of an abort is for the initiator to select the target at the
earliest possible opportunity and then issue an ABORT or ABORT TAG message as
appropriate. In at least one case I've seen where an abort clears a catatonic
drive condition, waiting for the target to reselect is useless as the target is
never going to.
Leonard
