On Mon, 21 Feb 2000, Kurt Garloff wrote:
> On Sat, Feb 05, 2000 at 05:37:25PM +0100, Kurt Garloff wrote:
> It was just to easy. I implemented a timer in the driver. Now, it always
> accepts commands, also right after a RESET. Only, those are not sent out to
> the bus, until the timer wakes up the queue again.
The scsi_block_requests()/scsi_unblock_requests() functions are
present in the distribution kernel - it might be safer and easier to call
the block function when you detect the reset, and call the unblock
function after the timer fires.
> > What about ordering of the commands? We need to maintain it in presence of
> > writes and reads to the same block. Are the commands aborted with DID_RESET
> > issued again in the same order to the driver? The ones returned to mid-level
> > from queuecommand with exit 1 (new EH)? If no, exception handling is very
> > unsafe! If yes, the driver then could send all commands in its queues back
> > to the mid-level with DID_RESET, such that all could be resend in the
> > right order.
>
> By looking at the ML behaviour, I guess giving back all cmnds in the right
> order (odlest first) is the only way :-(
Commands returned from queuecommand with exit 1 will be pushed to
the head of the queue, so there shouldn't be any issues with other
commands that were not yet queued. The problem that will occur is if the
low-level driver has several commands on the bus at the same time, and
these all get pushed back - in this case they will get pushed in a sort of
LIFO order (I believe), as the last one in gets pushed to the head of the
queue.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
