Bug 85881 - gpe66 interrupt keeps cpu continuously active
Summary: gpe66 interrupt keeps cpu continuously active
Status: CLOSED DUPLICATE of bug 53071
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Lv Zheng
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-08 13:05 UTC by andreanec
Modified: 2016-05-11 19:46 UTC (History)
22 users (show)

See Also:
Kernel Version: 3.17.0
Tree: Mainline
Regression: No


Attachments
acpidump>acpidump.out (250.13 KB, application/octet-stream)
2014-10-17 14:50 UTC, Phil Xiaojun Hu
Details
dmidecode>dmidecode.out (12.43 KB, application/octet-stream)
2014-10-17 14:51 UTC, Phil Xiaojun Hu
Details
MacBook Air mid-2013 acpidump (239.86 KB, application/octet-stream)
2014-10-20 08:22 UTC, Imre Kaloz
Details
MacBook Air mid-2013 dmidecode (12.31 KB, application/octet-stream)
2014-10-20 08:23 UTC, Imre Kaloz
Details
ACPIdump (249.69 KB, application/octet-stream)
2014-10-21 01:57 UTC, Darcy
Details
dmidecode (12.43 KB, application/octet-stream)
2014-10-21 01:58 UTC, Darcy
Details
acpidump (228.19 KB, text/plain)
2014-10-21 02:02 UTC, Eugene Cormier
Details
dmidecode (12.77 KB, text/plain)
2014-10-21 02:02 UTC, Eugene Cormier
Details
[DBG PATCH 1/5] ACPICA: Events: Reduce source code difference for the ACPI_EVENT_FLAG_HANDLE support. (6.16 KB, patch)
2014-10-22 02:09 UTC, Lv Zheng
Details | Diff
[DBG PATCH 2/5] ACPICA: Events: Reduce source code difference for the ACPI_EVENT_FLAG_HANDLE renaming. (4.30 KB, patch)
2014-10-22 02:10 UTC, Lv Zheng
Details | Diff
[DBG PATCH 3/5] ACPICA: Events: Introduce acpi_force_gpe() to fix an issue that the debugger cannot enable/disable GPE unconditionally. (15.96 KB, patch)
2014-10-22 02:12 UTC, Lv Zheng
Details | Diff
[DBG PATCH 4/5] ACPI: Update /sys/firmware/acpi/interrupts/gpexx using new GPE forced disabling/enabling mechanism. (4.58 KB, patch)
2014-10-22 02:15 UTC, Lv Zheng
Details | Diff
[DBG PATCH 5/5] ACPI: Add GPE quirks for recent apple devices. (2.54 KB, patch)
2014-10-22 02:23 UTC, Lv Zheng
Details | Diff
[DBG PATCH 4/5] ACPI: Update /sys/firmware/acpi/interrupts/gpexx using new GPE forced disabling/enabling mechanism. (4.58 KB, patch)
2014-10-23 02:21 UTC, Lv Zheng
Details | Diff
acpidump > acpidump.out on MBA6,2 (223.88 KB, application/octet-stream)
2014-11-07 21:02 UTC, Christian
Details
dmidecode > dmidecode.out on MBA6,2 (21.72 KB, application/octet-stream)
2014-11-07 21:02 UTC, Christian
Details
[PATCH] ACPICA: Events: Fix issue that GPE register modifications are not protected after _Lxx/_Exx evaluation. (1.27 KB, patch)
2014-11-12 06:34 UTC, Lv Zheng
Details | Diff
Macbook Pro ACPI Dump - Old Firmware (250.12 KB, application/octet-stream)
2014-12-17 11:38 UTC, Vishesh Handa
Details
signature.asc (820 bytes, application/pgp-signature)
2015-03-16 12:28 UTC, David Purton
Details
DSDT dump (27.03 KB, application/octet-stream)
2015-04-10 22:31 UTC, Fernando
Details
DSDT dump (disassembled) (249.52 KB, text/plain)
2015-04-10 22:34 UTC, Fernando
Details

