[8134] in linux-scsi channel archive
Re: wait after scsi_reset
daemon@ATHENA.MIT.EDU (Kurt Garloff)
Sun Feb 20 20:04:18 2000
Date: Mon, 21 Feb 2000 01:57:36 +0100
From: Kurt Garloff <garloff@suse.de>
To: "Eric Youngdale" <eric@andante.org>,
"Linux SCSI list" <linux-scsi@vger.rutgers.edu>
Message-ID: <20000221015736.Z25715@mobil.tue.nl>
Mail-Followup-To: "Eric Youngdale" <eric@andante.org>,
"Linux SCSI list" <linux-scsi@vger.rutgers.edu>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="vWfgMjdKllQeoPX8"
In-Reply-To: <20000205173724.C12494@mobil.tue.nl>
--vWfgMjdKllQeoPX8
Content-Type: text/plain; charset=us-ascii
On Sat, Feb 05, 2000 at 05:37:25PM +0100, Kurt Garloff wrote:
> > >So, I imagine a solution, where I just don't allow commands being queued
> > >with queuecommand in that period of time.
> > >Is returning with 1 fine for new EH. Will it resent the commands later
> > then?
> > >Or is it better calling scsi_done with DID_RESET for all new commands?
> > >Should the latter also work with old EH?
> >
> > Returning 1 from the queuecommand function will work to a point, but the
> > mid-level won't start queueing new commands until one of the existing
> > commands that is on the bus finishes. If the bus was otherwise idle and a
> > reset was detected, then there would be no mechanism to restart.
>
> Can't you set a timer for this? I would like the mid-level code make sure
> that commands in its queue never starve. If no outstanding commands are
> there, it's its responsability to set a timer to try again after some time
> (a second or so), IMHO. This can happen in normal operation, too, I think.
> The driver is not ready to accept a command (for whatever reason) and
> returns 1 therefore. What does the midlayer do, if there no more outstanding
> commands?
It was just to easy. I implemented a timer in the driver. Now, it always
accepts commands, also right after a RESET. Only, those are not sent out to
the bus, until the timer wakes up the queue again.
> What about ordering of the commands? We need to maintain it in presence of
> writes and reads to the same block. Are the commands aborted with DID_RESET
> issued again in the same order to the driver? The ones returned to mid-level
> from queuecommand with exit 1 (new EH)? If no, exception handling is very
> unsafe! If yes, the driver then could send all commands in its queues back
> to the mid-level with DID_RESET, such that all could be resend in the
> right order.
By looking at the ML behaviour, I guess giving back all cmnds in the right
order (odlest first) is the only way :-(
Regards,
--
Kurt Garloff <garloff@suse.de> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
--vWfgMjdKllQeoPX8
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4sI2AxmLh6hyYd04RASl7AKCPdRKZ/6eSk66O9iCm2lJQPgM10wCfb0Ux
fGr4xUP1tqDelCQcgZvpFKE=
=IpuI
-----END PGP SIGNATURE-----
--vWfgMjdKllQeoPX8--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
