>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 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. 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.
With the old error handling code, the situation is quite different. By
design (or lack of, thereof), new commands are still being pushed down to
the queuecommand function while error handling is in progress. There isn't
anything in the design which can be used to shut off the spigot as it were -
continuing to hold the lock isn't a great option, but it is one that would
work, I guess.
-Eric
----- Original Message -----
From: "Kurt Garloff" <[EMAIL PROTECTED]>
To: "Linux SCSI list" <[EMAIL PROTECTED]>
Cc: "Eric Youngdale" <[EMAIL PROTECTED]>
Sent: Saturday, January 29, 2000 1:38 PM
Subject: wait after scsi_reset
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
