On Tue, 12 Apr 2011, Graeme Gill wrote: > Alan Stern wrote: > > > Xiaofan was suggesting that your workaround might not be needed with > > later kernels. But keeping the workaround shouldn't hurt anything. > > Hi, > > Yes, but I don't understand the logic that this has anything > to do with my problems. Why would the Linux USB driver be > putting a Set-Interface between each data read ? > [I presume this is not the case.] It wouldn't. Which means your problem has a different cause. > >> ie. if on recent Linux kernels the resetep IOCTL no longer does anything > >> (ie. it doesn't reset the data toggle), then it breaks my workaround. > > > > No. The premise and the conclusion in that sentence are both false. > > Which is what I expected, but wanted confirmed. If that is not > the connection between set-interface and data reads having > (presumed) data toggle issues, what is ? I don't know. A bus analyzer would answer the question definitively. > The interface doesn't get released. To be completely clear the software: > > Opens the device > Configures the device > Resets the data read end point. > Does numerous control transactions > Does control transaction to create read data > Does a data read from the read end point that times out. > > Whereas if it: > > Opens the device > Configures the device > Does numerous control transactions > Does control transaction to create read data > Resets the data read end point. > Does a data read from the read end point OK > Does control transaction to create read data > Resets the data read end point. > Does a data read from the read end point OK > etc. That certainly does _sound_ like a toggle issue. > If I place a secondary hub between the computer and the device, > its behaviour is: > > Opens the device > Configures the device > Resets the data read end point. > Does numerous control transactions > Does control transaction to create read data > Resets the data read end point. > Does a data read from the read end point that times out. > > But only with modern kernels. For 2.6.9-55 the last case works. Bizarre indeed. The presence of an intermediate hub would not affect the data toggle. > > More recent kernels do not automatically send the Set-Interface > > request, providing the interface was already in altsetting 0 when it > > was released. > > These sound like configuration & open/close issues. I don't have any issues > with opening or doing control I/O to the device. It seems as if control operations > set the data toggle to the wrong state for the data read, and therefore > data reads need a resetep to fix it before each read. Yes, this is > probably some sort of firmware problem in the device, but as I said, > it's interesting that MSWin and OS X don't have this problem. > I (and my end users) wouldn't care about that if the secondary > hub case worked, since the resetep workaround is sufficient. In the absence of a bus analyzer, the best we can do is a software trace. If you can provide usbmon traces for the three scenarios given above (preferably all with recent kernels) and an equivalent trace for Windows, comparing them might help. 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
