> > I'm developing a Linux driver for a Logitech USB webcam. A few users > > reported that the webcam stopped responding under some conditions. After > > some investigation, I found out that the device either timed-out or > > returned a STALL handshake during a control transfer on endpoint 0. > > > > Logitech has been kind enough to investigate the problem. It seems a > > hardware bug is triggered when the control transfer transactions are sent > > "too fast". Preliminary results show that the hardware misses the second > > transaction in a control transfer when both the SETUP and IN/OUT > > transactions are in the same USB frame. > > > > I was wondering if anyone has ever seen such behaviour with other > > devices. > > I have, or something very similar. IIRC it was some sort of USB wireless > keyboard/mouse controller built into a laptop. It wouldn't enumerate if > the transactions came too close together, although after it was configured > there didn't seem to be any problem.
I'm not sure if I'm really happy to know there are more broken devices than I thought :-) > > It > > seems the bug is never triggered when using Microsoft Windows, so I > > suspect that Linux uses a faster scheduler. Is there a way to hack the > > USB scheduler to make it split control transfers across USB frames ? We > > would like to test if the hardware bug would then be still triggered. > > Which host controller driver are you using? uhci-hcd always splits > control transfers like this (each transaction in a different frame) for > unconfigured devices. If you want to hack uhci-hcd so that it splits up > control transfers all the time, I can send you a patch. As far as I know, > it's impossible to make OHCI hardware do the same thing. I'm using an EHCI controller. Does it matter if the USB 1.1 controller is an OHCI or UHCI ? It would be nice if you could send me the patch. > BTW, Windows does not split up control transfers for devices after they > are configured. Not in general, anyway -- the Logitech device might be an > exception. I'm not aware of anything specific being done by Logitech in respect to the way Windows schedules USB control transfers. The problem seems quite weird to me. On one hand, this is clearly a hardware bug. When the control transfer is sent "too fast", the device misses an interrupt, and either times out or STALL. On the other hand, the problem doesn't occur when using Microsoft Windows. Logitech is working on a firmware workaround for their next release, but devices already on the marker will still suffer from the bug. I was hoping to understand why Windows does not trigger the bug, and try to find a software fix for Linux. Laurent Pinchart ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
