Created attachment 107731 [details]
dmesg output from 2.6.37

Created attachment 107741 [details]
dmesg output from 2.6.38

Created attachment 107751 [details]
dmesg output from 3.10

Created attachment 107761 [details]
contents of /proc/interrupts on 2.6.37

Created attachment 107771 [details]
contents of /proc/interrupts on 2.6.38

Created attachment 107781 [details]
contents of /proc/interrupts on 3.10

Hi James,

Thanks for the report. Do I understand correctly that the problem of high CPU usage begin to occur on v2.6.38 but the problem of many gpe18 occur only on v3.1 and later? Thanks.

No, gpe18 is still increasing rapidly on v2.6.38, just not as quickly (maybe half the rate). When I installed Debian (unstable) on the laptop, v3.1 was the kernel in unstable then, which was where I found the bug first (and why the Debian bug report mentions v3.1). Sorry for the confusion. Thanks.

Please provide the output of "grep . /sys/firmware/acpi/interrupts/*".

BTW, does "echo disabled > /sys/firmware/acpi/interrupts/gpe18" stop gpe?

Created attachment 107971 [details]
output of "grep . /sys/firmware/acpi/interrupts/*"

"echo disabled > /sys/firmware/acpi/interrupts/gpe18" appears to reset the count, but gpe18 is still shown as enabled.

O(In reply to James Tocknell from comment #11)
> "echo disabled > /sys/firmware/acpi/interrupts/gpe18" appears to reset the
> count, but gpe18 is still shown as enabled.

Ok. Please provide the dmesg after disabing gpe18.

Sorry. A mistake. Please try "echo disable > /sys/firmare/acpi/interrupts/gpe18" again.

On both 2.6.38 and 3.10 (the latest version in Debian unstable), running "echo disable > /sys/firmare/acpi/interrupts/gpe18" twice seems to fix the problem, but only calling disable once appears to do nothing (gpe18 is still enabled), unless it takes more than about 30 seconds to disable.

From the DSDT table, GP18 is LID wakeup gpe and so you can "echo LID > /proc/acpi/wakeup" to disable GPE18. But no idea why it rises so much and this seems a hardware or Bios issue.

Device (LID)
{
     Name (_HID, EisaId ("PNP0C0D"))  // _HID: Hardware ID
     Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
     {
        0x18,
        0x03
     })
     ...
}

Could you try to do system suspend/resume and check whether the issue will be fixed?

ping...
can you please do the test in comment #15 and #16?

Created attachment 110921 [details]
Samsung NP550P5C ACPI dump

Binary ACPI dump of Samsung NP550P5C which has a similar problem described in http://marc.info/?l=linux-acpi&m=138170536231873&w=2

I found a workaround for my problem. Enabling the "USB S3 Wake-Up" BIOS option seems to fix this problem. I had it turned off since I bought the machine, but I guess something was introduced in 3.9 that triggers the issue. Judging from the amount of ACPI related issues on Samsung laptops, a true solution for the problem would be to never install Linux on them.

Agustin,
I'm not sure if they are the same problem or not.
will you please file a new bug report and attach the acpidump output when both "USB S3 Wake-up" BIOS option are set and cleared?

Jame,
comment #19 may be a clue, can you please check your BIOS options and see if there is some thing with wakeup related and check if changing the option helps?

As per Zhang Rui's suggestion, a new bug was filed [0]. I apologize for the confusion.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=63021

Sorry for the slow response.

On both the 2.6.38 and 3.10 kernels I found that "echo LID > /proc/acpi/wakeup" didn't disable gpe18 (according to /sys/firmare/acpi/interrupts/gpe18), but did disable LID in /proc/acpi/wakeup (both were enabled before running "echo LID > /proc/acpi/wakeup"). Suspending via pm-suspend (which worked) with LID enabled or disabled had no effect.

In the BIOS, I have only 4 options (besides system date/time and boot order), Legacy USB suport (toggle), SATA mode (AHCI/IDE), Power Beep (toggle, description says "A special beep as alarm for external power supply changes.") and Intel Virtual Technology (toggle). I found that toggling Legacy USB suport had no effect. I haven't tested the other settings.

Hello.
I have a Lenovo y560p too. There are lags on system general. For example, while watching a video you see small freezes. Or while scrolling down a webpage you see theese freezes. Adding noapic or nolapic on grub fixing the freezing issue but high cpu usage persists.

@James Tocknell did you noticed these freezes?

I am going to add some info here: http://pastebin.com/CEBiTGeF

I'm not sure. I haven't noticed small freeze in videos, but that may be because I don't watch that many videos. I may have noticed scrolling can stutter, but I had put that down to setting sensitivity to the wrong level.

Can you share your lspci output? Do we have same hardware?

Output of lspci -v: http://dpaste.com/hold/1508817/

Only difference is network controller. You have: Intel Corporation Centrino Wireless-N 1000. I have: Qualcomm Atheros AR9285 Wireless Network Adapter.

