|Summary:||Many Models of Logitech Webcams Stopped Working as of v3.5-rc1|
|Product:||v4l-dvb||Reporter:||Joseph Salisbury (joseph.salisbury)|
|Severity:||normal||CC:||bigbedue, brian, deminkirill, iq2luc, kernelorg, krellan, mchehab, migo, mike.parker, psychonaut, rotondi.simone, sellis, stephane.treboux|
Description Joseph Salisbury 2012-07-06 13:46:56 UTC
This is a regression from v3.4 final. Many models of Logitech webcams stopped working as starting in v3.5-rc1. I was able to reproduce this bug with a Logitec C250. It's going to be a little difficult to bisect since I ran into a USB bug that does allow any USB devices to work. The USB bug was fixed in v3.5-rc3, and I was able to reproduce the webcam bug in that kernel. So to recap testing: v3.4 does not have this bug. v3.5-rc1 has a separate USB bug preventing testing of the webcam. v3.5-rc2 has a separate USB bug preventing testing of the webcam. v3.5-rc3 the USB bug is fixed and the webcam bug is reproduced. v3.5 daily still has the webcam bug. There is also a bug opened on Launchpad against the Ubuntu distro. Hardware details and logs are available from there, or upon request.  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018020
Comment 1 Joseph Salisbury 2012-07-06 13:55:23 UTC
When trying to use the webcam, these messages are scrolled to syslog: [ 319.719296] uvcvideo: Failed to set UVC probe control : -71 (exp. 26). [ 319.723296] uvcvideo: Failed to set UVC probe control : -71 (exp. 26). [ 319.727436] uvcvideo: Failed to set UVC probe control : -71 (exp. 26).
Comment 2 Joseph Salisbury 2012-07-06 16:59:01 UTC
Message output from cheese when running v3.5-rc5: ** (cheese:2143): WARNING **: Device '/dev/video0' cannot capture at 640x480 ** (cheese:2143): WARNING **: Could not negotiate format
Comment 3 Joseph Salisbury 2012-07-06 22:05:11 UTC
I'm in the process of bisecting this now. I should have an update shortly.
Comment 4 Joseph Salisbury 2012-07-10 00:41:06 UTC
I've bisected down to the commit that is causing this bug: edcd3633e72a1590c4cf46befe5e6cd03b5aec3e - ALSA: snd-usb: switch over to new endpoint streaming logic However, the logic that caused this regression is in the following commit: 8fdff6a319e7dac757c558bd283dc4577e68cde7 - ALSA: snd-usb: implement new endpoint streaming model I attempted a simple revert, but it is not possible. The following commit is also involved: d399ff9593e088d33fb38f5206c6427825892baa - ALSA: snd-usb: remove old streaming logic This last commit just removes the obsolete unused code, which was causing a kernel compile error.
Comment 5 Mikhael Goikhman 2012-07-13 16:13:50 UTC
See also complaints about this bad regression from users of different Logitech webcams in bug 35922: https://bugzilla.kernel.org/show_bug.cgi?id=35922#c31
Comment 6 Joseph Salisbury 2012-07-13 17:45:56 UTC
For Ubuntu users, there is a test kernel available in a Launchpad bug. There is currently a fix for this being discussed on the alsa-devel mailing list. The fix should land in mainline soon.  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018020
Comment 7 kernelorg 2012-07-16 12:53:52 UTC
Linux 3.5-rc7, containing the fix, is released. Works for me! # uname -a Linux ROMAN-5720ZG 3.5.0-rc7-custom #2 SMP PREEMPT Mon Jul 16 16:39:59 MSK 2012 x86_64 GNU/Linux One error message is still there, but it doesn't seem to affect the webcam/microphone. # dmesg | grep ep [ 8.706829] 3:3:1: cannot set freq 16000 to ep 0x86
Comment 8 Simone Rotondi 2013-03-15 20:40:37 UTC
Hi , my webcam stop working properly again . With the webcam plugged in i can boot into the system just sometimes otherwise i get stuck after login and i gnome tell me something went wrong . #lsusb Bus 001 Device 006: ID 046d:081b Logitech, Inc. Webcam C310 #uname -a : Linux baltar 3.7.10-1-ARCH #1 SMP PREEMPT Thu Feb 28 09:50:17 CET 2013 x86_64 GNU/Linux #dmesg [ 6181.589567] usb 1-3: USB disconnect, device number 6 [ 6189.879130] usb 1-3: new high-speed USB device number 7 using ehci_hcd [ 6190.218371] uvcvideo: Found UVC 1.00 device <unnamed> (046d:081b) [ 6190.315629] input: UVC Camera (046d:081b) as /devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/input/input19 [ 6191.447066] 7:3:4: cannot set freq 48000 to ep 0x86 [ 6192.445704] 7:3:4: cannot set freq 48000 to ep 0x86 [ 6193.444339] 7:3:4: cannot set freq 48000 to ep 0x86 [ 6194.442981] 7:3:4: cannot set freq 48000 to ep 0x86 [ 6195.441744] 7:3:4: cannot set freq 48000 to ep 0x86 [ 6196.440381] 7:3:4: cannot set freq 48000 to ep 0x86 [ 6197.439014] 7:3:4: cannot set freq 48000 to ep 0x86 [ 6198.437659] 7:3:4: cannot set freq 48000 to ep 0x86
Comment 9 Michael Berg 2013-04-09 22:05:07 UTC
Same issue here with a Logitech webcam. System hangs on startup (after entering password in gdm to start gnome 3, but gdm startup is also terribly slow), printing the "cannot set freq" messages. Unplugging the webcam unlocks the system immediately. This does not appear on *every* boot, could not reproduce why or why not. # uname -a Linux snake 3.8.5-1-ARCH #1 SMP PREEMPT Fri Mar 29 19:18:14 CET 2013 x86_64 GNU/Linux # lsusb Device: Bus 001 Device 004: ID 046d:0825 Logitech, Inc. Webcam C270 (with -v): http://pastebin.com/5ZFCHwrk # dmesg |grep freq [ 3.536882] 3:3:2: cannot set freq 24000 to ep 0x86 [ 4.534103] 3:3:3: cannot set freq 32000 to ep 0x86 [ 5.531430] 3:3:4: cannot set freq 48000 to ep 0x86 [ 17.997410] 3:3:4: cannot set freq 48000 to ep 0x86 (...) [ 33.957226] 3:3:4: cannot set freq 48000 to ep 0x86 [ 34.954442] 3:3:4: cannot set freq 48000 to ep 0x86 (...and over 9000 more)
Comment 10 deminkirill 2013-06-05 20:00:45 UTC
Please reopen this bug. It's still present in 3.8
Comment 11 deminkirill 2013-06-06 11:52:59 UTC
Same bug on the Launchpad (marked as high): https://bugs.launchpad.net/ubuntu/+source/linux/+bug/884210 Workaround: rmmod -w snd-usb-audio modprobe snd-usb-audio It helps in 3.5 kernel always. But in 3.8 not always
Comment 12 Josh Lehan 2013-06-10 03:38:07 UTC
I can confirm this bug has reappeared, as another regression. I'm running 3.8.13 (Gentoo) and this bug just started happening. Almost exactly once per second: [ 703.568622] 3:3:1: cannot set freq 16000 to ep 0x86 [ 704.568285] 3:3:1: cannot set freq 16000 to ep 0x86 [ 705.567824] 3:3:1: cannot set freq 16000 to ep 0x86 [ 706.567485] 3:3:1: cannot set freq 16000 to ep 0x86 The desktop becomes unusable. It seems that many desktop applications, and the shell itself, are blocked on PulseAudio. PulseAudio is stuck in state "D": comatose. It's never a good sign when processes are in state "D".... I was earlier running 3.7.10 (Gentoo) and this bug didn't happen at all back then. Workaround is to hit Control-Alt-F1 to escape your unusable desktop, go to your text shell, start removing modules until you get rid of the offending sound driver, then hopefully that will snap PulseAudio out of its funk. Then, you can return to your desktop, and although it will be silent, you can use it again.
Comment 13 Brian J. Murrell 2015-09-27 17:10:19 UTC
This bug is back. I am seeing it in the 4.1.7-200.fc22.x86_64 kernel on Fedora 22. Camera is a Logitech Quickcam Pro 5000.
Comment 14 Mike Parker 2015-12-31 17:41:33 UTC
Bug confirmed as present in 4.1.13-100.fc21.i686 on Fedora 21. Camera is Logitech C310 Bus 001 Device 002: ID 046d:081b Logitech, Inc. Webcam C310
Comment 15 Steven Ellis 2016-01-04 03:51:14 UTC
Ditto look like issue is still present on Fedora 23 with 4.2.8-300.fc23.x86_64
Comment 16 Tristan Miller 2017-11-23 19:32:33 UTC
I believe I'm being affected by this bug. Audio recorded by my Logitech C270 is often artificially high-pitched, like a Chipmunk. Reproducible for me with kernel-default-4.13.12-1.1.x86_64 on openSUSE Tumbleweed.
Comment 17 Tristan Miller 2020-07-10 14:39:07 UTC
Still reproducible for me with a Logitech C270 and kernel-default-5.2.14-1.2.x86_64 on openSUSE Tumbleweed. Since this bug was marked as fixed some seven or eight years ago, there have been ten reports here of a regression. Could someone with the necessary permissions please reopen this issue?
Comment 19 Luc 2020-11-23 10:40:57 UTC
Still happening with my Logitech C310 (046d:081b) on 5.9.9. When the issue is happening, a recording with "arecord -d3 test.wav" takes about 11 seconds instead of 3 and playing back the recorded file gives the high-pitched / chipmunk sound mentioned above. [ 4496.787827] usb 1-6: new high-speed USB device number 19 using ehci-pci [ 4497.153865] usb 1-6: New USB device found, idVendor=046d, idProduct=081b, bcdDevice= 0.10 [ 4497.153867] usb 1-6: New USB device strings: Mfr=0, Product=0, SerialNumber=2 [ 4497.153869] usb 1-6: SerialNumber: 3E029A10 [ 4497.154168] uvcvideo: Found UVC 1.00 device <unnamed> (046d:081b) [ 4497.273552] input: UVC Camera (046d:081b) as /devices/pci0000:00/0000:00:1a.7/usb1/1-6/1-6:1.0/input/input46 [ 4498.436241] usb 1-6: set resolution quirk: cval->res = 384 Disconnecting or reconnecting the device (sometimes several times) or resetting the usb device fixes the issue eventually.
Comment 20 Tristan Miller 2021-07-11 07:57:32 UTC
Still reproducible for me with a Logitech C270 and kernel-default-5.13.0-1.2.x86_64 on openSUSE Tumbleweed. A thread on the Microsoft support forum at https://answers.microsoft.com/en-us/insider/forum/insider_apps-insider_video/logitech-c270-audio-problem/f3cca299-5b3d-42ff-8471-b77520f1a9f4?auth=1 shows that Windows users are also affected, so this is probably a bug in the webcam hardware/firmware itself. Still, it would be nice if there were some kernel-level workaround.