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]
