100% cpu usage with 4.8 kernel after upgrade to 16.10

[mscdex]

After upgrading my Sony Vaio Pro 13 to Lubuntu 16.10 and logging in for the first time, I noticed the fans were spinning crazy fast. Since nothing was open and I hadn't done anything since the upgrade yet, I looked at top. There it showed systemd-journal and rsyslog using 100% CPU.

I looked at /var/log/syslog and there was a flood of messaging continually being appended of the form:

   ACPI Error: no handler or method for gpe ... disabling event ...

The system was still somewhat usable, so I tried checking for updates, but there wasn't anything to update. Since I never encountered this error before, I tried installing a mainline kernel (4.9) from the Ubuntu mainline kernel PPA. I booted into the new, mainline kernel and no more 100% CPU usage. The only problem with using this kernel is that I can't use VirtualBox anymore because dkms has a compilation issue when building against the 4.9 kernel.

Before upgrading to 16.10, I was using Lubuntu 16.04 with whatever the latest 4.4 kernel was at the time that 16.10 was released, which also worked just fine.

The current (as of this writing) 4.8 kernel that is still causing problems is 4.8.0-32.
---
ApportVersion: 2.20.3-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: mscdex 1812 F.... pulseaudio
 /dev/snd/controlC1: mscdex 1812 F.... pulseaudio
CurrentDesktop: LXDE
DistroRelease: Ubuntu 16.10
InstallationDate: Installed on 2013-12-07 (1119 days ago)
InstallationMedia: Lubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016)
MachineType: Sony Corporation SVP13213CXB
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-32-generic root=UUID=97c33b42-d845-488d-9a1f-d62e03702b16 ro quiet splash libata.force=noncq acpi_backlight=vendor vt.handoff=7
ProcVersionSignature: Ubuntu 4.8.0-32.34-generic 4.8.11
RelatedPackageVersions:
 linux-restricted-modules-4.8.0-32-generic N/A
 linux-backports-modules-4.8.0-32-generic N/A
 linux-firmware 1.161.1
Tags: yakkety
Uname: Linux 4.8.0-32-generic x86_64
UpgradeStatus: Upgraded to yakkety on 2016-12-17 (14 days ago)
UserGroups: adm audio cdrom dip lpadmin netdev plugdev sambashare sudo vboxusers wireshark
_MarkForUpload: True
dmi.bios.date: 11/05/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: R1041V7
dmi.board.asset.tag: N/A
dmi.board.name: VAIO
dmi.board.vendor: Sony Corporation
dmi.board.version: N/A
dmi.chassis.asset.tag: N/A
dmi.chassis.type: 10
dmi.chassis.vendor: Sony Corporation
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrR1041V7:bd11/05/2013:svnSonyCorporation:pnSVP13213CXB:pvrC60C2CVE:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A:
dmi.product.name: SVP13213CXB
dmi.product.version: C60C2CVE
dmi.sys.vendor: Sony Corporation

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1653327/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1653327

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[mscdex (mscdex)]

apport information

[penalvch (penalvch)]

mscdex, thank you for reporting this and helping make Ubuntu better.

In order to allow additional upstream developers to examine the issue, at your earliest convenience, could you please test the latest upstream kernel available from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D ? Please keep in mind the following:
1) The one to test is at the very top line at the top of the page (not the daily folder).
2) The release names are irrelevant.
3) The folder time stamps aren't indicative of when the kernel actually was released upstream.
4) Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds .

If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.

If the latest kernel 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 issue 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 X, and Y are the first two numbers of the kernel version, and Z is the release candidate number if it exists.

If the mainline kernel does not fix the issue, 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.

Also, you don't need to apport-collect further unless specifically requested to do so.

It is most helpful that after testing of the latest upstream kernel is complete, you mark this report Status Confirmed.

Lastly, to keep this issue relevant to upstream, please continue to test the latest mainline kernel as it becomes available.

Thank you for your help.

[penalvch (penalvch)]

mscdex, to see if this is already resolved in Ubuntu, could you please test http://cdimage.ubuntu.com/daily-live/current/ and advise to the results?

[mscdex (mscdex)]

Since 17.04 uses the 4.9 kernel, yes, it does indeed work. I did boot the daily live iso anyway and as expected, it works fine.

[penalvch (penalvch)]

mscdex, would you need a backport to a release prior to 17.04? If not, feel free to mark this report Status Invalid.

[mscdex (mscdex)]

Christopher, a backport to 16.10 would be much appreciated so I can have a usable setup (while waiting for 17.04) and be a happy and productive developer again.

[penalvch (penalvch)]

mscdex, the next step is to fully reverse commit bisect from kernel 4.8 to 4.9 in order to identify the last bad commit, followed immediately by the first good one. Once this good commit has been identified, it may be reviewed for backporting. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions, or providing a commit from a kernel version bisect is not fully commit bisecting.

Also, the kernel release names are irrelevant for the purposes of bisecting.

It is most helpful that after the fix commit (not kernel version) has been identified, you then mark this report Status Confirmed.

Thank you for your help.

[mscdex (mscdex)]

Alright, so I noticed that 4.9-rc1 is still good, so I did a reverse commit bisect between 4.8 and r.9-rc1. Here was the final result:

2a5708409e4e05446eb1a89ecb48641d6fd5d5a9 is the first bad commit
commit 2a5708409e4e05446eb1a89ecb48641d6fd5d5a9
Author: Lv Zheng <email address hidden>
Date: Wed Sep 7 16:50:21 2016 +0800

    ACPI / EC: Fix a gap that ECDT EC cannot handle EC events

    It is possible to register _Qxx from namespace and use the ECDT EC to
    perform event handling. The reported bug reveals that Windows is using ECDT
    in this way in case the namespace EC is not present. This patch facilitates
    Linux to support ECDT in this way.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021
    Reported-and-tested-by: Luya Tshimbalanga <email address hidden>
    Tested-by: Jonh Henderson <email address hidden>
    Reviewed-by: Peter Wu <email address hidden>
    Signed-off-by: Lv Zheng <email address hidden>
    Signed-off-by: Rafael J. Wysocki <email address hidden>

The parent of that commit (which I am assuming is the "good commit") is:

commit 46922d2a3aff5122253d97e64500801c08f4f2c0
Author: Lv Zheng <email address hidden>
Date: Wed Sep 7 16:50:14 2016 +0800

    ACPI / EC: Fix a memory leakage issue in acpi_ec_add()

    When the handler installation failed, there was no code to free the
    allocated EC device. This patch fixes this memory leakage issue.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021
    Reported-and-tested-by: Luya Tshimbalanga <email address hidden>
    Tested-by: Jonh Henderson <email address hidden>
    Signed-off-by: Lv Zheng <email address hidden>
    Signed-off-by: Rafael J. Wysocki <email address hidden>

Let me know if you need anything else.

[mscdex (mscdex)]

Perhaps I misspoke in my last comment. I'm guessing that since the bisect was reversed that the "first bad commit" is actually the first good commit?

[penalvch (penalvch)]

mscdex, to clarify, did you actually test the good commit?

If not, the bisect isn't complete unless you tested it to confirm the results.