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[0] against the Ubuntu distro. Hardware details and logs are available from there, or upon request. [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018020
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).
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
I'm in the process of bisecting this now. I should have an update shortly.
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.
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
For Ubuntu users, there is a test kernel available in a Launchpad bug[0]. There is currently a fix for this being discussed on the alsa-devel mailing list. The fix should land in mainline soon. [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1018020
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
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
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)
Please reopen this bug. It's still present in 3.8
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
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.
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.
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
Ditto look like issue is still present on Fedora 23 with 4.2.8-300.fc23.x86_64
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.
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?
Possible duplicate: Bug 203763
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.
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.
Duplicate: Bug 105081