On Fri, 28 Jun 2013, Greg KH wrote: > On Fri, Jun 28, 2013 at 04:17:44PM -0700, Sarah Sharp wrote: > > On Fri, Jun 28, 2013 at 03:24:49PM -0400, Alan Stern wrote: > > > Please use Reply-To-All so that your response gets sent to the mailing > > > list as well as to me. And please don't top-post. > > > > > > On Fri, 28 Jun 2013, William Gulland wrote: > > > > > > > Yes, two ClearTTBuffer requests seem to be necessary with Intel's CaveCreek > > > > integrated rate-matching hub - I've got it into the state where control > > > > requests to a USB 1.1 device were failing, > > > > > > How did you manage to do that? > > > > > > > but recovered when I sent the > > > > hub a ClearTTBuffer for endpoint 0 - but only if I set the IN bit in the > > > > request. > > > > > > This sounds like a bug in the Intel hub hardware, or at least, > > > unintentional behavior. > > > > > > Sarah, is this the sort of thing the Intel engineers would want to know > > > about? > > > > I will send them a report. However, if this was found on production > > hardware, there's probably not much they can do about it for CaveCreek. > > Then we should only do this for that specific hardware device, right? The thing is, we don't know which devices are affected. William tested only the CaveCreek integrated hub, so it's possible that other hubs are affected too. And it's not an easy test to do, because it relies on some sort of unlikely error situation to arise first. He mentioned that it takes hours, and he has to do intensive I/O to three devices simultaneously to make it happen. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
