On Wed, 18 Nov 2009, Simon Arlott wrote: > > You may have to do a bisection search to find the answer. > > With what? I can't really bisect "the UHCI code" and "the OHCI code"... > > I have no good kernel to work with unless I start trying really old kernels, > but there's no reason why those should work either. I'm hoping someone > recognises the significance of the transfer speed. If you don't have a good kernel to start from then there's nothing to search for. I was assuming that a relatively recent kernel change might have caused the slow-down, but if it has been this way for a long time then a different approach is needed. There's no particular significance to 256 ms that I know of, although if the hardware is malfunctioning it could easily pick such a rate. The page size is significant because that's how the driver and the hardware divide up transfers; each Transfer Descriptor refers to at most 4096 bytes of data. > The OHCI code appears to split the data up into 4096 chunks, but even the > odd sized transfer of 25280 bytes at the end runs at the same speed: > > [ 4774.830569] cxacru: sending fw 0x3 size 0x62c0 to #98668 > [ 4776.410375] cxacru: sending fw 0x3 size 0x100 to #e0 Yep. My intuition says "hardware problem", but there's no hard evidence one way or another. What happens with other sorts of devices, such as a USB flash drive? 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
