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?
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.
Yesterday I upgraded to Yosemite beta 5, but the problem still persists.
please attach the acpidump output.
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
Created attachment 154091 [details] acpidump>acpidump.out
Created attachment 154101 [details] dmidecode>dmidecode.out
Hi there, I've just uploaded the dmidecode and acpidump outputs. Please note that I'm running kernel 3.16.1.
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
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.
Also affects MacBook Air 6,2 (mid-2013 model) after Yosemite's bundled firmware upgrade. I'm attaching acpidump and dmidecode outputs.
Created attachment 154241 [details] MacBook Air mid-2013 acpidump
Created attachment 154251 [details] MacBook Air mid-2013 dmidecode
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
Created attachment 154311 [details] ACPIdump
Created attachment 154321 [details] dmidecode
Created attachment 154331 [details] acpidump
Created attachment 154341 [details] dmidecode
(In reply to Darcy from comment #15) > Created attachment 154321 [details] > dmidecode This seems to be same as attachment 154101 [details].
(In reply to Eugene Cormier from comment #17) > Created attachment 154341 [details] > dmidecode This seems to be same as attachment 154251 [details].
(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.
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.
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.
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.
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.
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
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
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.
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?
Created attachment 156991 [details] acpidump > acpidump.out on MBA6,2
Created attachment 157001 [details] dmidecode > dmidecode.out on MBA6,2
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.
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
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 ***
(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
(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!
(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.
Created attachment 160971 [details] Macbook Pro ACPI Dump - Old Firmware
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?
(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
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
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.
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
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
(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.
(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.
(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.
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.
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.
(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).
This is a 15'' MacBook Pro 11,2 (late 2013, intel GPU). Can any one with this same model confirm?
(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...
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
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.
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.
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)
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.
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.
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.
I have filed another bug report about gpe06, fyi #105781.