On Fri, 30 Aug 2013, Jürgen Liebmann wrote: > Another mystery effect: > > I have Ubuntu with the same kernel installed in a virtual machine (virtualbox). > > When I plug in the camera in the host the error appears. > > Then I plug in the camera in the virtual machine camera works fine. > And now I shut down virtual machine. > > Now I can use the camera in host until I remove the camera. > A new plug in produces the error again. This does seem to indicate that the problem is in the camera. > Can it be that the time between the both Get-String-Descriptor requests are too small? You mean the time between the two class-specific requests? Yes, this is possible. (But the commit you found increases that time, so it should not have caused the problem to occur.) Anyway, if you want to increase the time between those two requests, you will have to change the video driver. Maybe Laurent can help (see the analysis below). Alan Stern > Am 28.08.2013 22:51, schrieb Alan Stern: > > On Wed, 28 Aug 2013, Jürgen Liebmann wrote: > > > >> In the attachment the both usbmon traces: > >> > >> usbmon-reverted.out (camera works ok) > >> usbmon-74a6af256648 (camera fails) > > > > This is very strange indeed. Here's where the two traces start to get > > different results. In the kernel with the commit reverted: > > > > ffff88023073f9c0 742830275 S Co:2:009:0 s 01 0b 0000 0001 0000 0 > > ffff88023073f9c0 742830331 C Co:2:009:0 0 0 > > ffff88023073f9c0 742830336 S Ci:2:009:0 s a1 87 0100 0001 001a 26 < > > ffff88023073f9c0 742830583 C Ci:2:009:0 -32 0 > > ffff88023073f9c0 742830592 S Ci:2:009:0 s a1 81 0100 0001 001a 26 < > > ffff88023073f9c0 742831081 C Ci:2:009:0 0 26 = 01000101 15160500 00000000 00000000 00000018 0300fc03 0000 > > ffff88023073fc00 742831291 S Ci:2:009:0 s 80 06 0302 0409 00ff 255 < > > ffff88023073fc00 742831583 C Ci:2:009:0 0 52 = 34034d00 69006300 72006f00 73006f00 66007400 20004c00 69006600 65004300 > > > > This shows a successful Set-Interface request, followed by an > > unsuccessful class-specific request and a successful class-specific > > request which returns 26 data bytes. Following that, the computer > > reads a 52-byte string descriptor. > > > > Now here's the same thing with the commit present: > > > > ffff880233820f00 1078447196 S Co:2:008:0 s 01 0b 0000 0001 0000 0 > > ffff880233820f00 1078447253 C Co:2:008:0 0 0 > > ffff880233739cc0 1078447266 S Ci:2:008:0 s a1 87 0100 0001 001a 26 < > > ffff880233739cc0 1078447523 C Ci:2:008:0 -32 0 > > ffff880233739cc0 1078447539 S Ci:2:008:0 s a1 81 0100 0001 001a 26 < > > ffff880233739cc0 1078447898 C Ci:2:008:0 -32 0 > > ffff880233739a80 1078448123 S Ci:2:008:0 s 80 06 0302 0409 00ff 255 < > > ffff880233739a80 1078448542 C Ci:2:008:0 0 26 = 01000101 15160500 00000000 00000000 00000018 0300fc03 0000 > > ffff880233739a80 1078448556 S Ci:2:008:0 s 80 06 0302 0409 00ff 255 < > > ffff880233739a80 1078448907 C Ci:2:008:0 0 52 = 34034d00 69006300 72006f00 73006f00 66007400 20004c00 69006600 65004300 > > > > This starts with the same Set-Interface request and the same > > unsuccessful class-specific request. But the second class-specific > > request also fails, and the Get-String-Descriptor returns the 26 bytes > > of class-specific data! The Get-String-Descriptor request is repeated, > > and this time the device sends the correct 52-byte string descriptor. > > After that everything seems to return to normal. > > > > I don't understand this at all. There is no way that commit could > > cause the driver to malfunction like this. The only thing I can think > > of is some sort of hardware problem, either in the computer or (less > > likely) in the camera. > > > > Can you try testing this on a different computer? > > > > 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
