My kernel isn't getting enough sleep. It is really tired, and getting quite cranky from being woken up all the time. If that damned schedule wakes him up one more time, I'm afraid that the kernel is going to go postal on my machine and I'll wind up with a smoking pile of plastic. 57.2% (427.6) [kernel scheduler] Load balancing tick 9.0% ( 67.2) [iwlagn] <interrupt> That's what power top says. 2.6.35.4-28.fc14.x86_64
It looks like we'd need to apply these commits: linux-2.6.git-fdf3e95d3916f18bf8703fb065499fdbc4dfe34c.patch linux-2.6.git-83cd4fe27ad8446619b2e030b171b858501de87d.patch linux-2.6.git-5343bdb8fd076f16edc9d113a9e35e2a1d1f4966.patch linux-2.6.git-861d034ee814917a83bd5de4b26e3b8336ddeeb8.patch linux-2.6.git-da2b71edd8a7db44fe1746261410a981f3e03632.patch Some of them are pretty big. Hopefully we can get these into -stable and not have to worry about carrying them.
I put the patches in 2.6.35.5-29, building now.
I still get this: $ sudo powertop ... Top causes for wakeups: 76.1% (783.9) [kernel scheduler] Load balancing tick 5.9% ( 60.4) [uhci_hcd:usb5, i915, yenta] <interrupt> with: $ uname -sr Linux 2.6.35.5-29.fc14.x86_64 Gene
(In reply to comment #3) > I still get this: > > $ sudo powertop > ... > Top causes for wakeups: > 76.1% (783.9) [kernel scheduler] Load balancing tick > 5.9% ( 60.4) [uhci_hcd:usb5, i915, yenta] <interrupt> Is that on a completely idle system? Others have reported on IRC that the numbers have dropped way down.
On a completely idle system (one gnome terminal running sudo powertop), I see: Top causes for wakeups: 70.7% (302.3) [kernel scheduler] Load balancing tick 10.4% ( 44.4) [uhci_hcd:usb5, i915, yenta] <interrupt> 4.3% ( 18.3) [iwlagn] <interrupt> 2.7% ( 11.7) awn-applet Memory says that's still high? Gene
With the 2.6.35.6-rc1 kernel I get: 29.9% ( 11.6) [kernel core] hrtimer_start (tick_sched_timer) 25.8% ( 10.0) [kernel core] __mod_timer (ehci_watchdog) 12.9% ( 5.0) [pata_amd] <interrupt> 7.2% ( 2.8) [Rescheduling interrupts] <kernel IPI> 6.4% ( 2.5) [kernel scheduler] Load balancing tick 3.4% ( 1.3) [eth0] <interrupt>
With: $ uname -sr Linux 2.6.35.6-34.fc14.x86_64 I still see: Top causes for wakeups: 49.4% (115.7) [kernel scheduler] Load balancing tick 17.6% ( 41.3) [uhci_hcd:usb5, i915, yenta] <interrupt> 6.1% ( 14.2) [iwlagn] <interrupt> 5.2% ( 12.1) awn-applet 3.5% ( 8.3) [kernel core] hrtimer_start (tick_sched_timer) This is better than I saw in Comment 5, but not nearly as low as you see in Comment 6. Do you think I can improve this? Thanks, Gene
I'm seeing a load of about 1.2, 94% idle, and about 150-400 Load balancing ticks/s with 2.6.35.6-43.fc14.i686.PAE on a system I'm using.
Possible upstream bug
With nohz=off, my load can get to 0.00 on an idle system (despite load balancing ticks of 1000/s - obviously :).
I'm seeing the same thing w/ 2.6.35.6-43.fc14.x86_64 http://poelstra.fedorapeople.org/paste-bin/f14-load.png http://poelstra.fedorapeople.org/paste-bin/f14-load.ogg
Also discussed here: http://lists.fedoraproject.org/pipermail/test/2010-October/094683.html
Hardware is Dell XPS M1330.
This is trashing the battery life on my ThinkPad X301: # powertop Power usage (ACPI estimate): 20.1W (0.7 hours) Top causes for wakeups: 62.9% (1380.5) [kernel scheduler] Load balancing tick 17.3% (379.8) PS/2 keyboard/mouse/touchpad interrupt 10.1% (221.0) chrome Is there anything being done about this?
I can confirm the problem with this CPU: Intel(R) Core(TM) i7 CPU L620 @ 2.00GHz I could reproduce the mentioned behaviour with the follwing kernel: 2.6.36.1-7.rc1.fc15.x86_64 (Load >2.0 !!! when idle) 2.6.35.9-62.fc14.x86_64 (Load <1.0 when idle) 2.6.35.6-48.fc14.x86_64 (Load <1.0 when idle) All kernels above result in a shortened battery time and higher fan speeds Problem does not exist with: kernel-2.6.34.7-62.fc13.x86_64.rpm (Load around 0.0)
http://kyle.fedorapeople.org/kernel/2.6.35.9-62.bz635813.fc14/x86_64/ Try this build, please?
Looks mich better for me: bash-4.1$ cat /proc/loadavg 0.08 0.13 0.09 1/285 5631
No change for me, one CPU on my laptop is stuck at ~100% CPU usage in kacpid.
There's two bugs being conflated here.
The 'load average is really high bug is https://bugzilla.redhat.com/show_bug.cgi?id=650934 The large amount of wakeups folks can stay on this one. The people seeing excessive wakeups, can you test either 2.6.36 from rawhide, or 2.6.37-rc3 from http://repos.fedorapeople.org/repos/kyle/kernel/fedora-kernel.repo and let us know if either of those help alleviate it? --Kyle
It's a little bit better with 2.6.36.1-7.rc1.fc15.x86_64 but I wouldn't call it solved: 50.5% (1786.3) [acpi] <interrupt> 28.0% (989.2) [kernel scheduler] Load balancing tick
Huh, acpi, eh... Can you watch /sys/firmware/acpi/interrupts/gpe_all and if its rising quickly at runtime figure out which gpe_ is causing all those interrupts. I wonder if this and #645968 may be symptoms of the same issue.
I just tested 2.6.37-0.rc3.git6.2.fc15.x86_64 powertop: 23,3% ( 55,1) kworker/0:1 16,4% ( 38,7) kworker/0:0 15,5% ( 36,7) [kernel scheduler] Load balancing tick 11,8% ( 27,9) [iwlagn] <interrupt> 5,5% ( 13,1) firefox bash-4.1$ cat /proc/loadavg 2.01 1.38 0.60 1/303 4722 /sys/firmware/acpi/interrupts/gpe_all raises every 15seconds for about +15 I couldn't figure out the responsible gpe_ . If I do cat /sys/firmware/acpi/interrupts/* all other gpe_ are 0
(In reply to comment #22) > Huh, acpi, eh... > > Can you watch /sys/firmware/acpi/interrupts/gpe_all and if its rising quickly > at runtime figure out which gpe_ is causing all those interrupts. I wonder if > this and #645968 may be symptoms of the same issue. gpe01 definitely: [jcollie@lt27416 ~]$ cat /sys/firmware/acpi/interrupts/gpe01 7778602 enabled [jcollie@lt27416 ~]$ cat /sys/firmware/acpi/interrupts/gpe_all 7802594 All of the othe gpe* files are 0 except for one which is 131.
I'm also following this issue as it is happening on my Dell E6400. I tried the latest 2.6.37 kernel but that didn't help. I also tried turning off NO_HZ and that helped a bit but not much. I'm now running an old kernel 2.6.32 and I'm still seeing abnormally high "wakeups from idle" and cursor slowdowns at random times. I'm running out of things to try...
Hi, can you try, as Matthew suggested in #638912, booting with pcie_ports=compat and letting us know if you still have the issue? Thanks! Kyle
In reply to Comment 22: [gene@Mobile-PC ~]$ uname -sr Linux 2.6.35.9-65.fc14.x86_64 [gene@Mobile-PC ~]$ grep . /sys/firmware/acpi/interrupts/gpe[10]* /sys/firmware/acpi/interrupts/gpe00: 0 invalid /sys/firmware/acpi/interrupts/gpe01: 0 enabled /sys/firmware/acpi/interrupts/gpe02: 341 enabled /sys/firmware/acpi/interrupts/gpe03: 0 disabled /sys/firmware/acpi/interrupts/gpe04: 0 disabled /sys/firmware/acpi/interrupts/gpe05: 0 disabled /sys/firmware/acpi/interrupts/gpe06: 0 invalid /sys/firmware/acpi/interrupts/gpe07: 0 invalid /sys/firmware/acpi/interrupts/gpe08: 0 disabled /sys/firmware/acpi/interrupts/gpe09: 0 disabled /sys/firmware/acpi/interrupts/gpe0A: 0 invalid /sys/firmware/acpi/interrupts/gpe0B: 0 disabled /sys/firmware/acpi/interrupts/gpe0C: 0 disabled /sys/firmware/acpi/interrupts/gpe0D: 0 disabled /sys/firmware/acpi/interrupts/gpe0E: 0 enabled /sys/firmware/acpi/interrupts/gpe0F: 0 invalid /sys/firmware/acpi/interrupts/gpe10: 0 invalid /sys/firmware/acpi/interrupts/gpe11: 0 invalid /sys/firmware/acpi/interrupts/gpe12: 0 invalid /sys/firmware/acpi/interrupts/gpe13: 0 invalid /sys/firmware/acpi/interrupts/gpe14: 0 invalid /sys/firmware/acpi/interrupts/gpe15: 0 invalid /sys/firmware/acpi/interrupts/gpe16: 0 invalid /sys/firmware/acpi/interrupts/gpe17: 0 invalid /sys/firmware/acpi/interrupts/gpe18: 0 invalid /sys/firmware/acpi/interrupts/gpe19: 20552 enabled /sys/firmware/acpi/interrupts/gpe1A: 0 invalid /sys/firmware/acpi/interrupts/gpe1B: 0 invalid /sys/firmware/acpi/interrupts/gpe1C: 0 invalid /sys/firmware/acpi/interrupts/gpe1D: 0 enabled /sys/firmware/acpi/interrupts/gpe1E: 0 invalid /sys/firmware/acpi/interrupts/gpe1F: 0 invalid I hope this helps. Gene
I missed the subdirectories in my Comment 27. Here's the complete list for the same kernel: [gene@Mobile-PC ~]$ grep . -r /sys/firmware/acpi/interrupts /sys/firmware/acpi/interrupts/gpe00: 0 invalid /sys/firmware/acpi/interrupts/gpe01: 0 enabled /sys/firmware/acpi/interrupts/gpe02: 376 enabled /sys/firmware/acpi/interrupts/gpe03: 0 disabled /sys/firmware/acpi/interrupts/gpe04: 0 disabled /sys/firmware/acpi/interrupts/gpe05: 0 disabled /sys/firmware/acpi/interrupts/gpe06: 0 invalid /sys/firmware/acpi/interrupts/gpe07: 0 invalid /sys/firmware/acpi/interrupts/gpe08: 0 disabled /sys/firmware/acpi/interrupts/gpe09: 0 disabled /sys/firmware/acpi/interrupts/gpe0A: 0 invalid /sys/firmware/acpi/interrupts/gpe0B: 0 disabled /sys/firmware/acpi/interrupts/gpe0C: 0 disabled /sys/firmware/acpi/interrupts/gpe0D: 0 disabled /sys/firmware/acpi/interrupts/gpe0E: 0 enabled /sys/firmware/acpi/interrupts/gpe0F: 0 invalid /sys/firmware/acpi/interrupts/gpe10: 0 invalid /sys/firmware/acpi/interrupts/gpe11: 0 invalid /sys/firmware/acpi/interrupts/gpe12: 0 invalid /sys/firmware/acpi/interrupts/gpe13: 0 invalid /sys/firmware/acpi/interrupts/gpe14: 0 invalid /sys/firmware/acpi/interrupts/gpe15: 0 invalid /sys/firmware/acpi/interrupts/gpe16: 0 invalid /sys/firmware/acpi/interrupts/gpe17: 0 invalid /sys/firmware/acpi/interrupts/gpe18: 0 invalid /sys/firmware/acpi/interrupts/gpe19: 22673 enabled /sys/firmware/acpi/interrupts/gpe1A: 0 invalid /sys/firmware/acpi/interrupts/gpe1B: 0 invalid /sys/firmware/acpi/interrupts/gpe1C: 0 invalid /sys/firmware/acpi/interrupts/gpe1D: 0 enabled /sys/firmware/acpi/interrupts/gpe1E: 0 invalid /sys/firmware/acpi/interrupts/gpe1F: 0 invalid /sys/firmware/acpi/interrupts/ff_pmtimer: 0 invalid /sys/firmware/acpi/interrupts/ff_gbl_lock: 0 enabled /sys/firmware/acpi/interrupts/ff_pwr_btn: 0 enabled /sys/firmware/acpi/interrupts/ff_slp_btn: 0 invalid /sys/firmware/acpi/interrupts/ff_rt_clk: 0 disabled /sys/firmware/acpi/interrupts/gpe_all: 23049 /sys/firmware/acpi/interrupts/sci: 23049 /sys/firmware/acpi/interrupts/sci_not: 1 /sys/firmware/acpi/interrupts/error: 0 Gene
Here are my powertop outputs for the latest 2.6.35 and 2.6.37 kernels on an idle system: $ uname -sr Linux 2.6.35.9-65.fc14.x86_64 Top causes for wakeups: 48.4% (135.0) [kernel scheduler] Load balancing tick 15.4% ( 42.8) [uhci_hcd:usb5, i915, yenta] <interrupt> 4.8% ( 13.3) awn-applet 4.2% ( 11.7) [iwlagn] <interrupt> $ uname -sr Linux 2.6.37-0.rc5.git2.1.fc15.x86_64 Top causes for wakeups: 33.1% (137.4) [kernel scheduler] Load balancing tick 31.5% (131.1) kworker/0:0 10.6% ( 43.9) [uhci_hcd:usb5, i915, yenta] <interrupt> 4.4% ( 18.3) [uhci_hcd:usb4, mmc0, tifm_7xx1] <interrupt> 4.4% ( 18.2) USB device 4-1 : USB RECEIVER (Logitech) 3.2% ( 13.4) [iwlagn] <interrupt> 3.0% ( 12.4) awn-applet Notice that the 2.6.37 kernel has about the same number of wakeups for load balancing as the 2.6.25 kernel. It also has the additional wakeups for kworker. Gene
Hi, I'm just wondering how can this be a low priority, medium severity issue... I'm unable to use my laptop (Dell Latitude 630c) for several weeks (I actually lost the count) since this bug came out!!! The funniest thing is that I gave up dual boot a few months ago, and now I'm stuck with an unusable OS. Since I'm very resilient in moving away from Fedora, and by the progress I can see in this matter, I guess I'll be using the laptop again when the hardware is completely obsolete. Is this only happening in a very restricted hardware type or what? Sorry guys, but I'm really frustrated!!! Jhonny
Totally agree with Jhonny, new Lenovo G560 - overheating often leads to shut down, not to mention overall performance compared to older kernel. Really sad that is low priority/severity. Richard
Jhonny spoke what I am thinking. However, I just found out this morning that people do not get hit equally by this bug. At home I have a HP nw9440 running Fedora 14 (i686) and its getting at least 80% of all wake ups due to the load balancing tick. Last Friday I got a new laptop at work (Dell Latitude E6410) and I installed F14 (x86_64) and its only doing 25-35% wake ups for the load balancing tick. The nw9440 is a great laptop, I love the screen (1920x1200) but I can barely use it. Simple things like right clicking an icon on my desktop (i.e. an USB key to select unmount or eject) takes seconds... I can right click, remove my hand from the mouse and count a few seconds before the menu even appears. If updating priority or severity helps get this fixed, please consider doing that. Richard.
Try upgrading to the rawhide kernel, I have no idea what's wrong with your hardware or why you're experiencing this.
Wrong with our hardware? Are you saying that Fedora 14 broke all our machines somehow? Please say it isn't so and this is a bug in the kernel ;) I cant speak for other people but my nw9440 was great on every single Fedora for the last 4+ years up to and including Fedora 13. But I will test this. I have a unused 25Gig partition on my nw9440 and I will install another OS there and see what happens. Any suggestions on which OS I should set up and test to prove/disprove the Fedora 14 broke our hardware theory?
Try this when it completes: http://koji.fedoraproject.org/koji/taskinfo?taskID=2678152
(In reply to comment #30) > Hi, > > I'm just wondering how can this be a low priority, medium severity issue... I'm > unable to use my laptop (Dell Latitude 630c) for several weeks (I actually lost > the count) since this bug came out!!! You're under the mistaken impression that priority/severity settings in a bug actually mean anything. They are largely ignored.
I'm running F14 + the latest rawhide kernel (2.6.37-0.rc6.git0.1.fc15) + plus "pcie_ports=compat" kernel boot parameters. I believe that it's the "pcie_ports=compat" that fixed me up as the problem still happens without it.
I have done some testing. Here is what my system looks like under 2.6.35.9-64.fc14.i686 with default boot options: Top causes for wakeups: 92.9% (2001.9) [kernel scheduler] Load balancing tick 1.5% ( 33.1) [iwl3945] <interrupt> 0.9% ( 19.2) USB device 4-1 : Logitech USB Optical Mouse (Logitech) 0.8% ( 17.3) [ahci] <interrupt> 0.7% ( 15.9) [uhci_hcd:usb4, yenta, tifm_7xx1] <interrupt> 0.6% ( 13.6) packagekitd Sometimes I see higher percentages in the other lines, but nothing seems to be able to take the first place from the load ballancing tick. As per Jeffrey's suggestion I tried 2.6.35.9-64.fc14.i686 with pcie_ports=compat and lo and behold, it made a huge difference: Top causes for wakeups: 20.1% ( 15.1) [ata_piix] <interrupt> 18.3% ( 13.8) [iwl3945] <interrupt> 15.9% ( 12.0) [kernel scheduler] Load balancing tick 13.1% ( 9.9) [kernel core] hrtimer_start (tick_sched_timer) 10.6% ( 8.0) [kernel core] __mod_timer (rh_timer_func) 2.6% ( 1.9) [ahci] <interrupt> While copying files from my Android: Top causes for wakeups: 24.9% ( 67.7) USB device 1-6 : SAMSUNG_Android (SAMSUNG) 17.0% ( 46.4) [ehci_hcd:usb1, uhci_hcd:usb2] <interrupt> 9.2% ( 25.0) [kernel core] hrtimer_start (tick_sched_timer) 7.7% ( 21.1) [kernel scheduler] Load balancing tick 6.3% ( 17.2) [uhci_hcd:usb4, yenta, tifm_7xx1] <interrupt> 6.3% ( 17.2) USB device 4-1 : Logitech USB Optical Mouse (Logitech) And the whole machine feels much lighter. I even venture to say by orders of magnitude. I'm going to keep this setup for the evening and try things that previously where impossible (watch a HDTV movie without hiccups and so on) and see if things are really fixed by this. I will test the new test-kernel tomorrow, unless someone else does it :)
New kernel won't fix it. Thanks for testing, this looks like a consequence of PCIE ASPM. I'll poke Matthew about it, since that's really his cup of tea. Hopefully we can get a fix quickly. In the mean time, pcie_ports=compat is a safe workaround. Thanks, Kyle
http://koji.fedoraproject.org/koji/taskinfo?taskID=2679491 Actually, if you'd please try that without booting using pcie_ports=compat I'd appreciate it. --Kyle
(In reply to comment #36) > You're under the mistaken impression that priority/severity settings in a bug > actually mean anything. They are largely ignored. Seems to me we need to fix that, then. Or get rid of the settings. If what you say is true, this is a pretty sorry state of affairs compared to, say, Launchpad.
(In reply to comment #40) > http://koji.fedoraproject.org/koji/taskinfo?taskID=2679491 > > Actually, if you'd please try that without booting using pcie_ports=compat I'd > appreciate it. > > --Kyle Seems to work better: 2.6.35.10-72.bz635813.fc14.x86_64 without pcie_ports=compat Häufigste Ursachen für das Aufwachen: 52,9% (326,3) PS/2 keyboard/mouse/touchpad interrupt 24,5% (151,3) [kernel scheduler] Load balancing tick 4,4% ( 27,0) [iwlagn] <interrupt> 3,2% ( 20,0) [kernel core] hrtimer_start (tick_sched_timer) 2,1% ( 13,0) firefox 2,0% ( 12,3) [kernel core] __mod_timer (flush_unmaps_timeout) 1,6% ( 10,0) xbindkeys ------------------------------------------------------------------- 2.6.35.9-65.fc14.x86_64 without pcie_ports=compat Häufigste Ursachen für das Aufwachen: 46,1% (1529,4) [kernel scheduler] Load balancing tick 30,0% (996,8) pulseaudio 12,5% (413,8) vmware-vmx 2,1% ( 69,2) [Rescheduling interrupts] <kernel IPI> 2,0% ( 64,8) [ahci] <interrupt> 1,8% ( 60,4) [TLB shootdowns] <kernel IPI> 1,2% ( 40,2) [iwlagn] <interrupt> 0,9% ( 31,0) [Function call interrupts] <kernel IPI>
Uggh.... Abysmal translation though.... ;)
Fabian, Can you install the pmtools package and attach the output of the acpidump command (run as root) please?
Created attachment 470081 [details] acpidump [root@serenity Desktop]# acpidump > acpidump.txt
Created attachment 470082 [details] acpidump x201T Lenovo
Created attachment 470317 [details] acpidump Dell Latitude 630C 2.6.35.10-72.fc14.x86_64 without pcie_ports=compat Wakeups-from-idle per second : 52.9 interval: 15.0s no ACPI power usage estimate available Top causes for wakeups: 50.4% ( 63.9) [kernel scheduler] Load balancing tick 28.8% ( 36.5) [iwlagn] <interrupt> 6.3% ( 8.0) [kernel core] __mod_timer (rh_timer_func) 3.6% ( 4.6) [kernel core] hrtimer_start (tick_sched_timer) 3.2% ( 4.0) [Function call interrupts] <kernel IPI> 2.2% ( 2.8) [ata_piix] <interrupt> 1.8% ( 2.3) [eth0] <interrupt>
We only needed one, thanks, please avoid littering bugs with excessive "me toos." regards, Kyle
to add something tangible interesting. this still happens with kernel-2.6.38-0.rc2.git0.1.fc15.x86_64 (w/o any additional kernel cmdline arguments). (this is on a amd 4050e, ati rx780-based mainboard (amd sb600-southbridge))
10:14 [ root @ samhain ] /root ROOTMODE> uname -sr Linux 2.6.35.10-80.fc14.x86_64 with boot options pcie_ports=compat Top causes of wakeups: 73,1% (1730,8) [kernel scheduler] Load balancing tick 9,2% (252,0) chromium-browse 8,5% (233,0) Klawiatura/mysz/touchpad PS/2 interrupt 5,5% (150,8) java with pcie_ports=compat nohz=off Top causes of wakeups: 71,5% (2001,9) [kernel scheduler] Load balancing tick 10,6% (296,6) Klawiatura/mysz/touchpad PS/2 interrupt 8,2% (229,2) chromium-browse Without pcie_ports=compat and without nohz=off results the same like with "pcie_ports=compat nohz=off" Lenovo Thinkpad R61i 8943-DKG (C2D T5250) http://www.smolts.org/client/show/pub_155ba98d-3576-4e0a-8940-e209a5675506
Created attachment 475575 [details] acpidump Thinkpad 8943-DKG
11:36 [ root @ samhain ] /root ROOTMODE> grep . -r /sys/firmware/acpi/interrupts /sys/firmware/acpi/interrupts/gpe00: 0 invalid /sys/firmware/acpi/interrupts/gpe01: 0 enabled /sys/firmware/acpi/interrupts/gpe02: 0 enabled /sys/firmware/acpi/interrupts/gpe03: 0 invalid /sys/firmware/acpi/interrupts/gpe04: 0 invalid /sys/firmware/acpi/interrupts/gpe05: 0 invalid /sys/firmware/acpi/interrupts/gpe06: 0 enabled /sys/firmware/acpi/interrupts/gpe07: 0 invalid /sys/firmware/acpi/interrupts/gpe08: 0 invalid /sys/firmware/acpi/interrupts/gpe09: 0 disabled /sys/firmware/acpi/interrupts/gpe0A: 0 invalid /sys/firmware/acpi/interrupts/gpe0B: 0 invalid /sys/firmware/acpi/interrupts/gpe0C: 0 invalid /sys/firmware/acpi/interrupts/gpe0D: 0 invalid /sys/firmware/acpi/interrupts/gpe0E: 0 invalid /sys/firmware/acpi/interrupts/gpe0F: 0 invalid /sys/firmware/acpi/interrupts/gpe10: 0 invalid /sys/firmware/acpi/interrupts/gpe11: 0 invalid /sys/firmware/acpi/interrupts/gpe12: 8615 enabled /sys/firmware/acpi/interrupts/gpe13: 0 invalid /sys/firmware/acpi/interrupts/gpe14: 0 invalid /sys/firmware/acpi/interrupts/gpe15: 0 invalid /sys/firmware/acpi/interrupts/gpe16: 0 invalid /sys/firmware/acpi/interrupts/gpe17: 0 invalid /sys/firmware/acpi/interrupts/gpe18: 0 enabled /sys/firmware/acpi/interrupts/gpe19: 0 invalid /sys/firmware/acpi/interrupts/gpe1A: 0 invalid /sys/firmware/acpi/interrupts/gpe1B: 0 invalid /sys/firmware/acpi/interrupts/gpe1C: 0 invalid /sys/firmware/acpi/interrupts/gpe1D: 0 invalid /sys/firmware/acpi/interrupts/gpe1E: 0 invalid /sys/firmware/acpi/interrupts/gpe1F: 0 invalid /sys/firmware/acpi/interrupts/ff_pmtimer: 0 invalid /sys/firmware/acpi/interrupts/ff_gbl_lock: 0 enabled /sys/firmware/acpi/interrupts/ff_pwr_btn: 0 enabled /sys/firmware/acpi/interrupts/ff_slp_btn: 0 invalid /sys/firmware/acpi/interrupts/ff_rt_clk: 0 disabled /sys/firmware/acpi/interrupts/gpe_all: 8615 /sys/firmware/acpi/interrupts/sci: 8615 /sys/firmware/acpi/interrupts/sci_not: 1 /sys/firmware/acpi/interrupts/error: 0
Reported fixed by the original reporter. If you're seeing high wakeup rates on an otherwise idle system (ie, you're not getting any wakeups from i8042 or userspace processes), please open a new bug per machine.
https://bugzilla.redhat.com/show_bug.cgi?id=667080 https://bugzilla.redhat.com/show_bug.cgi?id=680041 https://bugzilla.redhat.com/show_bug.cgi?id=664027 All bugs created by me, I love reaction time (up to one month and still status "new"!) for new bugs related to existing ones. Battery lifetime reduced from ~7h to 2:15h