[Asus X750LN] High ACPI event count causing ~12% non-stop CPU utilization

[Nikola Nikolov]

This started as soon as I installed Ubuntu when I bought my laptop, about 3 months ago. Due to other bugs with the kernel that Ubuntu uses, I switched to the latest mainline kernel available and that resolved the issue for me. At the time, this was 3.16.3-031603.201409171435_amd64 . Ubuntu(14.10) itself is using 3.16.0-28-generic at the moment.

For only 16 minutes of uptime, cat /sys/firmware/acpi/interrupts/gpe_all yields this:
50867044

Which is over 50 million interrupts. To illustrate the rate at which those events are fired, I ran this command:
cat /sys/firmware/acpi/interrupts/gpe_all && sleep 10 && cat /sys/firmware/acpi/interrupts/gpe_all and the result was:
58397255
58916975

A little over half a million interrupts in 10 seconds.

Again - this doesn't happen in the 3.17 kernel. At this point, I'm not sure whether this is a regression or if the fix hasn't gotten to Ubuntu yet.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-image-3.16.0-28-generic 3.16.0-28.38
ProcVersionSignature: Ubuntu 3.16.0-28.38-generic 3.16.7-ckt1
Uname: Linux 3.16.0-28-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
Date: Wed Dec 31 15:48:51 2014
HibernationDevice: RESUME=UUID=7b341f94-cd2e-461a-8b9b-38d1161c43a6
InstallationDate: Installed on 2014-09-21 (101 days ago)
InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2)
MachineType: ASUSTeK COMPUTER INC. X750LN
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-28-generic root=UUID=7f1fe8aa-bbe8-435d-979a-261f0331631e ro quiet splash i8042.noloop=1 psmouse.proto=bare acpi_osi= vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-28-generic N/A
 linux-backports-modules-3.16.0-28-generic N/A
 linux-firmware 1.138
SourcePackage: linux
StagingDrivers: keucr
UpgradeStatus: Upgraded to utopic on 2014-11-05 (55 days ago)
dmi.bios.date: 02/19/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 201
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: X750LN
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr201:bd02/19/2014:svnASUSTeKCOMPUTERINC.:pnX750LN:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX750LN:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: X750LN
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Nikola Nikolov, thank you for reporting this and helping make Ubuntu better. The next step is to fully reverse commit bisect from kernel 3.16 to 3.17 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

[Nikola Nikolov (nikolov-tmw)]

Hello Christopher,

I've started reverse commit bisecting the kernel and it seems like I'm on the right track(I already had instances of the bug being present and being fixed). It does take me a rather significant amount of time(well, I've read it can be worse, since it takes me about an hour - hour and a half to build the kernel from source), but I'm hoping to identify the first good commit over the weekend.

I'm just letting you know that I've started working on it and that I'm not going to disappear on the bug :)

Nikola

[Nikola Nikolov (nikolov-tmw)]

Hi Christopher,

git bisect found the first good commit, here's the full output from the last command:

bd9b2f9aff26c185c1f8e0cd08a850ee4ace391a is the first bad commit
commit bd9b2f9aff26c185c1f8e0cd08a850ee4ace391a
Author: Rafael J. Wysocki <email address hidden>
Date: Mon Jul 14 22:41:41 2014 +0200

    ACPI / scan: No implicit wake notification for buttons

    The ACPI device enumeration code in Linux assumes that buttons always
    are wakeup devices, so it calls acpi_setup_gpe_for_wake() for them
    which leads to undesirable side effects. Namely, that function sets
    up implicit device wake notification mechanism for a given GPE if
    there is no handler method in the ACPI namespace, which from the
    ACPICA's perspective means that there always is a way to handle
    that GPE if enabled. However, we don't handle wake notify events
    for buttons, so if there are no handler methods for their GPEs in
    the namespace, enabling a button GPE at run time leads to a GPE
    storm in some cases (the GPE triggers, ACPICA carries out the
    implicit wake notification for it which isn't handled, so the
    GPE triggers again and so on).

    To prevent that from happening use acpi_mark_gpe_for_wake()
    instead of acpi_setup_gpe_for_wake() for buttons which will cause
    ACPICA to only enable button GPEs if there are handler methods for
    the in the namespace.

    Signed-off-by: Rafael J. Wysocki <email address hidden>

:040000 040000 fec6e6222f6b0f58a5106035c38c7091a48eef0c f6c36ad741c62668891689c8229c3703146dc92e M drivers

Let me know if there's anything else I need to do,
Nikola

[Joseph Salisbury (jsalisbury)]

Commit bd9b2f9 is in the mainline tree as of 3.17-rc1. It required that I first cherry-pick commit c12f07d.

I built a Utopic kernel with a cherry-pick of bd9b2f9. It can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1406767/

Can you test this kernel and see if it resolves this bug?

Thanks in advance!

[Nikola Nikolov (nikolov-tmw)]

Hi Joseph,

Thank you for your work! I just tested your kernel and the bug is gone!

Let me know if there's anything else I can do.

[Joseph Salisbury (jsalisbury)]

I submitted a request to have commits bd9b2f9 and c12f07d included in upstream 3.16.y-ckt