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.
From a short browsing, there is a mechanism to handle things like that, when
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?
--
Kurt Garloff <[EMAIL PROTECTED]> [Dortmund, FRG]
Plasma physics, high perf. computing [Linux-ix86,-axp, DUX]
PGP key: see mailheader [Linux SCSI driver: DC390]
PGP signature
