Bug 635813 - Excessive kernel wakeups
Summary: Excessive kernel wakeups
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: John Feeney
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-20 19:00 UTC by Jesse Keating
Modified: 2013-01-10 08:38 UTC (History)
30 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 680041 (view as bug list)
Environment:
Last Closed: 2011-02-09 18:21:08 UTC
Type: ---
Embargoed:
poelstra: fedora_requires_release_note+


Attachments (Terms of Use)
acpidump (265.63 KB, text/plain)
2010-12-21 21:22 UTC, Fabian A. Scherschel
no flags Details
acpidump x201T Lenovo (296.65 KB, text/plain)
2010-12-21 21:32 UTC, brickwedde
no flags Details
acpidump (126.52 KB, text/plain)
2010-12-22 22:07 UTC, Jhonny Oliveira
no flags Details
acpidump Thinkpad 8943-DKG (296.20 KB, text/plain)
2011-01-27 10:35 UTC, Krzysztof "Uosiu" Hajdamowicz
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 16525 0 None None None Never

Internal Links: 680041

Description Jesse Keating 2010-09-20 19:00:57 UTC
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

Comment 1 Chuck Ebbert 2010-09-21 13:18:44 UTC
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.

Comment 2 Chuck Ebbert 2010-09-21 14:01:10 UTC
I put the patches in 2.6.35.5-29, building now.

Comment 3 Gene Snider 2010-09-22 19:29:01 UTC
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

Comment 4 Chuck Ebbert 2010-09-23 16:41:09 UTC
(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.

Comment 5 Gene Snider 2010-09-23 22:28:53 UTC
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

Comment 6 Chuck Ebbert 2010-09-25 20:28:24 UTC
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>

Comment 7 Gene Snider 2010-09-27 22:32:51 UTC
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

Comment 8 Orion Poplawski 2010-10-15 17:32:08 UTC
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.

Comment 9 Orion Poplawski 2010-10-15 17:33:24 UTC
Possible upstream bug

Comment 10 Orion Poplawski 2010-10-15 17:49:52 UTC
With nohz=off, my load can get to 0.00 on an idle system (despite load balancing ticks of 1000/s - obviously :).

Comment 11 John Poelstra 2010-10-15 18:31:58 UTC
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

Comment 12 John Poelstra 2010-10-15 18:37:41 UTC
Also discussed here: http://lists.fedoraproject.org/pipermail/test/2010-October/094683.html

Comment 13 John Poelstra 2010-10-15 18:53:50 UTC
Hardware is Dell XPS M1330.

Comment 14 Fabian A. Scherschel 2010-11-08 08:55:36 UTC
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?

Comment 15 brickwedde 2010-11-24 21:51:35 UTC
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)

Comment 16 Kyle McMartin 2010-11-28 02:05:32 UTC
http://kyle.fedorapeople.org/kernel/2.6.35.9-62.bz635813.fc14/x86_64/

Try this build, please?

Comment 17 brickwedde 2010-11-29 07:29:43 UTC
Looks mich better for me:

bash-4.1$ cat /proc/loadavg 
0.08 0.13 0.09 1/285 5631

Comment 18 Jeffrey C. Ollie 2010-11-29 13:07:49 UTC
No change for me, one CPU on my laptop is stuck at ~100% CPU usage in kacpid.

Comment 19 Kyle McMartin 2010-11-29 14:26:17 UTC
There's two bugs being conflated here.

Comment 20 Kyle McMartin 2010-11-29 15:02:46 UTC
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

Comment 21 Jeffrey C. Ollie 2010-11-29 20:52:12 UTC
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

Comment 22 Kyle McMartin 2010-11-29 21:03:38 UTC
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.

Comment 23 brickwedde 2010-11-30 12:59:35 UTC
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

Comment 24 Jeffrey C. Ollie 2010-11-30 15:01:41 UTC
(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.

Comment 25 Brad Hein 2010-12-07 17:37:10 UTC
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...

Comment 26 Kyle McMartin 2010-12-09 16:32:58 UTC
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

Comment 27 Gene Snider 2010-12-09 22:47:00 UTC
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

Comment 28 Gene Snider 2010-12-09 23:00:27 UTC
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

Comment 29 Gene Snider 2010-12-10 19:23:56 UTC
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

Comment 30 Jhonny Oliveira 2010-12-19 19:19:22 UTC
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

Comment 31 Richard Marko 2010-12-20 01:21:28 UTC
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

Comment 32 Richard Allen 2010-12-20 15:49:59 UTC
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.

Comment 33 Kyle McMartin 2010-12-20 16:50:26 UTC
Try upgrading to the rawhide kernel, I have no idea what's wrong with your hardware or why you're experiencing this.

Comment 34 Richard Allen 2010-12-20 17:12:23 UTC
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?

Comment 35 Kyle McMartin 2010-12-20 17:39:28 UTC
Try this when it completes:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2678152

Comment 36 Jesse Keating 2010-12-20 18:03:53 UTC
(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.

Comment 37 Jeffrey C. Ollie 2010-12-20 19:18:36 UTC
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.

Comment 38 Richard Allen 2010-12-20 23:50:22 UTC
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 :)

Comment 39 Kyle McMartin 2010-12-21 00:30:33 UTC
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

Comment 40 Kyle McMartin 2010-12-21 00:47:12 UTC
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

Comment 41 Fabian A. Scherschel 2010-12-21 11:13:36 UTC
(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.

Comment 42 brickwedde 2010-12-21 19:55:03 UTC
(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>

Comment 43 Fabian A. Scherschel 2010-12-21 20:15:07 UTC
Uggh.... Abysmal translation though.... ;)

Comment 44 Matthew Garrett 2010-12-21 21:08:40 UTC
Fabian,

Can you install the pmtools package and attach the output of the acpidump command (run as root) please?

Comment 45 Fabian A. Scherschel 2010-12-21 21:22:26 UTC
Created attachment 470081 [details]
acpidump

[root@serenity Desktop]# acpidump > acpidump.txt

Comment 46 brickwedde 2010-12-21 21:32:19 UTC
Created attachment 470082 [details]
acpidump x201T Lenovo

Comment 47 Jhonny Oliveira 2010-12-22 22:07:33 UTC
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>

Comment 48 Kyle McMartin 2010-12-22 22:26:51 UTC
We only needed one, thanks, please avoid littering bugs with excessive "me toos."

regards, Kyle

Comment 49 Tobias Florek 2011-01-23 21:28:09 UTC
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))

Comment 50 Krzysztof "Uosiu" Hajdamowicz 2011-01-27 09:21:23 UTC
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

Comment 51 Krzysztof "Uosiu" Hajdamowicz 2011-01-27 10:35:42 UTC
Created attachment 475575 [details]
acpidump Thinkpad 8943-DKG

Comment 52 Krzysztof "Uosiu" Hajdamowicz 2011-01-27 10:36:57 UTC
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

Comment 53 Matthew Garrett 2011-02-09 18:21:08 UTC
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.

Comment 54 Krzysztof "Uosiu" Hajdamowicz 2011-02-28 19:04:28 UTC
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


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