Hi Jakub, [CC'ing Matthew Garrett and linux-usb] On Tuesday 29 May 2012 20:52:09 Jakub Jankowski wrote: > On Monday 28 of May 2012, you wrote: > > > I'm writing to let you know that there is a regression in uvcvideo for > > > my camera: (adding missing part of the log from a previous e-mail) uvcvideo: Device requested 3060 B/frame bandwidth. uvcvideo: Selecting alternate setting 11 (3060 B/frame bandwidth). usb 2-2: USB disconnect, device number 6 uvcvideo: Allocated 5 URB buffers of 32x3060 bytes each. uvcvideo: Failed to submit URB 0 (-19). usb 2-2: new high-speed USB device number 7 using ehci_hcd > > > usb 2-2: New USB device found, idVendor=5986, idProduct=02c1 > > > usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > > > usb 2-2: Product: BisonCam, NB Pro > > > usb 2-2: Manufacturer: BISON Corporation > > > usb 2-2: SerialNumber: 20090505 > > > uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:02c1) > > > input: BisonCam, NB Pro as > > > /devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.0/input/input13 > > > This is a webcam present in MSI U200 (Wind12) netbook series. > > > > > > Last working version of uvcvideo is the one shipped with 2.6.36 kernel, > > > first kernel that ships a broken version is 2.6.37 (and 3.4 still > > > doesn't work). What happens is, when any software (guvcvideo, flash > > > plugin, skype) tries to access the webcam, kernel sees an USB disconnect > > > and immediate reconnect. > > > > There can be several causes to this issue. A device disconnecting on its > > own without reason is definitely a bug, and can be caused by a device > > firmware bug (most UVC webcams are known to be very buggy) or a USB core > > bug. I usually incriminate the device firmware first, a change on the host > > side (either in the USB core or the UVC driver) might have cause > > differences in timings that can trigger a race condition on the device > > side. > > > > The best way to debug this would be to bisect the kernel. Would you be > > able to do that ? > > It took me a while (on my CULV 1.3GHz netbook...), but here it goes: > > $ git bisect good > 3dae8b41dc5651f8eb22cf310e8b116480ba25b7 is the first bad commit > commit 3dae8b41dc5651f8eb22cf310e8b116480ba25b7 > Author: Matthew Garrett <mjg@xxxxxxxxxx> > Date: Thu Sep 16 15:00:04 2010 -0300 > > V4L/DVB: uvc: Enable USB autosuspend by default on uvcvideo > > We've been doing this for a while in Fedora without any complaints. > > Signed-off-by: Matthew Garrett <mjg@xxxxxxxxxx> > Acked-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> > > :040000 040000 8df4a95ecacca8f551552ee55c86261701250b6c > > 09686bc05852cd9dd4c9b3501138ec7cc32d7c78 Mdrivers > $ > > Furthermore, I can confirm that reverting this commit in 3.4 codebase fixes > my problem. Thanks a lot for working on this. Matthew, it seems you have a complaint now :-) Would you be able to try and debug that with Jakub ? Jakub, the first step will probably be to enable USB debugging (CONFIG_USB_DEBUG=y) and send the complete kernel log around the disconnection. Would you be able to do that ? -- Regards, Laurent Pinchart -- 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
