It constantly consumes 70% of one of my cores and around 20% of my total processor. Issue was resolved when I downgraded to an earlier version of the kernel that I had installed (version 3.11.10-301). I don't know if I filled the fields right, I emitated this bug: https://bugzilla.kernel.org/show_bug.cgi?id=20232 my hardware: macbook pro 11,1 (late 2013). x86-64 processor.
I experienced the same issue on the kernel 3.13.10-200.fc20.x86_64 and later versions as well. now I am using the kernel 3.12.5-302.fc20.x86_64 and the issue is gone. I don't know on which version exactly did the issue start to appear but I hope I helped narrowing the search.
Sounds like a GPE problem. Please show me the result of: $ grep . /sys/firmware/acpi/interrupts/* with both kernels. Please also attach acpidump: # acpidump > acpidump.txt
BTW, is it that the problem starts to occur from v3.13? And does the latest v3.17 also have this problem?
Created attachment 159651 [details] grep . /sys/firmware/acpi/interrupts/* kernel 3.17
Created attachment 159661 [details] grep . /sys/firmware/acpi/interrupts/* kernel 3.12.5
Created attachment 159671 [details] acpidump for kernel 3.17
Created attachment 159681 [details] acpidump for kernel 3.12.5
thanks for the reply yes kernel version 3.17 does have the bug and yes I believe the bug starts to appear starting from v3.13 but the one I'm running now doesn't have the bug (3.12.5)
Quite similar to bug #85881. Since this is a regression, can you please git bisect the offending commit? Thanks.
Does that require me to git clone the kernel and run git bisect over the commits between 3.12.9 and 3.13 and build, install and test each commit until I find the offending commit? or is there a better way (hopefully)?
Yes, you will need to clone the kernel tree and bisect between v3.12 and v3.13. The bisect is a binary search process, so it's not every commit, but still, requires some time to do. A better way would be analyzing the problem and find out solution but it doesn't seem we are able to find out the here.
Hi (In reply to Adham Zahran from comment #10) > Does that require me to git clone the kernel and run git bisect over the > commits between 3.12.9 and 3.13 and build, install and test each commit > until I find the offending commit? or is there a better way (hopefully)? This GPE seems to be related to the GPU. During the 3.12-rc5 and 3.13, there is no commit related to ACPI GPE merged (maybe I'm wrong). And from ACPI susbystem's point of view, there is _L66 prepared in the ACPI namespace, thus ACPI core won't stop enabling the GPE (which leads to the work queue item) unless it is quirked (in bug 85881, it is quirked). Thus this issue might be related to the GPU. Since you have reported this as a regression, you probably can help developers to address the culprit component related to this regression. Thanks and best regards -Lv
Adham, can you please kindly do git bisect to find out the offending commit? As you have successfully narrow down the problem to between 3.12 and 3.13, I think git bisect will take much less time.
Zhang Rui... I tried to go through the git bisect process earlier today but something really weird happened. I had this command in /etc/rc.d/rc.local to be executed automatically on startup: echo disable > /sys/firmware/acpi/interrupts/gpe66 it worked fine as a work around for our bug. but I had to remove it so that I can test the kernel, but when I removed it the computer worked fine! kworker is no longer eating up my processor even without disabling gpe66 I even tried older kernels and it's the same. do you know if fedora could be executing that command somewhere else behind my back or what's happening here?
now I ran cat /sys/firmware/acpi/interrupts/gpe66 and it returned: 2 enabled so yeah it wasn't disabled but suddenly the bug isn't occurring on any version of the kernel... I don't know if that is a good thing or a bad thing. what do?
It seems a firmware upgrade can fix this bug. Please refer to Bug 85881. If you don't have the buggy firmware to test, it should be impossible for you to bisect the culprit...