[5960] in linux-scsi channel archive
Re: delay after SCSI bus reset
daemon@ATHENA.MIT.EDU (Kurt Garloff)
Sun Feb 21 20:30:52 1999
Date: Sun, 21 Feb 1999 13:13:28 +0100
From: Kurt Garloff <K.Garloff@ping.de>
To: mjacob@feral.com, Richard Waltham <dormouse@farsrobt.demon.co.uk>
Cc: Kurt Garloff <K.Garloff@ping.de>,
Linux SCSI list <linux-scsi@vger.rutgers.edu>
Mail-Followup-To: mjacob@feral.com,
Richard Waltham <dormouse@farsrobt.demon.co.uk>,
Kurt Garloff <K.Garloff@ping.de>,
Linux SCSI list <linux-scsi@vger.rutgers.edu>
In-Reply-To: <Pine.LNX.4.04.9902210221490.1414-100000@feral-gw>; from Matthew Jacob on Sun, Feb 21, 1999 at 02:30:21AM -0800
--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 21, 1999 at 02:30:21AM -0800, Matthew Jacob wrote:
>=20
> > Section 5.7 of the SCSI 2 spec mentions a value of 250ms for a hard res=
et to
> > selection time - but its only a recommendation.
> >=20
>=20
> I don't have my SCSI spec in front of me- this may simply be the
> propagation of the recommended selection timeout of 250ms - if initiators
> will wait up to 250ms then try and be ready before that time has elapsed.
> But there's no guarantee past SCSI bus reset whether a device will respon=
d or
> not.
In my SCSI-2 draft (section 4.7, table 7) it says:
Power-On to Selection Time: 10 s recommended
Reset to Selection Time: 250 ms recommended
So, if the devices do comply with SCSI2 standard, it would be save to wait
only for 0.25s after a reset. However, some devices such as scanners or
CD-Rs tend tend to violate specs, resulting in the need to wait for a longer
time after a bus reset.
Now, my interest is in having a proper implementation for handling SCSI
resets. I could imagine something like this:
* Whoever issues or detects a SCSI RESET, should set last_reset (member of
Scsi_Host structure) to jiffies.
* Another variable delay_reset specifies how long to wait (this could be set
by the low-level driver or by the mid-level code, by error-handling or
whatever). Note that this way the delay after a reset would be a per
controller thing.
* The mid-level code does queue commands, but does not send them to the low
level driver, as long as time_before(jiffies,last_reset+delay_reset)
* The same holds for the low-level driver: It may have commands in it's own
queue, but those should not be sent as long as time_before(...).
* In order to start transfers after the delay_reset time is over, the
mid-level as well as the low-level code have to use timers, to be woken u=
p.
Does this look like a reasonable design?
There are some issues with this approach:
* Timeouts: If a command has a timeout of 2 seconds and the bus has a
delay_reset time of 3 seconds, the command would time out, which might not
be the desired behaviour. It would be necessary to make sure that the
timing only starts, when the command is sent to the driver. For commands
already in the low-level queue this is hardly achievable. I don't know,
if the error handling code will react reasonably on situations like this.
* The waiting after a reset caused by the error handling code should be
integrated with this.
I'm not too familiar with mid-level SCSI code, but this looks like a
non-trivial thing to implement. Not a 2.2 project, it seems.
Who is developing mid-level code for 2.3?
--=20
Kurt Garloff <kurt@garloff.de> [Dortmund, FRG]
Plasma physics, high perf. computing [Linux-ix86,-axp, DUX]
PGP key: see mailheader [Linux SCSI driver: DC390]
--sdtB3X0nJg68CQEu
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3in
iQCVAwUBNs/4aBaQN/7O/JIVAQGCbgP/chqwwZZQvM+uKVS3UHuRT5RKvOHs9sSG
ZS6+5ZWbc1PHbBeC1bjpS5B8RmuXuruLpMUDCtX1Ijo6CcOCA54ozqQJE8LAzdYA
u9DfPLOpHz6Iv5PGkSE53D0+Nl3bjFlYU7ZXEf08SydWPm1lhr0zn04rURkJWLAA
Zf4Raa0VnrI=
=4mDv
-----END PGP SIGNATURE-----
--sdtB3X0nJg68CQEu--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
