Bug 44191

Summary:	046d:08c1 Quickcam Fusion stops working after first time (from 2.6.39-rc1 onward)
Product:	v4l-dvb	Reporter:	Eric Ding (jk79xfbjhg)
Component:	webcam	Assignee:	Alan (alan)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	alan, jrnieder
Priority:	P1
Hardware:	i386
OS:	Linux
Kernel Version:	3.2.0-25-generic	Subsystem:
Regression:	Yes	Bisected commit-id:
Attachments:	disable autosuspend for Logitech Quickcam Fusion turn on USB_QUIRK_RESET_RESUME for Logitech Quickcam Fusion

Description Eric Ding 2012-07-03 14:33:17 UTC

From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops working if I turn it on (e.g., guvcview), then shut it off, wait a few seconds, and then turn it on again.  From the second time onward, all I get is screen noise rather than the expected video images.

I did a kernel bisection, which revealed the commit that caused the regression: 

commit e1620d591a75a10b15cf61dbf8243a0b7e6731a2
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date: Fri Mar 18 19:55:36 2011 +0100

    USB: Move runtime PM callbacks to usb_device_pm_ops

    USB defines usb_device_type pointing to usb_device_pm_ops that
    provides system-wide PM callbacks only and usb_bus_type pointing to
    usb_bus_pm_ops that provides runtime PM callbacks only. However,
    the USB runtime PM callbacks may be defined in usb_device_pm_ops
    which makes it possible to drop usb_bus_pm_ops and will allow us
    to consolidate the handling of subsystems by the PM core code.

    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Greg Kroah-Hartman <gregkh@suse.de>

Some more trial-and-error revealed the underlying hardware issue: this webcam does not play well after a suspend/resume cycle -- after either a runtime autosuspend/resume cycle (in 2.6.39-rc1 or newer), or a system suspend/resume cycle, I get the same video gibberish.  Moreover, if I try connecting to another system running Win7 and do a system suspend/resume, I again see a similar problem.

I've reported this already on Ubuntu (see LP#1017072), but since this is an upstream kernel issue, I'm now reporting it here as well.  It appears to me that some possible steps now would be either:

1) not to enable runtime autosuspend by default for this webcam (e.g., via a new UVC quirk in uvc_driver.c:uvc_probe()), or 

2) to follow the rabbit trail of the above commit to figure out why it (rather than 3dae8b4, when autosuspend was enabled by default on uvcvideo) tickled this hardware bug.  Is it because autosuspend didn't actually suspend the webcam before this point?  Or because the way autosuspend works actually changed as a result of this commit?  Going down this road myself would quickly lead me to getting in way over my head, so I've refrained, but I'm willing to help test.

For now, the sledgehammer workaround on my system is to turn off USB autosuspend altogether (echo -1 > /sys/module/usbcore/parameters/autosuspend).  But that's obviously non-ideal.

Thanks for your attention!

Comment 1 Eric Ding 2012-07-03 14:44:40 UTC

Just to clarify: this webcam works on my Thinkpad R61 even after a system suspend/resume cycle in 2.6.38 (but not 2.6.39-rc1 or later)!  So the problem's not as simple as "this webcam doesn't work after resume".  What this might imply, I'm at the moment a little too tired to figure out.  But it does seem like it might be significant.

Comment 2 Alan 2012-07-05 10:06:49 UTC

I think the right thing to do for now is probably to disable autosuspend on this specific camera

It ought to be enough to just check id->idVendor and id->idProduct so I'd give it a go and see

Comment 3 Eric Ding 2012-07-05 11:36:48 UTC

Disabling autosuspend for the appropriate device would work around this issue in part, though it doesn't resolve the issue where it doesn't work after resume.  Still, given that I rarely keep the webcam connected through sleep/resume cycles, and that the webcam also fails on Win7 after a suspend/resume cycle, I'm not too concerned about that use case.

Are you suggesting that I do this manually, or that this be programmatically implemented?

Comment 4 Alan 2012-07-05 13:01:08 UTC

I'd just stick the code in the probe to not enable autosuspend at the end for that specific device, test it and if it work ssubmit the patch.

Suspend/resume may be trickier. One thing to try is whether unloading and reloading the driver fixes it. If that makes a difference then it would imply that making suspend/resume for that device do a complete re-initialize might do the trick. If that fails it may simply not be fixable.

Comment 5 Eric Ding 2012-07-06 02:53:59 UTC

Created attachment 74911 [details]
disable autosuspend for Logitech Quickcam Fusion

This patch works ok for me.  It takes advantage of the fact that this webcam is already mentioned in uvc_driver.c in the uvc_ids[] table.  Rather than just looking for this specific webcam in uvc_probe(), I've just added another quirk so that the code is a little more elegant.

Comment 6 Eric Ding 2012-07-06 05:08:30 UTC

Created attachment 74921 [details]
turn on USB_QUIRK_RESET_RESUME for Logitech Quickcam Fusion

This is a better patch, which just turns on USB_QUIRK_RESET_RESUME for this webcam.  This indirectly disables autosuspend for this webcam, incidentally matches the way that several other Logitech webcams are handled, and avoids adding a specific UVC_QUIRK for this problem.  

What's more, the camera now works even after a suspend/resume cycle.

Comment 7 Eric Ding 2012-07-06 07:01:46 UTC

In case you need it, by the way, I also add this comment:

Signed-off-by: Eric Ding <ericding <at> alum.mit.edu>

Comment 8 Alan 2012-07-06 10:28:22 UTC

I do indeed. Added and will push to Greg KH shortly

Comment 9 Eric Ding 2012-07-06 10:38:54 UTC

Thanks!!  Will this change make it into any of the stable releases, or just to 3.5.0 and later?

Comment 10 Alan 2012-07-06 10:42:02 UTC

3.6 certainly, if it scrapes 3.5 is GregKH's call. It does look a stable candidate.

Alan

Comment 11 Jonathan Nieder 2012-07-06 16:11:49 UTC

Reference: http://marc.info/?l=linux-usb&m=134157105131351&w=2