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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
