On Mon, Jun 04, 2012 at 05:19:52PM +0200, Laurent Pinchart wrote: > 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 ? Ok, so something in the resume path triggers a disconnect. Oliver, any ideas? -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- 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
