[9378] in linux-scsi channel archive
Re: Adaptec dies after powerloss of a drive
daemon@ATHENA.MIT.EDU (Kurt Garloff)
Sat Aug 12 10:29:34 2000
Date: Sat, 12 Aug 2000 16:26:14 +0200
From: Kurt Garloff <garloff@suse.de>
To: Martin Peschke <peschke@fh-brandenburg.de>
Cc: Eddie Williams <Eddie.Williams@SteelEye.com>,
linux-scsi@vger.rutgers.edu
Message-ID: <20000812162614.K19981@D250.suse.de>
Mail-Followup-To: Kurt Garloff <garloff@suse.de>,
Martin Peschke <peschke@fh-brandenburg.de>,
Eddie Williams <Eddie.Williams@SteelEye.com>,
linux-scsi@vger.rutgers.edu
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="dpynvXbW/eW9Tpc3"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10008111659170.8523-100000@zeus.fh-brandenburg.de>; from peschke@fh-brandenburg.de on Fri, Aug 11, 2000 at 05:16:00PM +0200
--dpynvXbW/eW9Tpc3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 11, 2000 at 05:16:00PM +0200, Martin Peschke wrote:
> The mentioned behavior should depend on whether we have an environment
> with several initiators or not. (Is it possible to detect this by means of
> INQUIRY?)
In general, it's not possible.
I disagree, the behaviour should NOT depend on the question how many
inititators there are on a bus.
The error handling strategy should be such, that detected SCSI resets do not
lead to further resets.=20
If a driver just resets its negotiated parameters and does give back all
sent (and queued) commands back to the mid-layer with DID_RESET, they will
be just requeued and not time out or be aborted (which could lead to a bus
reset).=20
That's the right thing, and I have no idea, what some drivers (or the new
EH?) do in order to screw things up and start reset wars.
BTW, I have a Am53c974 (tmscsim), a sym53c875 and a TRM-S1040 (dc395x_trm)
on a SCSI bus and never managed to start a reset war, despite manually
resetting the bus quite often.
> A more defensive error handling should be applied in such
> environments. A compromise: let the user decide, i.e. during kernel
> configuration by means of a SCSI midlayer option forcing defensive error
> recovery.
A more defensive strategy would be nice in all environments.
However, I disagree with those people that claim that a bus reset is never
any good. It is. As the last thing before finally failing, I prefer SCSI bus
resets. And I've seen devices saved by this.
However, the SCSI subsystem should get some memory. If there are a like two
consecutive bus resets caused by the same device, it should be just taken
offline.
Regards,
--=20
Kurt Garloff <garloff@suse.de> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
--dpynvXbW/eW9Tpc3
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org
iD8DBQE5lV6GxmLh6hyYd04RAuqMAJ9XLr/FGpD4PEn3hWsBU64/P99y9ACgvSnM
OmwqeB3r2d1KqA4zAA6cChI=
=YJpY
-----END PGP SIGNATURE-----
--dpynvXbW/eW9Tpc3--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