Description andreanec 2014-10-08 13:05:48 UTC
I'm using a macbook pro late 2013, and after upgrading to OSX Yosemite Beta 4 I got an important battery life reduction with Linux: my cpu is always at 50-80% of utilization (and top says that is kworker that keeps it active).

I suspect this is due to a firmware update.
After a little investigation I found that the problem could be the gpe66 interrupt.

This is after about 10 seconds from boot:
# cat /sys/firmware/acpi/interrupts/gpe66 
22414625   enabled

and the temporal solution (which seems to solve the problem) is to disable it with:
# echo disable > /sys/firmware/acpi/interrupts/gpe66

is this a kernel bug or just a firmware problem?
Comment 1 Phil Xiaojun Hu 2014-10-11 08:02:10 UTC
I had the exact same problem.

I'm using a MacBook Pro mid 2014, which shares the same model number as yours. After upgrading to OS X Yosemite DM2, the kworker process throttles one of the cores.

And the gpe66 is the problem.

I tried to revert the kernel back to 3.16.1 but the problem still exists. So it seems to be a firmware problem with Yosemite.
Comment 2 andreanec 2014-10-11 09:23:12 UTC
Yesterday I upgraded to Yosemite beta 5, but the problem still persists.
Comment 3 Zhang Rui 2014-10-13 02:08:18 UTC
please attach the acpidump output.
Comment 4 Lv Zheng 2014-10-17 02:45:09 UTC
Is it a duplicates of this bug?
https://bugzilla.kernel.org/show_bug.cgi?id=53071

It seems we may need to provide a quirk mechanism to disable GPEs.
Please upload both the dmidecode and the acpidump outputs here.

Thanks
-Lv
Comment 5 Phil Xiaojun Hu 2014-10-17 14:50:44 UTC
Created attachment 154091 [details]
acpidump>acpidump.out
Comment 6 Phil Xiaojun Hu 2014-10-17 14:51:08 UTC
Created attachment 154101 [details]
dmidecode>dmidecode.out
Comment 7 Phil Xiaojun Hu 2014-10-17 14:54:30 UTC
Hi there,

I've just uploaded the dmidecode and acpidump outputs.

Please note that I'm running kernel 3.16.1.
Comment 8 Eugene Cormier 2014-10-18 17:40:28 UTC
I'm seeing this too since my update to the final release of Yosemite yesterday. echo disable > /sys/firmware/acpi/interrupts/gpe66 fixes it here too
Comment 9 Steven Gilberd 2014-10-19 03:10:54 UTC
I'm also seeing this since upgrading from Mavericks to the release version of Yosemite.

