There is definitely a need to specify different
timeout values for different SCSI commands. For
example, a write_file_mark of more than 5 seconds for
a tape drive could be an indication something is
wrong, but a 5 seconds for the read_element_status of
a tape library can be perfectly normal. Some library
devices will move a cleaning cartridge into the drive
before the data cartridge if the drive cleaning is
required. This 'move medium' scsi operation can take
minutes.
regards,
Stanley
--- "Boerner, Brian" <[EMAIL PROTECTED]>
wrote:
> This also benefits HW raid devices. Some of these
> devices support
> pausing the I/O on the controller to allow people to
> swap failed drives.
>
> This isn't a problem with smart enclosures, but
> older enclosures don't
> support this. So, pausing the I/O on the controller
> allows for the
> failed drive to be replaced without interrupting the
> system. However,
> it usually takes more than a few seconds and if this
> is on your boot
> device, guess what happens... panic.
>
> I didn't see any posts for or against this.
>
> -bmb-
>
>
> > -----Original Message-----
> > From: Matthew Dharm
> [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, June 07, 2000 12:34 AM
> > To: Linux SCSI list; Kernel Developer List
> > Subject: Re: Can we change the SCSI command
> timeout?
> >
> >
> > Some people have asked me for some clarification
> on my
> > request.... I hope
> > this message can clear up most people's questions.
> >
> > Basically, there is a class of USB devices which
> are actually
> > USB to SCSI
> > bus bridges. For most commands (such as READ_10),
> the bridge
> > works very
> > well. We send the command, and it can determine
> when the
> > full load of data
> > has been transported and the command has
> completed. However,
> > for a command
> > like INQURIRY, the bridge can't really tell how
> much data there is to
> > transfer.
> >
> > In these cases, the bridge begins transferring the
> INQUIRY
> > data, and then
> > waits to see if there is any more data. The
> timeout built-in to these
> > devices (in the ASICs) is about 5 seconds (+ or -
> a little
> > bit -- these are
> > experimentally observed numbers). After the
> device timeout occurs, it
> > concludes the transfer.
> >
> > Unfortunately, with the current linux timeout of 2
> seconds,
> > the OS timeout
> > fires before the device timeout does. There is
> nothing wrong with the
> > command, the device, or the bridge -- the only
> thing we need
> > to do is wait
> > longer before attempting to abort the command.
> >
> > Matt Dharm
> >
> > On Tue, Jun 06, 2000 at 06:52:08PM -0700, Matthew
> Dharm wrote:
> > > Can we increase the timeout for some comamnds?
> > >
> > > Specifically, some USB devices (notably the
> USB/SCSI
> > bridges) which use the
> > > USB SCSI emulation need about 5-6 seconds to
> respond to an
> > INQUIRY (as well
> > > as a couple of other commands).
> > >
> > > I didn't have this problem on older kernels -- I
> suspect
> > that someone either
> > > changed the timeout or change the default
> debugging defines.
> > >
> > > The current timeout in 2.4.0-test1-ac8 is about
> 2 seconds.
> > This is defined
> > > in drivers/scsi/scsi.h -- increasing this to 6
> seconds
> > works fine. Or, in
> > > scsi_scan.c, increase the timeout used for the
> probing
> > INQUIRY command from
> > > the default of SCSI_TIMEOUT to 6*HZ.
> > >
> > > I can send a patch if it's desired -- but I was
> wondering what the
> > > preferred choice is.
> > >
> > > Matt Dharm
> > >
> > > --
> > > Matthew Dharm Home:
>
> > [EMAIL PROTECTED]
> > > Senior Engineer, QCP Inc.
> Work:
> > [EMAIL PROTECTED]
> > >
> > > Department of Justice agent. I have come to
> purify the flock.
> > > -- DOJ agent
> > > User Friendly, 5/22/1998
> > >
> > > -
> > > To unsubscribe from this list: send the line
> "unsubscribe
> > linux-scsi" in
> > > the body of a message to
> [EMAIL PROTECTED]
> >
> > --
> > Matthew Dharm Home:
> > [EMAIL PROTECTED]
> > Senior Engineer, QCP Inc.
> Work:
> > [EMAIL PROTECTED]
> >
> > You are needink to look more evil. You likink
> very strong coffee?
> > -- Pitr to Dust Puppy
> > User Friendly, 10/16/1998
> >
> > -
> > To unsubscribe from this list: send the line
> "unsubscribe
> > linux-kernel" in
> > the body of a message to
> [EMAIL PROTECTED]
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
