[5948] in linux-scsi channel archive
delay after SCSI bus reset
daemon@ATHENA.MIT.EDU (Kurt Garloff)
Sat Feb 20 14:45:51 1999
Date: Sat, 20 Feb 1999 20:41:15 +0100
From: Kurt Garloff <K.Garloff@ping.de>
To: Linux SCSI list <linux-scsi@vger.rutgers.edu>
Mail-Followup-To: Linux SCSI list <linux-scsi@vger.rutgers.edu>
--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Hi SCSI experts,
there are some places, where I have to wait for a large amount of time
within my SCSI driver:
* after issueing a bus reset
* after detecting one
This waiting is done by udelay/mdelay and takes a couple of seconds
(adjustable). During this time, the kernel can't do anything useful, since
the (irq save) io_request lock is held. So this is very bad.
Maybe you could ignore this problem for SCSI driver initialization at boot
up time, but think of resets and/or modules loading during normal operation.
(Fortunately this does not happen very often.)
You won't be able to serve a serial/network/whatever interrupt for a
couple of seconds! Your clock (date) will be off by some seconds.
I was always thinking that my driver implementation is rather bad to do it
that way, but other drivers take the same approach, so I guess it has to be
done that way.
Now, the delay after the SCSI bus reset has to ensure, that there is some
time between the reset and the next SCSI commands in order to give slow
devices the possibility to recover from the reset. This could be done by
just preventing the driver from issueing new commands for a certain amount
of time or even better by preventing the mid-level scsi code from sending
commands to the driver. The long udelay/mdelay in the driver then would be
unecessary.
=46rom a short browsing, there is a mechanism to handle things like that, w=
hen
the reset is issued by the scsi error handling code and the last_reset
variable is used to store the time when this occured.
It would be nice to find an approach to handle this in a general way.
Any ideas or comments?
--=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]
--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3in
iQCVAwUBNs8P2xaQN/7O/JIVAQH3FAP+M9pVJeahTECphd4xgbG/J6mQtNa8NSgl
Nu4ZUUK2Ini62RzQ9LgmSqmHbaoiubbnZ7A6rBp0nOZ0+k0xG8U3D3VfR+Hpw5n8
SusbwLGu3TSehXh6tMKJQSrvXA93ubbKpAlRxZzsi1KjsLarkd9/gSivAGJlpXRr
i39FlGODwjI=
=IAzD
-----END PGP SIGNATURE-----
--OXfL5xGRrasGEqWY--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu