Description of problem: After a recent kernel upgrade, I am unable to use an internal webcam in my laptop HP 6730b: usually the first user of /dev/video0 works OK (I am testing with cheese now), but after I close it, the subsequent users of /dev/video0 are getting stuck in the D state (I am not able to kill them, etc.). It worked OK a month ago, and the problem appeared after the recent yum update (most probably the update of kernel). Version-Release number of selected component (if applicable): kernel-3.15.7-200.fc20.x86_64 cheese-3.10.2-1.fc20.x86_64 How reproducible: 100 % Steps to Reproduce: 1. reboot the system, log in 2. run cheese (it displays the video from the internal webcam), close it 3. run cheese again Actual results: The second cheese process is stuck in the "D" state. Expected results: The second cheese should work the same way as the first one. Additional info: lsusb: Bus 001 Device 003: ID 04f2:b059 Chicony Electronics Co., Ltd CKF7037 HP webcam dmesg: [ 31.087494] Linux video capture interface: v2.00 [ 31.507255] uvcvideo: Found UVC 1.00 device CKF7037 (04f2:b059) [ 31.523703] input: CKF7037 as /devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5:1.0/input/input15 [ 31.523792] usbcore: registered new interface driver uvcvideo [ 31.523794] USB Video Class driver (1.1.1) strace -f -o /tmp/strace cheese: [...] 16130 open("/usr/lib64/libv4l/plugins/libv4l-mplane.so", O_RDONLY|O_CLOEXEC) = 1 7 16130 read(17, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\10\0\0\0\0\0\0". .., 832) = 832 16130 fstat(17, {st_mode=S_IFREG|0755, st_size=11104, ...}) = 0 16130 mmap(NULL, 2105448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 17, 0) = 0x7f9d54c42000 16130 mprotect(0x7f9d54c44000, 2093056, PROT_NONE) = 0 16130 mmap(0x7f9d54e43000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP _DENYWRITE, 17, 0x1000) = 0x7f9d54e43000 16130 close(17) = 0 16130 mprotect(0x7f9d54e43000, 4096, PROT_READ) = 0 16130 ioctl(16, VIDIOC_QUERYCAP or VT_OPENQRY, 0x7fff26c9c820) = 0 16130 munmap(0x7f9d54c42000, 2105448) = 0 16130 ioctl(16, VIDIOC_QUERYCAP or VT_OPENQRY, 0x7fff26c9c990) = 0 16130 ioctl(16, VIDIOC_G_FMT or VIDIOC_SUBDEV_G_FMT or VT_SENDSIG <unfinished .. .>
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
I have tested it, and with the latest kernel, 3.17.2-200.fc20, the problem is not present anymore. Closing the bug with CURRENTRELEASE.