Bug 1126767 - V4L (/dev/video0 internal webcam) users stuck in the D state
Summary: V4L (/dev/video0 internal webcam) users stuck in the D state
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-05 08:50 UTC by Jan "Yenya" Kasprzak
Modified: 2014-11-14 11:53 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-11-14 11:53:38 UTC

Attachments (Terms of Use)

Description Jan "Yenya" Kasprzak 2014-08-05 08:50:02 UTC
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):

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:
Bus 001 Device 003: ID 04f2:b059 Chicony Electronics Co., Ltd CKF7037 HP webcam

[   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
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
 = 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 ..

Comment 1 Justin M. Forbes 2014-11-13 15:58:48 UTC
*********** 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.

Comment 2 Jan "Yenya" Kasprzak 2014-11-14 11:53:38 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.