[7989] in linux-scsi channel archive
Re: wait after scsi_reset
daemon@ATHENA.MIT.EDU (Kurt Garloff)
Wed Feb 2 09:46:54 2000
Date: Wed, 2 Feb 2000 15:13:48 +0100
From: Kurt Garloff <garloff@suse.de>
To: "Eric Youngdale" <eric@andante.org>
Cc: "Linux SCSI list" <linux-scsi@vger.rutgers.edu>
Message-ID: <20000202151348.E690@mobil.garloff.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="FEz7ebHBGB6b2e8X"
In-Reply-To: <001f01bf6be9$e92aee00$0f17a8c0@eric.home>
--FEz7ebHBGB6b2e8X
Content-Type: text/plain; charset=us-ascii
On Mon, Jan 31, 2000 at 07:48:55AM -0500, Eric Youngdale wrote:
> >currently my SCSI drivers (tmscsim, dc395x_trm) do a very long udelay()
> >after a reset of the SCSI bus did occur. Even worse, an IRQ safe spinlock
> >is held.
> >That's bad, and I don't like it at all.
> >It would actually be enough to prevent the mid-layer sending commands to
> >the driver for a few seconds.
> >What's the best to achieve that? (Is it the same solution for old and new
> >EH? The same for 2.0 -- 2.4?)
>
> This would tend to be much easier with new error handling. In fact with
> the new error handling you should be pretty much guaranteed that there are
> no new commands being issued while error correction is in progress. The
> only place that commands should be issued is from the error handling thread
> itself
And new commands?
> - and the easiest way of keeping the error handling thread from
> proceeding when you are doing a bus reset is to simply not return from your
> dispatch function until after the delay is complete.
I'd prefer to avoid this. I'll have to unlock, but this always risks a
deadlock, if sb. else grabs the io_lock from an IRQ handler. (If it's
properly implemented, it won't give a problem, I believe.)
> In this situation, you
> probably want to release locks and you could probably use something like a
> form of sleep which yields the processor to someone else for a while.
That's possible, of course.
Anyway, what happens, if I detect a RESET on the bus (issued by another
initiator or a device)? I also want to prevent the issueing of commands for
a second or so, then.
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?
Regards,
--
Kurt Garloff <garloff@suse.de> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
--FEz7ebHBGB6b2e8X
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4mDucxmLh6hyYd04RAfsnAKDTQ63m7DLaHIMQ/GpdYRRKsXWf/wCdH0xc
fikmMGNb2ZhPq1CVxHmG4m4=
=4DN8
-----END PGP SIGNATURE-----
--FEz7ebHBGB6b2e8X--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
