>
> Now, my interest is in having a proper implementation for handling SCSI
> resets. I could imagine something like this:
> * Whoever issues or detects a SCSI RESET, should set last_reset (member of
> Scsi_Host structure) to jiffies.
> * Another variable delay_reset specifies how long to wait (this could be set
> by the low-level driver or by the mid-level code, by error-handling or
> whatever). Note that this way the delay after a reset would be a per
> controller thing.
> * The mid-level code does queue commands, but does not send them to the low
> level driver, as long as time_before(jiffies,last_reset+delay_reset)
> * The same holds for the low-level driver: It may have commands in it's own
> queue, but those should not be sent as long as time_before(...).
> * In order to start transfers after the delay_reset time is over, the
> mid-level as well as the low-level code have to use timers, to be woken up.
Okay.
>
> Does this look like a reasonable design?
>
> There are some issues with this approach:
> * Timeouts: If a command has a timeout of 2 seconds and the bus has a
> delay_reset time of 3 seconds, the command would time out, which might not
> be the desired behaviour. It would be necessary to make sure that the
> timing only starts, when the command is sent to the driver. For commands
> already in the low-level queue this is hardly achievable. I don't know,
> if the error handling code will react reasonably on situations like this.
A command that has a timeout must be meant to have a timeout once started-
not while it's on a queue somewhere held up from being started,no?
> * The waiting after a reset caused by the error handling code should be
> integrated with this.
>
> I'm not too familiar with mid-level SCSI code, but this looks like a
> non-trivial thing to implement. Not a 2.2 project, it seems.
> Who is developing mid-level code for 2.3?
I dunno.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