Macbook A1502 (late 2013 retina 13")
Gentoo kernel 3.14.14

No issues prior to the update. A firmware update for the laptop was bundled with the update.
Comment 10 Imre Kaloz 2014-10-20 08:21:53 UTC
Also affects MacBook Air 6,2 (mid-2013 model) after Yosemite's bundled firmware upgrade. I'm attaching acpidump and dmidecode outputs.
Comment 11 Imre Kaloz 2014-10-20 08:22:45 UTC
Created attachment 154241 [details]
MacBook Air mid-2013 acpidump
Comment 12 Imre Kaloz 2014-10-20 08:23:11 UTC
Created attachment 154251 [details]
MacBook Air mid-2013 dmidecode
Comment 13 Lv Zheng 2014-10-21 01:49:27 UTC
Phil Xiaojun Hu and Imre Kaloz:

OK.

I'll use the information to generate a quirk mechanism for you.
The quirk mechanism can be implemented using the patches attached here:
https://bugs.acpica.org/show_bug.cgi?id=1102
Please wait a while.

Any further acpidump/dmidecode files are welcome so that we can provide a more generic DMI matching entry.

Thanks
-Lv
Comment 14 Darcy 2014-10-21 01:57:50 UTC
Created attachment 154311 [details]
ACPIdump
Comment 15 Darcy 2014-10-21 01:58:25 UTC
Created attachment 154321 [details]
dmidecode
Comment 16 Eugene Cormier 2014-10-21 02:02:02 UTC
Created attachment 154331 [details]
acpidump
Comment 17 Eugene Cormier 2014-10-21 02:02:36 UTC
Created attachment 154341 [details]
dmidecode
Comment 18 Lv Zheng 2014-10-21 05:55:08 UTC
(In reply to Darcy from comment #15)
> Created attachment 154321 [details]
> dmidecode

This seems to be same as attachment 154101 [details].
Comment 19 Lv Zheng 2014-10-21 05:56:56 UTC
(In reply to Eugene Cormier from comment #17)
> Created attachment 154341 [details]
> dmidecode

This seems to be same as attachment 154251 [details].
Comment 20 Darcy 2014-10-21 05:57:50 UTC
(In reply to Lv Zheng from comment #18)
> (In reply to Darcy from comment #15)
> > Created attachment 154321 [details]
> > dmidecode
> 
> This seems to be same as attachment 154101 [details].

OK.  Thanks.
Comment 21 Lv Zheng 2014-10-22 02:07:21 UTC
The quirk patches are ready and tested.
They are generated on top of upstream linux.
So they include 2 pre-requisite non-upstreamed ACPICA release patches.
I'll upload them here after this comment.
You guys can continue to use the MacBooks using these patches.
And I'll continue to investigate if Linux can support the hardware that is sourcing the GPE 66.
Comment 22 Lv Zheng 2014-10-22 02:09:31 UTC
Created attachment 154491 [details]
[DBG PATCH 1/5] ACPICA: Events: Reduce source code difference for the ACPI_EVENT_FLAG_HANDLE support.

This is a non-upstreamed ACPICA release patch.
Comment 23 Lv Zheng 2014-10-22 02:10:36 UTC
Created attachment 154501 [details]
[DBG PATCH 2/5] ACPICA: Events: Reduce source code difference for the ACPI_EVENT_FLAG_HANDLE renaming.

Another non-upstreamed ACPICA release patch.
You can find them in the mainline kernel 1 or 2 months later.
Comment 24 Lv Zheng 2014-10-22 02:12:16 UTC
Created attachment 154511 [details]
[DBG PATCH 3/5] ACPICA: Events: Introduce acpi_force_gpe() to fix an issue that the debugger cannot enable/disable GPE unconditionally.

The ACPICA support to implement the quirk.
This patch's idea is accepted by the maintainers but its implementation is still under internal discussion.
So when it is upstreamed, it might be different from this version.
Comment 25 Lv Zheng 2014-10-22 02:15:00 UTC
Created attachment 154521 [details]
[DBG PATCH 4/5] ACPI: Update /sys/firmware/acpi/interrupts/gpexx using new GPE forced disabling/enabling mechanism.

The sysfs controlling interface of the quirk.
If you want to revert the quirk (when trying the support of this GPE).
You can type the following command:
 echo "unforce" > /sys/firmware/acpi/interrupts/gpe66
Comment 26 Lv Zheng 2014-10-22 02:23:39 UTC
Created attachment 154531 [details]
[DBG PATCH 5/5] ACPI: Add GPE quirks for recent apple devices.

The quirk.

After applying these patches, in the boot log, you should be able to see that the GPE 0x66 is forced to be disabled.
If not, the DMI matching entry might be wrong.
Please fix it in this patch according to the dmidecode output on your platform.

Thanks
Comment 27 Lv Zheng 2014-10-23 02:21:18 UTC
Created attachment 154571 [details]
[DBG PATCH 4/5] ACPI: Update /sys/firmware/acpi/interrupts/gpexx using new GPE forced disabling/enabling mechanism.

One of the patch contains a wrong line.
Please use this instead.
Comment 28 Christian 2014-11-07 21:00:52 UTC
I have the exact same issue: the Yosemite update on a Macbook Air 2013 triggers a storm on gpe66.

I also found out that this is somehow related to the i915 driver, because when I boot with

    modprobe.blacklist=i915

the issue does *not* appear. Can anyone else confirm this?
Comment 29 Christian 2014-11-07 21:02:10 UTC
Created attachment 156991 [details]
acpidump > acpidump.out on MBA6,2
Comment 30 Christian 2014-11-07 21:02:44 UTC
Created attachment 157001 [details]
dmidecode > dmidecode.out on MBA6,2
Comment 31 Lv Zheng 2014-11-12 06:27:33 UTC
The decompiled GPE 0x66 handler is as follows:
        Method (_L66, 0, NotSerialized)  // _Lxx: Level-Triggered GPE
        {
            If (LAnd (\_SB.PCI0.IGPU.GSSE, LNot (GSMI)))
            {
                \_SB.PCI0.IGPU.GSCI ()
            }
            Else
            {
                Store (0x00, \_SB.PCI0.IGPU.GEFC)
                Store (0x01, SCIS) /* \SCIS */
                Store (0x00, \_SB.PCI0.IGPU.GSSE)
                Store (0x00, \_SB.PCI0.IGPU.SCIE)
            }
        }
It's completely GPU related. So I have no idea what has happened.
The GSMI seems to be some configuration option in the BIOS:
    OperationRegion (GNVS, SystemMemory, 0x8CD3EA90, 0x026D)
    Field (GNVS, AnyAcc, Lock, Preserve)
    {
        GSMI,   8, 
    }
It sounds like something was originally handled by SMI and now is reported through GPE. So I guess there might be chances you could revert back to the original behavior using some BIOS configuration.

If someone could upload an acpidump before the upgrading, we might learn something from the DSDT difference.

Also we received a report from apple.com that there is an GPE issue in the current ACPICA code. Let me also post the fix later. You can also try it.
Comment 32 Lv Zheng 2014-11-12 06:34:12 UTC
Created attachment 157391 [details]
[PATCH] ACPICA: Events: Fix issue that GPE register modifications are not protected after _Lxx/_Exx evaluation.

The fix to a known bug.
I'm not sure if this relates to this bug. But you can try it.

Thanks
Comment 33 Lv Zheng 2014-11-12 06:35:00 UTC
As the GPE storming prevention quirk has been tested on bug 53071, marking this as duplicate.

*** This bug has been marked as a duplicate of bug 53071 ***
Comment 34 Christian 2014-11-12 17:42:17 UTC
(In reply to Lv Zheng from comment #31)
> The decompiled GPE 0x66 handler is as follows:
>         Method (_L66, 0, NotSerialized)  // _Lxx: Level-Triggered GPE
>         {
>             If (LAnd (\_SB.PCI0.IGPU.GSSE, LNot (GSMI)))
>             {
>                 \_SB.PCI0.IGPU.GSCI ()
>             }
>             Else
>             {
>                 Store (0x00, \_SB.PCI0.IGPU.GEFC)
>                 Store (0x01, SCIS) /* \SCIS */
>                 Store (0x00, \_SB.PCI0.IGPU.GSSE)
>                 Store (0x00, \_SB.PCI0.IGPU.SCIE)
>             }
>         }
> It's completely GPU related. So I have no idea what has happened.
> The GSMI seems to be some configuration option in the BIOS:
>     OperationRegion (GNVS, SystemMemory, 0x8CD3EA90, 0x026D)
>     Field (GNVS, AnyAcc, Lock, Preserve)
>     {
>         GSMI,   8, 
>     }
> It sounds like something was originally handled by SMI and now is reported
> through GPE. So I guess there might be chances you could revert back to the
> original behavior using some BIOS configuration.

Unfortunately there is no configuration on Macbooks. The EFI bootloader is able to choose between operating systems, but that's about it.
 
> If someone could upload an acpidump before the upgrading, we might learn
> something from the DSDT difference.

I posted such a request on the Debian user's list. Hopefully I will get a reply.

For reference, I also received the following reply on the intel-gfx mailing list (where I originally posted my issue as I thought it came from the i915):

http://lists.freedesktop.org/archives/intel-gfx/2014-November/054692.html
Comment 35 Christian 2014-11-12 17:42:44 UTC
(In reply to Lv Zheng from comment #32)
> Created attachment 157391 [details]
> [PATCH] ACPICA: Events: Fix issue that GPE register modifications are not
> protected after _Lxx/_Exx evaluation.
> 
> The fix to a known bug.
> I'm not sure if this relates to this bug. But you can try it.

I will try it out over the weekend.

Thanks!
Comment 36 Christian 2014-11-14 23:21:43 UTC
(In reply to Lv Zheng from comment #32)
> Created attachment 157391 [details]
> [PATCH] ACPICA: Events: Fix issue that GPE register modifications are not
> protected after _Lxx/_Exx evaluation.
> 
> The fix to a known bug.
> I'm not sure if this relates to this bug. But you can try it.

I just tested this with a 3.16.7 kernel and unfortunately this did not resolve the problem.
Comment 37 Vishesh Handa 2014-12-17 11:38:38 UTC
Created attachment 160971 [details]
Macbook Pro ACPI Dump - Old Firmware
Comment 38 Jose Xavier 2015-01-03 12:00:13 UTC
I have a MacBook Pro Mid-2014. I'm using kubuntu and kernel version 3.16.0-28-generic and has the gpe66 interrupt keeping the cpu1 active.

If there are any more information that I should give you just tell me.

PS: What is gpe66 and why can we disable it?
Comment 39 Lv Zheng 2015-01-04 03:24:32 UTC
(In reply to Jose Xavier from comment #38)
> I have a MacBook Pro Mid-2014. I'm using kubuntu and kernel version
> 3.16.0-28-generic and has the gpe66 interrupt keeping the cpu1 active.
> 
> If there are any more information that I should give you just tell me.
> PS: What is gpe66 and why can we disable it?

This GPE seems to be used by the graphics.

In ACPICA, there is an automatic GPE disabling mechanism:
If the level triggered GPE doesn't have _Lxx defined for it, ACPICA will disable it righter after it fires for the first time.
But GPE66 in this bug does have _L66 defined in the ACPICA namespace.
So ACPICA won't disable it.

It seems the _L66 doesn't handle this GPE correctly so it keeps on firing.

From ACPI subsystem's point of view, if we need a disabling quirk mechanism for this GPE in order to make the platform working, then we need the new quirk facility I've implemented it in attachment 154511 [details]/154571/154531.

Currently we are waiting. Because there are many GPE fixes pending.
We need to wait for them to appear in the upstream kernel or we'll have to ask reporters to apply dozens of fixes before applying the fix you need.
Otherwise, even the test results are not so persuasive because of other GPE bugs.

If you want to know what the GPE 66 is, you may file another bug to ask helps from graphics guys.

Thanks and best regards
-Lv
Comment 40 Rob 2015-02-05 17:36:30 UTC
Hi,

I believe that I am suffering from this bug.  I own a 2014 Macbook Pro, and run XUbuntu 14.04 LTS.  I loved my system until I installed the new Mac OS Yosimite and then reintalled XUbuntu.  Since then my CPU 1 is constantly running.

Since the update to Yosimite my main problem is that the battery life is reduced to less than half charge.  I used to get +7 hours charge, now I get less than 3.  This make my portable computer not very portable.

It appears that there is a solution to the problem.  I'm wondering when we might see these fixes released into the wild?

Cheers,
Rob
Comment 41 David Purton 2015-02-11 00:24:44 UTC
I just upgraded to OS X 10.10.2 and the problem seems to have been resolved. Perhaps there was another Firmware update? Can anyone else confirm?

$ cat /sys/firmware/acpi/interrupts/gpe66
       2   enabled

$ uname -a
Linux detritus 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux

I have an early 2014 Macbook Air model running Debian Jessie.
Comment 42 Eugene Cormier 2015-02-11 01:41:13 UTC
I can confirm that as well here after the last Mac firmware update

/sys/firmware/acpi/interrupts/gpe66 is showing enabled, yet cpu usage is 0% and no off the wall kworker usage

Gentoo stable here
Linux macair-13 3.17.8-gentoo-r1 #1 SMP Sat Jan 31 12:40:32 AST 2015 x86_64 Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz GenuineIntel GNU/Linux
Comment 43 Lv Zheng 2015-02-11 02:13:43 UTC
Hi,

(In reply to Rob from comment #40)
> Hi,
> 
> I believe that I am suffering from this bug.  I own a 2014 Macbook Pro, and
> run XUbuntu 14.04 LTS.  I loved my system until I installed the new Mac OS
> Yosimite and then reintalled XUbuntu.  Since then my CPU 1 is constantly
> running.
> 
> Since the update to Yosimite my main problem is that the battery life is
> reduced to less than half charge.  I used to get +7 hours charge, now I get
> less than 3.  This make my portable computer not very portable.
> 
> It appears that there is a solution to the problem.  I'm wondering when we
> might see these fixes released into the wild?

We only have a quirk mechanism to achieve so.
The quirk may appear in kernel in 3.23 after all the other GPE dependencies are merged.

This issue really need to be root caused by the firmware developer or graphics developer.

Thanks
-Lv
Comment 44 Lv Zheng 2015-02-11 02:15:14 UTC
(In reply to Eugene Cormier from comment #42)
> I can confirm that as well here after the last Mac firmware update
> 
> /sys/firmware/acpi/interrupts/gpe66 is showing enabled, yet cpu usage is 0%
> and no off the wall kworker usage
> 
> Gentoo stable here
> Linux macair-13 3.17.8-gentoo-r1 #1 SMP Sat Jan 31 12:40:32 AST 2015 x86_64
> Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz GenuineIntel GNU/Linux

OK. Let me mark it as a firmware bug and close it.
Don't worry about the quirk, I'll take care of discussing it with maintainers.
Comment 45 Christian 2015-02-11 07:18:43 UTC
(In reply to David Purton from comment #41)
> I just upgraded to OS X 10.10.2 and the problem seems to have been resolved.
> Perhaps there was another Firmware update? Can anyone else confirm?

Yes, I can confirm. This is great!

The Boot ROM Version was updated from MBA61.0099.B18 to MBA61.0099.B18. I don't think the SMC Version changed.
Comment 46 Christian 2015-02-11 07:19:30 UTC
(In reply to Christian from comment #45)
> The Boot ROM Version was updated from MBA61.0099.B18 to MBA61.0099.B18. I
> don't think the SMC Version changed.

I meant to say: from MBA61.0099.B16 to MBA61.0099.B18.
Comment 47 Rob 2015-02-13 02:31:46 UTC
I just finished upgrading to the newest version of Yosimite (OS X 10.10.2), and then reinstalled xubuntu 14.04 and voila, the problem is fixed for me too.  I'm running a Macbook Pro 11.
Comment 48 Fernando 2015-03-15 22:57:55 UTC
Are you all sure the problem is gone? I would say it has "moved":

I have just installed Linux for the first time on a OSX 10.10.2 MacBook (where the problem should be fixed according to your reports) and one CPU is still being used @80% by a kworker thread.

Only that this time the offending IRQ is GPE06 (instead of GPE66).
"echo disable > /sys/firmware/acpi/interrupts/gpe06" fixes the problem.
Comment 49 Christian 2015-03-15 23:03:22 UTC
(In reply to Fernando from comment #48)
> Are you all sure the problem is gone? I would say it has "moved":
> 
> I have just installed Linux for the first time on a OSX 10.10.2 MacBook
> (where the problem should be fixed according to your reports)

What type of MacBook is it?

AFAICT, it has been confirmed for the 13" MacBook Air (2013), 13" MacBook air (2014), and 11" MacBook Pro (year?)

> and one CPU is still being used @80% by a kworker thread.
> 
> Only that this time the offending IRQ is GPE06 (instead of GPE66).
> "echo disable > /sys/firmware/acpi/interrupts/gpe06" fixes the problem.

Nope, not seeing this here on my 13" MBA (2013).
Comment 50 Fernando 2015-03-15 23:11:08 UTC
This is a 15'' MacBook Pro 11,2 (late 2013, intel GPU).

Can any one with this same model confirm?
Comment 51 Imre Kaloz 2015-03-16 09:31:10 UTC
(In reply to Christian from comment #49)
> > Only that this time the offending IRQ is GPE06 (instead of GPE66).
> > "echo disable > /sys/firmware/acpi/interrupts/gpe06" fixes the problem.
> 
> Nope, not seeing this here on my 13" MBA (2013).

On the MBA 2013 gpe06 isn't there, but take a look at gpe4E...
Comment 52 David Purton 2015-03-16 12:28:16 UTC
Created attachment 170761 [details]
signature.asc

On Mon, Mar 16, 2015 at 09:31:10AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=85881
> 
> --- Comment #51 from Imre Kaloz <kaloz@openwrt.org> ---
> (In reply to Christian from comment #49)
> > > Only that this time the offending IRQ is GPE06 (instead of GPE66).
> > > "echo disable > /sys/firmware/acpi/interrupts/gpe06" fixes the problem.
> > 
> > Nope, not seeing this here on my 13" MBA (2013).
> 
> On the MBA 2013 gpe06 isn't there, but take a look at gpe4E...

gpe4E is high on my early 2014 11" MBA, however it doesn't seem to
affect cpu usage for me, so battery life is fine. Disabling this
interrupt does not seem to change anything for me.

David
Comment 53 Fernando 2015-03-17 22:41:21 UTC
I found someone else with the same problem as me (also with the same hardware: MackBook Pro 15, late 2013, hardware version 11,2).

The gpe06 storm is explained here: https://bugzilla.redhat.com/show_bug.cgi?id=1192856

It might be related to the orginal gpe66 problem.
Comment 54 Fernando 2015-04-10 22:26:30 UTC
Update: Apple has just (April 2015) released OSX 10.10.3 but it looks like the ACPI firmware has not been updated as "sudo cat /sys/firmware/acpi/tables/DSDT > data" produces the same output before and after the upgrade.

Because of this, gpe06 is still producing an IRQ storm (MBP 11,2 15'' late 2013), causing high CPU usage and thus low battery live.

I'll attach the dump in case someone finds it useful for something.
Comment 55 Fernando 2015-04-10 22:31:00 UTC
Created attachment 173741 [details]
DSDT dump

Result from executing this:
sudo cat /sys/firmware/acpi/tables/DSDT > MB_11.2_10.10.3.dat

...on a Macbook Pro 15'', hardware 11,2 (late 2013) after the upgrade to OSX 10.10.3.

NOTE: The file is identical to the one obtained while in OSX 10.10.2 (before the upgrade)
Comment 56 Fernando 2015-04-10 22:34:17 UTC
Created attachment 173751 [details]
DSDT dump (disassembled)

Result from executing this:
iasl -d MBP_11.2_10.10.3.dat

...on the previously attached file.
Included for convenience.
Comment 57 Gökçen Eraslan 2015-10-11 10:20:57 UTC
I'm experiencing same gpe06 issue with rMBP late 2013 and that is not the duplicate of bug #53071 as it's still not fixed on kernel 4.2.2.
Comment 58 Eduardo Silva 2016-05-11 15:10:40 UTC
This is not a duplicate of bug #53071.

In Linux 4.4 this is an active issue. My computer is a MacbookPro Retina late 2014.

When facing it the CPU goes 100%, not helping power consumption and harming overall performance. Please fix it.
Comment 59 Gökçen Eraslan 2016-05-11 19:46:12 UTC
I have filed another bug report about gpe06, fyi #105781.

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