The freezes are system general but you can see it easily while watching a video.

Using a kernel > v2.6: There are freezes. Adding noapic on grub fixing the freezing issue. CPU usage problem persists.

Using a kernel <= v2.6: No freezes and no strange cpu usage.

One other noticeable thing is this machine(y560p) doesn't have 2 graphics cards.

After some googling found other people with y560p had same issue. So I think this is not a hardware failure that only I have. Also factory installed Windows 7 don't have any issue. I am able to test anything to solve this issue with Linux Kernel.

Judging by the ACPI dump, perhaps the patch that was proposed on another issue [1] might be worth trying.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=63021

Compiled with that patch. Does not fix our problem.
After running "echo disable > /sys/firmware/acpi/interrupts/gpe18" twice, CPU usage returns normal.

Can anyone contact Lenovo? I have opened a topic on Lenovo forum but no response: http://forums.lenovo.com/t5/Linux-Discussion/y560p-BIOS-Bug/td-p/1483406

(In reply to Muhammed YILDIRIM from comment #30)
> Compiled with that patch. Does not fix our problem.
> After running "echo disable > /sys/firmware/acpi/interrupts/gpe18" twice,
> CPU usage returns normal.

first, I'm wondering why we need to run the command twice to make it work.
Second, please run "echo clear > /sys/firmware/acpi/interrupts/gpe18", and then "echo enable > /sys/firmware/acpi/interrupts/gpe18", does the storm come back again?

(In reply to Zhang Rui from comment #32)
> first, I'm wondering why we need to run the command twice to make it work.
> Second, please run "echo clear > /sys/firmware/acpi/interrupts/gpe18", and
> then "echo enable > /sys/firmware/acpi/interrupts/gpe18", does the storm
> come back again?

Yes it comes back.

(In reply to Zhang Rui from comment #32)
> (In reply to Muhammed YILDIRIM from comment #30)
> > Compiled with that patch. Does not fix our problem.
> > After running "echo disable > /sys/firmware/acpi/interrupts/gpe18" twice,
> > CPU usage returns normal.
> 
> first, I'm wondering why we need to run the command twice to make it work.
> Second, 

This have been resolved in the latest upstream kernel.

Hi Muhammed:
     Could you try the following patch? Test system suspend and check whether this patch will affect the wakeup via LID on your machine. Thanks.

diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c
index 1638401..3d1c9d6 100644
--- a/drivers/acpi/wakeup.c
+++ b/drivers/acpi/wakeup.c
@@ -87,8 +87,8 @@ int __init acpi_wakeup_device_init(void)
                                                       wakeup_list);
                if (device_can_wakeup(&dev->dev)) {
                        /* Button GPEs are supposed to be always enabled. */
-                       acpi_enable_gpe(dev->wakeup.gpe_device,
-                                       dev->wakeup.gpe_number);
+//                     acpi_enable_gpe(dev->wakeup.gpe_device,
+//                                     dev->wakeup.gpe_number);
                        device_set_wakeup_enable(&dev->dev, true);
                }
        }

Created attachment 141701 [details]
gpe.patch

Please ignore the previous one and try this patch.

ping...

Hi,

In acpi_ev_dispatch_gpe(), if a GPE doesn't have a handler/method to run, acpi_hw_low_set_gpe() is invoked and the acpi_ev_finish_gpe() isn't, thus it will be automatically disabled.
So this bug means this facility is not working on your platform?

Thanks

I think it does, but acpi_ev_asynch_execute_gpe_method() is executed
due to ACPI_GPE_DISPATCH_NOTIFY.

I wonder if we need to install a notify handler for all wakeup GPEs, then.

[Of course, the problem is a missing GPE method on the Lenovo machine
in question, but we need a workaround.]

The Tianyu's patch from comment #36 is worth trying still, so someone
who can reproduce the problem please give it a go.

(In reply to Rafael J. Wysocki from comment #39)
> [Of course, the problem is a missing GPE method on the Lenovo machine
> in question, but we need a workaround.]

Hi Rafael:
         This is not a special case and I check some machines' dsdt. They also don't have GPE method for LID wakeup GPE.

E,G acpidump from bug 72641 and bug 77431
    https://bugzilla.kernel.org/attachment.cgi?id=139061
    https://bugzilla.kernel.org/attachment.cgi?id=132091&action=edit

Yes, the problem is in our code.  We call acpi_setup_gpe_for_wake()
for buttons just because they are buttons even though there's no _PRW.

Created attachment 142581 [details]
ACPI / scan: Simplify wakeup GPE initialization for buttons

This patch should help too if I'm not mistaken, so if someone with a reproducer can test it, please do so.

The following patches will disable the GPE and they have been merged into Linux-PM tree.

http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=bd9b2f9aff26c185c1f8e0cd08a850ee4ace391a

http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=c12f07d17c12193256a99e20c9a0f130fb8f7be8

http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=bleeding-edge&id=b9ca3d7b513a9824dc97d5dc7c4eb9e30ab776b5