Ricky Beam wrote:
> 
> On Tue, 13 Jun 2000, Stanley Wu wrote:
> >There is definitely a need to specify different
> >timeout values for different SCSI commands.  For
> ...
> 
> I think there needs to be at least two independant timeouts.  One for the
> scsi core and one for the driver.  Right now, I see command timeouts before
> they were ever sent to the driver to be processed -- why should I reset the
> scsi bus (read: fuck up the scsi subsystem) because the kernel failed to
> post a command.
> 
> Timeouts are for the handling of exceptions -- basically a means to sense
> that something is wrong.  It's up to the driver to decide if the command
> it has been asked to perform has actually failed or "timed out".  The scsi
> core needs a timer for application interfacing -- i.e. to signal EIO much
> in the same fashion as an NFS fault if a command takes "too long."
> 
> This is not an easy problem to handle.  Different devices and different
> commands can have various execution times.  Mix in RAID hardware and any
> predictablity goes right out the window.  Additionally, there needs to be
> lock(s) for device and bus level resets -- all the scsi drivers need some
> serious "reset logic" improvements. ... *sigh*

I tried to add some logic to the mid level driver [core] so that the
upper level drivers (specifically sg under superuser's instruction) 
could request a SCSI bus/device/host reset. Basically the patch was 
rejected because it might interfere with the mid level's error 
processing.

My feeling is that in some contexts [best known to a user application
or an upper level driver] turning off the mid level's error processing
might be advantageous. There is also no way for an application or an
upper level driver to abort a SCSI command in progress. This means
that an application can't set an extremely long timeout to the SCSI
subsystem, run its own timer, and if that timer expires, abort the 
outstanding command.

Doug Gilbert

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Reply via email to