[PATCH] SCSI: increase default timeout for INQUIRY

[PATCH] SCSI: increase default timeout for INQUIRY

[Alan Stern]

This patch (as1224) changes the default timeout for INQUIRY commands
from 3 seconds to 20 seconds, which is the value used by Windows for
USB Mass-Storage devices.  Some of these devices, like the Corsair
Flash Voyager (see Bugzilla #12188) really do need a long timeout.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

---

It's hard to see how this could cause any signficant problems, unless 
somebody actually depends on INQUIRY timing out.



Index: usb-2.6/drivers/scsi/scsi_scan.c
===================================================================
--- usb-2.6.orig/drivers/scsi/scsi_scan.c
+++ usb-2.6/drivers/scsi/scsi_scan.c
@@ -115,12 +115,12 @@ MODULE_PARM_DESC(max_report_luns,
 		 "REPORT LUNS maximum number of LUNS received (should be"
 		 " between 1 and 16384)");
 
-static unsigned int scsi_inq_timeout = SCSI_TIMEOUT/HZ+3;
+static unsigned int scsi_inq_timeout = SCSI_TIMEOUT/HZ + 18;
 
 module_param_named(inq_timeout, scsi_inq_timeout, uint, S_IRUGO|S_IWUSR);
 MODULE_PARM_DESC(inq_timeout, 
 		 "Timeout (in seconds) waiting for devices to answer INQUIRY."
-		 " Default is 5. Some non-compliant devices need more.");
+		 " Default is 20. Some devices may need more; most need less.");
 
 /* This lock protects only this list */
 static DEFINE_SPINLOCK(async_scan_lock);

Re: [PATCH] SCSI: increase default timeout for INQUIRY

[Matthew Wilcox]

On Thu, Mar 12, 2009 at 11:08:51AM -0400, Alan Stern wrote:
> It's hard to see how this could cause any signficant problems, unless 
> somebody actually depends on INQUIRY timing out.

Erm, like doing a scan of a bus?  With 15 devices to probe, you've
increased the time from 15 * 3 = 45 seconds to 15 * 20 = 300 seconds.
That's not cool ;-(

Maybe we could default this in the transport or something so USB can
override it.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [PATCH] SCSI: increase default timeout for INQUIRY

[James Bottomley]

On Thu, 2009-03-12 at 09:12 -0600, Matthew Wilcox wrote:
> On Thu, Mar 12, 2009 at 11:08:51AM -0400, Alan Stern wrote:
> > It's hard to see how this could cause any signficant problems, unless 
> > somebody actually depends on INQUIRY timing out.
> 
> Erm, like doing a scan of a bus?  With 15 devices to probe, you've
> increased the time from 15 * 3 = 45 seconds to 15 * 20 = 300 seconds.
> That's not cool ;-(
> 
> Maybe we could default this in the transport or something so USB can
> override it.

Well, no, this is the overall command timeout.  Each bus (that's
scannable) has its own timeout.  For instance, on a parallel bus this is
250ms per device ... don't respond in that time, we return
DID_NO_CONNECT.

I think what Alan is saying is that some USB devices will take >5s to
respond to an initial inquiry.  Remember that USB isn't actually a
scannable bus.  We get told there's a device there and we have to send
an INQUIRY to classify it.

James

Re: [PATCH] SCSI: increase default timeout for INQUIRY

[Alan Stern]

On Thu, 12 Mar 2009, James Bottomley wrote:

> On Thu, 2009-03-12 at 09:12 -0600, Matthew Wilcox wrote:
> > On Thu, Mar 12, 2009 at 11:08:51AM -0400, Alan Stern wrote:
> > > It's hard to see how this could cause any signficant problems, unless 
> > > somebody actually depends on INQUIRY timing out.
> > 
> > Erm, like doing a scan of a bus?  With 15 devices to probe, you've
> > increased the time from 15 * 3 = 45 seconds to 15 * 20 = 300 seconds.
> > That's not cool ;-(
> > 
> > Maybe we could default this in the transport or something so USB can
> > override it.
> 
> Well, no, this is the overall command timeout.  Each bus (that's
> scannable) has its own timeout.  For instance, on a parallel bus this is
> 250ms per device ... don't respond in that time, we return
> DID_NO_CONNECT.
> 
> I think what Alan is saying is that some USB devices will take >5s to
> respond to an initial inquiry.  Remember that USB isn't actually a
> scannable bus.  We get told there's a device there and we have to send
> an INQUIRY to classify it.

That's right.  There are a few devices which take > 15 seconds to 
respond to INQUIRY, but once they do respond they go on to work 
correctly and at a reasonable speed.  Apparently this is some sort of 
initialization delay.

Obviously this isn't a huge issue, since users can set the module
parameter for themselves.  But it's a lot easier if they don't have to
-- especially since they won't have to figure out what _needs_ to
changed (it isn't at all obvious from the pattern of errors).

Alan Stern