> > > > 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 ? > > Is the Logitech webcam a full-speed device or does it use high-speed? If > it is full-speed, is it behind a high-speed hub? These things will affect > which controller gets used. If it is behind a high-speed hub, does it > work better when you connect it directly to the computer?
The webcam is a high-speed device connected to the root hub. > For most purposes it doesn't matter whether a full-speed controller is > OHCI or UHCI. OHCI does more of the work in hardware, so it puts less > load on the host computer. By the same token, its scheduling is less > flexible since the host has less direct control. > > > It would be nice if you could send me the patch. > > See below. > > > > 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. > > Does this happen while the camera is in normal operation or only during > the initial enumeration? If it happens during operation, why do you need > to send control transfers to the camera while it is sending you data? During normal operation. Control transfers are used to set controls such as brightness. > > 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. > > You probably won't get too far trying to understand Windows' behavior by > asking questions on a Linux mailing list. :-) Well, many talented Linux programmers know more about Windows than Windows programmers themselves :-) > Before anything can be fixed we need more details about the problem, like > when it occurs, what is being transferred, maybe even USB bus traces if > you can get them. A developer at Logitech is working on the problem, I'll ask him for traces. > How did you determine the source of the problem? Did the engineers at > Logitech figure it out for you? If so, have they made a similar analysis > of what happens with Windows to see why it works better? They are working on it, but they don't have lots of traces yet. I'll ask them to send more information on this mailing list directly, this should be easier. The problem is definitely in the webcam hardware (they are working on a firmware workaround), but the weird part is it is not triggered by Windows. Thanks for the patch, I'll see if it helps. 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
