Created attachment 573763 [details] <lsusb -v -d 2232:1020> command output Description of problem: After the kernel has been updated to <3.3.0-4.fc16.i686.PAE> a web-camera using isn't possible, because OS freezes at the moment when some application is trying to open </dev/video0>. ___________________________________ Version-Release number of selected component (if applicable): kernel-PAE-3.3.0-4.fc16.i686 ___________________________________ How reproducible: always ___________________________________ Steps to Reproduce: <$ vlc v4l2://> (also it is shown with MPlayer & other applications using </dev/video0>) ___________________________________ Actual results: OS is not responding. The <$ ping> command, launched from the other machine to the first one, says "Destination Host Unreachable". ___________________________________ Expected results: The VLC player shows the picture from web-camera. OS works fine. ___________________________________ Additional info: I've done the next steps to work around this problem: I've extracted the <uvcvideo> module source (uvc_ctrl.c/uvc_driver.c/uvc_entity.c/uvc_isight.c/uvc_queue.c/uvc_status.c/uvc_v4l2.c/uvc_video.c/uvcvideo.h) from the <kernel-3.2.10-3.fc16.src.rpm> package and compiled the module with this <Makefile>: ___________________________________ obj-m := uvcvideo.o uvcvideo-objs := uvc_driver.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_ctrl.o \ uvc_status.o uvc_isight.o uvc_entity.o KERNELDIR ?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KERNELDIR) M=$(PWD) clean: rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c rm -f Module.markers Module.symvers modules.order rm -rf .tmp_versions Modules.symvers ___________________________________ Then I've put <uvcvideo.ko> to the </lib/modules/$(uname -r)/kernel/drivers/media/video/uvc/> directory and run <# depmod -a>. Now the <uvcvideo> module does not cause the OS freezing.
I have the same issue with kernel version 3.3.0-8.fc16.i686.PAE and the workaround solves the problem. Camera device ID is 090c:3717.
This trouble exists with kernel 3.3.1-3.fc16.i686.PAE too.
I am seeing this in kernel-PAE-3.3.1-5.fc16.i686 with camera device id 13d3:5126. webcam unusable since the move to 3.3.
This trouble exists with kernel 3.3.2-1.fc16.i686.PAE too.
Per http://sourceforge.net/mailarchive/message.php?msg_id=29124514 $ sudo -c 'echo options uvcvideo nodrop=1 >> /etc/modprobe.d/uvcvideo.conf && rmmod uvcvideo && modprobe uvcvideo' For my kernel, 3.3.2-1.fc16.i686.PAE, this effectively works around the crash on my machine (ASUS EEE PC 1201N).
Very good, options uvcvideo nodrop=1 fixes the crash on Thinkpad T60, using 3.3.2-1.fc16.i686
Well! I've done: $ su -c 'echo "options uvcvideo nodrop=1" > /etc/modprobe.d/uvcvideo.conf' This works fine for my Samsung RV5-s0l! Now there is no need to recompile the module <uvcvideo.ko> from the kernel 3.2 source code.
(In reply to comment #7) > Well! I've done: > $ su -c 'echo "options uvcvideo nodrop=1" > /etc/modprobe.d/uvcvideo.conf' > This works fine for my Samsung RV5-s0l! > Now there is no need to recompile the module <uvcvideo.ko> from the kernel 3.2 > source code. * Samsung RV520-s0l // Fixed
I no longer reproduce the bug as of kernel-PAE-3.3.2-6.fc16.i686.
uvcvideo nodrop=1 still needed here running kernel-3.3.2-6.fc16.i686 to avaoid hard freeze. PAE should'nt be make the difference. Thinkpad T60.
Then I probe first launch of the camera - camera displays normally. The second and subsequent launch - in fog and haze. That's is? In fedora 16 it's works fine. Web cam USB 1.1 connected to USB 3 port. Sea privious bug in Fedora 16. https://bugzilla.redhat.com/show_bug.cgi?id=755323 But in Fedora 17 reboot after next use web cam? Reconnect camera to USB port? and again...and again? ---- cat reset.c #include <stdio.h> #include <fcntl.h> #include <errno.h> #include <sys/ioctl.h> #include <linux/usbdevice_fs.h> ///home/nargis/reset /dev/bus/usb/003/002 void main(int argc, char **argv) { const char *filename; int fd; printf ("/home/nargis/reset /dev/bus/usb/003/002"); filename = argv[1]; fd = open(filename, O_WRONLY); ioctl(fd, USBDEVFS_RESET, 0); close(fd); return; } -- Compile this and run with parameters #./reset /dev/bus/usb/003/002 I "reconnect" web cam programs. But it's not good!!(
(In reply to comment #11) > Then I probe first launch of the camera - camera displays normally. > > The second and subsequent launch - in fog and haze. > > That's is? In fedora 16 it's works fine. Web cam USB 1.1 connected to USB 3 > port. > Sea privious bug in Fedora 16. > https://bugzilla.redhat.com/show_bug.cgi?id=755323 > > But in Fedora 17 reboot after next use web cam? Reconnect camera to USB > port? and again...and again? It's not this bug.
Hello, this is 100% reproducible for me. I can reproduce it with "vlc v4l2://". Sometimes I need to run the command only once, sometimes 5 times or more. Sooner or later a hard-freeze happens and nothing responds, not even magic-SysRq keys (I have them enabled). No backtrace on screen, no backtrace in the logs. I remember having those freezes after 3.3.0 at fc16, so I always kept a 3.2 kernel for working. Now that I preupgraded to fc17, 3.4.3 seems to manifest the same bug as well. Webcam is a laptop-embedded Lenovo EasyCamera (according to lsusb -v). Graphics is Intel embedded GM45 (Xorg.0.log) modeset via the i915 module (lspci -v). Please let me know how to get some useful debug info so we can fix it. Thanks.
OK I managed to reproduce it in console mode using "mplayer -vo null tv:///dev/video0" several times. A backtrace was shown part of which is caught on the first attached file. Even though the system was completely locked-up, pressing the power button produced another backtrace which was repeating with a period of about 30s. This is shown on 2nd attached file. Kernel is 3.4.3-1.fc17.PAE.
Created attachment 593618 [details] first backtrace
Created attachment 593619 [details] second backtrace, after pressing power button, repeating every 30s
I am having the same problem on a Thinkpad T60p with an external HP USB Webcam. Running cheese completely locks the system up, requiring a power cycle to recover. There is no visible output from either cheese or on the system log. This is under 3.4.3-1.fc17.i686 and cheese 3.4.2 (current from updates-testing). What information can I gather that would help solve this problem?
@Peter: Did you try Brad Rubenstein's fix? (Comment #5 for this bug). It solves the problem on my Lenovo Z560 with 3.4.2-4.fc17.i686.PAE.
The workaround in comment #5 gets past the lock-up. However, cheese still doesn't work very well with the camera. Skype also has problems. I guess I'll have to dig deeper and try to find out whether these problems are with the applications or with the kernel/driver.
We can add another camera to the list. The integrated camera on Asus EeePC 1005PE, vendor 13d3 product 5111 IMC Networks fails as described above. I can also confirm that the "nodrop" workaround fixes the problem on my current kernel, 3.4.6-2.fc17.x86_64. Earlier I submitted a report to the kernel bugzilla regarding this problem. See bug 45031.
From the <kernel> package changelog: > * Thu Jul 26 2012 Josh Boyer <jwboyer> > - kernel: recv{from,msg}() on an rds socket can leak kernel > memory (rhbz 820039 843554) > - Apply patch to fix uvcvideo crash (rhbz 836742) http://koji.fedoraproject.org/koji/buildinfo?buildID=344289 http://koji.fedoraproject.org/koji/buildinfo?buildID=344324 I have installed <kernel-PAE-3.5.0-1.fc17.i686> and now <options uvcvideo nodrop=1> parameter is no more necessary. It must work with <kernel> packages >= 3.4.6-4[.fc17]. Does anybody know whether this <uvcvideo> patch sent to upstream?
(In reply to comment #21) > From the <kernel> package changelog: > > * Thu Jul 26 2012 Josh Boyer <jwboyer> > > - kernel: recv{from,msg}() on an rds socket can leak kernel > > memory (rhbz 820039 843554) > > - Apply patch to fix uvcvideo crash (rhbz 836742) > > http://koji.fedoraproject.org/koji/buildinfo?buildID=344289 > http://koji.fedoraproject.org/koji/buildinfo?buildID=344324 > > I have installed <kernel-PAE-3.5.0-1.fc17.i686> and now <options uvcvideo > nodrop=1> parameter is no more necessary. It must work with <kernel> > packages >= 3.4.6-4[.fc17]. > > Does anybody know whether this <uvcvideo> patch sent to upstream? It was, yes. Thank you for letting us know the problem is resolved.
Thank you too.