webcam indicator LED remains lit after resume from suspend

[Hans109h]

After resuming from suspend the webcam indicator light remains on, however the webcam is not on. Opening Cheese and closing Cheese results in the indicator light turning off.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: linux-image-3.19.0-18-generic 3.19.0-18.18
ProcVersionSignature: Ubuntu 3.19.0-18.18-generic 3.19.6
Uname: Linux 3.19.0-18-generic x86_64
ApportVersion: 2.17.2-0ubuntu1.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: hans109h 1278 F.... pulseaudio
CurrentDesktop: GNOME
Date: Sat May 30 10:34:29 2015
HibernationDevice: RESUME=UUID=851878e8-669f-4a9d-806a-0b4ba86a929a
InstallationDate: Installed on 2015-04-29 (31 days ago)
InstallationMedia: Ubuntu-GNOME 15.04 "Vivid Vervet" - Release amd64 (20150422)
MachineType: ASUSTeK Computer Inc. K60IJ
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-18-generic root=UUID=c5445ede-5f15-457d-8605-193f57ad6688 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.19.0-18-generic N/A
 linux-backports-modules-3.19.0-18-generic N/A
 linux-firmware 1.143.1
SourcePackage: linux
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/03/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 206
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: K60IJ
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: ATN12345678901234567
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr206:bd12/03/2009:svnASUSTeKComputerInc.:pnK60IJ:pvr1.0:rvnASUSTeKComputerInc.:rnK60IJ:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: K60IJ
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Hans109h, thank you for reporting this and helping make Ubuntu better. Could you please test the latest upstream kernel available from the very top line at the top of the page (the release names are irrelevant for testing, and please do not test the daily folder) following https://wiki.ubuntu.com/Kernel/MainlineBuilds ? It will allow additional upstream developers to examine the issue.

If the test did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where XY and Z are numbers corresponding to the kernel version.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

[Hans109h (hans109h)]

Bug not present upstream in mainline kernel v4.1-rc5.

[penalvch (penalvch)]

Hans109h, the next step is to fully reverse commit bisect from kernel 3.19 to 4.1-rc5 in order to identify the last bad commit, followed immediately by the first good one. Once this commit has been identified, then it may be reviewed as a candidate for backporting into your release. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Hans109h (hans109h)]

I have found the adjacent kernel versions and have begun the commit bisecting, however I have run into some problems.

First, I have found the adjacent kernel versions to be v4.0-rc1 (good) and v3.19.8 (bad) and I did:

git checkout v4.0-rc1
git bisect start
git bisect good v3.19.8

however v.3.19.8 is not available so I reran the command with:

git bisect good v.3.19-rc7

3.19-rc7 was the next previous version I could find, so I proceeded with:

git bisect bad v4.13-rc5

and then built the kernel. After the kernel built I installed it and loaded it, however as a result, using that kernel my computer would not suspend simply by shutting the lid.

I had to use 'sudo pm-suspend' which appeared to suspend the machine but I could not get the computer to wake up after that without a hard reboot.

I then rebooted and reported the test results as 'git bisect good' and then started to build the kernel. The result of this build was the same as the first. I also reported that with 'git bisect good'. Currently I am building the kernel for the third time.

Should I continue with this method of testing?

[Hans109h (hans109h)]

"git bisect bad v4.13-rc5" above should read "git bisect bad v4.1-rc1"

[Hans109h (hans109h)]

I mean "v4.0-rc1"

[Hans109h (hans109h)]

ce1d3fde87d1a21f1ec1147dde32b2825dd3a276 is the first bad commit