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 <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
