Bug 15377 - 2000 wake/sec after r8169 or ath9k load; becomes 35000 in 2.6.32 -- HP Pavilion DM1-1150SL
2000 wake/sec after r8169 or ath9k load; becomes 35000 in 2.6.32 -- HP Pavili...
Status: REJECTED INSUFFICIENT_DATA
Product: ACPI
Classification: Unclassified
Component: Power-Processor
All Linux
: P1 normal
Assigned To: Zhang Rui
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-23 11:15 UTC by Stefano
Modified: 2010-07-07 05:05 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.32
Tree: Mainline
Regression: Yes


Attachments
powertop -d / lspci -vvv / dmidecode (44.44 KB, text/plain)
2010-02-23 11:15 UTC, Stefano
Details
powertop -d with active network interfaces -> high wakeups (2.71 KB, text/plain)
2010-03-16 17:37 UTC, Stefano
Details
powertop -d with NOT active network interfaces -> low wakeups (2.70 KB, text/plain)
2010-03-16 17:38 UTC, Stefano
Details
modules list BEFORE active network interfaces (3.48 KB, text/plain)
2010-03-16 17:41 UTC, Stefano
Details
modules list AFTER active network interfaces enabled (3.66 KB, text/plain)
2010-03-16 17:42 UTC, Stefano
Details
lspci for kernel2.6.34-rc1 before network (40.51 KB, text/plain)
2010-03-17 08:24 UTC, Stefano
Details
lspci for kernel2.6.34-rc1 after network (40.54 KB, text/plain)
2010-03-17 08:24 UTC, Stefano
Details
dmidecode for hp pavilion dm1 (8.70 KB, text/plain)
2010-03-31 08:03 UTC, Stefano
Details
cpuinfo on kernel 2.6.31.6 (1.39 KB, text/plain)
2010-04-04 13:30 UTC, Stefano
Details
powertop -d with processor.max_cstate=1 on kernel 2.6.34rc1 (3.13 KB, text/plain)
2010-04-04 14:06 UTC, Stefano
Details
powertop -d for kernel 2.6.34 (4.13 KB, text/plain)
2010-06-30 06:37 UTC, Stefano
Details

Description Stefano 2010-02-23 11:15:25 UTC
Created attachment 25174 [details]
powertop -d / lspci -vvv / dmidecode

Laptop HP Pavilion DM1-1150SL
Distribution: Archlinux

After last upgrade package kernel 2.6.31.x to any kernel 2.6.32.*
consumption of power usage dramatic went up, which is killing battery in my laptop - from 5h on battery to not even 2/3h.
I was testing it using powertop tool. When usually there was about 300 to 1000 wakeups from idle per second,
now, with any 2.6.32.* kernel, there is about 30000 to 40000. Also jump from 16-18Watts then to even 35Watts!

System load seems to be pretty normal, not higer than ~0.10. Tempratures with kernel 2.6.31.* is about 42C (idle) while 53C with kernel 2.6.32.*.

i have tried this commandline (grub) without success:
idle=nomwait
clocksource=pit

Everything works fine when i downgraded it to kernel26-2.6.31.6.

i have attached a text file with powertop -d, lspci -vvv and dmidecode

thanks.
Comment 1 Zhang Rui 2010-02-24 09:17:01 UTC
please attach the output of "grep . /sys/firmware/acpi/interrupts/*" when the wakeups are high.
Comment 2 Stefano 2010-02-24 09:35:44 UTC
/sys/firmware/acpi/interrupts/error:       0
/sys/firmware/acpi/interrupts/ff_gbl_lock:       0	enabled
/sys/firmware/acpi/interrupts/ff_pmtimer:       0	invalid
/sys/firmware/acpi/interrupts/ff_pwr_btn:       0	enabled
/sys/firmware/acpi/interrupts/ff_rt_clk:       0	disabled
/sys/firmware/acpi/interrupts/ff_slp_btn:       0	invalid
/sys/firmware/acpi/interrupts/gpe00:       0	invalid
/sys/firmware/acpi/interrupts/gpe01:       0	enabled
/sys/firmware/acpi/interrupts/gpe02:       0	invalid
/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	enabled
/sys/firmware/acpi/interrupts/gpe07:       0	enabled
/sys/firmware/acpi/interrupts/gpe08:       0	enabled
/sys/firmware/acpi/interrupts/gpe09:       0	invalid
/sys/firmware/acpi/interrupts/gpe0A:       0	invalid
/sys/firmware/acpi/interrupts/gpe0B:       0	disabled
/sys/firmware/acpi/interrupts/gpe0C:       0	enabled
/sys/firmware/acpi/interrupts/gpe0D:       0	disabled
/sys/firmware/acpi/interrupts/gpe0E:       0	disabled
/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:     194	enabled
/sys/firmware/acpi/interrupts/gpe18:       0	invalid
/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/gpe20:       0	enabled
/sys/firmware/acpi/interrupts/gpe21:       0	invalid
/sys/firmware/acpi/interrupts/gpe22:       0	invalid
/sys/firmware/acpi/interrupts/gpe23:       0	invalid
/sys/firmware/acpi/interrupts/gpe24:       0	invalid
/sys/firmware/acpi/interrupts/gpe25:       0	invalid
/sys/firmware/acpi/interrupts/gpe26:       0	invalid
/sys/firmware/acpi/interrupts/gpe27:       0	invalid
/sys/firmware/acpi/interrupts/gpe28:       0	invalid
/sys/firmware/acpi/interrupts/gpe29:       0	invalid
/sys/firmware/acpi/interrupts/gpe2A:       0	invalid
/sys/firmware/acpi/interrupts/gpe2B:       0	invalid
/sys/firmware/acpi/interrupts/gpe2C:       0	invalid
/sys/firmware/acpi/interrupts/gpe2D:       0	invalid
/sys/firmware/acpi/interrupts/gpe2E:       0	invalid
/sys/firmware/acpi/interrupts/gpe2F:       0	invalid
/sys/firmware/acpi/interrupts/gpe30:       0	invalid
/sys/firmware/acpi/interrupts/gpe31:       0	invalid
/sys/firmware/acpi/interrupts/gpe32:       0	invalid
/sys/firmware/acpi/interrupts/gpe33:       0	invalid
/sys/firmware/acpi/interrupts/gpe34:       0	invalid
/sys/firmware/acpi/interrupts/gpe35:       0	invalid
/sys/firmware/acpi/interrupts/gpe36:       0	invalid
/sys/firmware/acpi/interrupts/gpe37:       0	invalid
/sys/firmware/acpi/interrupts/gpe38:       0	invalid
/sys/firmware/acpi/interrupts/gpe39:       0	invalid
/sys/firmware/acpi/interrupts/gpe3A:       0	invalid
/sys/firmware/acpi/interrupts/gpe3B:       0	invalid
/sys/firmware/acpi/interrupts/gpe3C:       0	invalid
/sys/firmware/acpi/interrupts/gpe3D:       0	invalid
/sys/firmware/acpi/interrupts/gpe3E:       0	invalid
/sys/firmware/acpi/interrupts/gpe3F:       0	invalid
/sys/firmware/acpi/interrupts/gpe_all:     194
/sys/firmware/acpi/interrupts/sci:     194
/sys/firmware/acpi/interrupts/sci_not:       0
Comment 3 Zhang Rui 2010-03-01 05:56:10 UTC
(In reply to comment #0)
> Created an attachment (id=25174) [details]
> powertop -d / lspci -vvv / dmidecode
> 
> Laptop HP Pavilion DM1-1150SL
> Distribution: Archlinux
> 
pleast attach the powertop -d output in 2.6.31.* kernel
Comment 4 Stefano 2010-03-01 08:13:05 UTC
root ~ #  uname -a
Linux l0cmobi 2.6.31-ARCH #1 SMP PREEMPT Tue Nov 10 19:48:17 CET 2009 i686 Genuine Intel(R) CPU U2300 @ 1.20GHz GenuineIntel GNU/Linux

# on AC power

root ~ #  powertop -d
PowerTOP 1.12   (C) 2007, 2008 Intel Corporation 

Raccolta dati per 15 secondi 


Your CPU supports the following C-states : C1 C2 C3 C4 
Your BIOS reports the following C-states : C1 C4 
Cn	          Avg residency
C0 (cpu occupata)      (11,5%)
C0		  0,0ms ( 0,0%)
C1 mwait	  2,1ms (60,2%)
C4 mwait	  0,2ms (28,2%)
P-states (frequencies)
Wakeups-from-idle per second : 2071,9	interval: 15,0s
no ACPI power usage estimate available
Top causes for wakeups:
  44,5% (417,2)   [kernel scheduler] Load balancing tick
  23,3% (218,8)   chromium
  12,8% (119,7)   [Rescheduling interrupts] <kernel IPI>
   6,8% ( 64,0)   [extra timer interrupt]
   3,4% ( 31,6)   [eth0] <interrupt>
   2,6% ( 24,7)   [kernel core] hrtimer_start (tick_sched_timer)
   2,0% ( 18,5)   xchat
   1,2% ( 11,1)   [kernel core] ehci_irq (ehci_watchdog)
   0,5% (  4,3)   [ehci_hcd:usb2, uhci_hcd:usb4] <interrupt>
   0,4% (  3,7)   zfs-fuse
   0,3% (  3,2)   USB device 2-1.7 : Storage Device   (USB     )
   0,3% (  3,1)   [kernel core] sk_reset_timer (tcp_delack_timer)
   0,3% (  2,6)   [i915@pci:0000:00:02.0] <interrupt>
   0,2% (  2,1)   [uhci_hcd:usb3, uhci_hcd:usb6] <interrupt>
   0,2% (  2,1)   USB device  3-1 : USB Receiver (Logitech)
   0,2% (  1,9)   [acpi] <interrupt>
   0,2% (  1,7)   compiz
   0,1% (  1,0)   X
   0,1% (  0,9)   multiload-apple
   0,1% (  0,9)   [ahci] <interrupt>
   0,1% (  0,7)   [kernel core] neigh_periodic_timer (neigh_periodic_timer)
   0,1% (  0,5)   [Function call interrupts] <kernel IPI>
   0,0% (  0,5)   devkit-disks-da
   0,0% (  0,5)   hald-addon-stor
   0,0% (  0,4)   [TLB shootdowns] <kernel IPI>
   0,0% (  0,4)   sensors-applet
   0,0% (  0,3)   nautilus
   0,0% (  0,2)   /usr/bin/termin
   0,0% (  0,2)   pdflush
   0,0% (  0,2)   ifconfig
   0,0% (  0,2)   gnome-panel
   0,0% (  0,2)   cupsd
   0,0% (  0,2)   system-tools-ba
   0,0% (  0,2)   clock-applet
   0,0% (  0,1)   wicd-monitor
   0,0% (  0,1)   init
   0,0% (  0,1)   PS/2 keyboard/mouse/touchpad interrupt
   0,0% (  0,1)   [kernel core] neigh_add_timer (neigh_timer_handler)
   0,0% (  0,1)   gnome-settings-
   0,0% (  0,1)   ddclient

A USB device is active 100,0% of the time:
USB device 2-1.6 : LaCie Hard Drive USB (LaCie)

Suggestion: Enable USB autosuspend for non-input devices by pressing the U key


Suggestion: increase the VM dirty writeback time from 5,00 to 15 seconds with:
  echo 1500 > /proc/sys/vm/dirty_writeback_centisecs 
This wakes the disk up less frequently for background VM activity

Suggestion: Enable SATA ALPM link power management via: 
  echo min_power > /sys/class/scsi_host/host0/link_power_management_policy
or press the S key.

Recent USB suspend statistics
Active  Device name
100,0%	USB device 2-1.7 : Storage Device   (USB     )
100,0%	USB device 2-1.6 : LaCie Hard Drive USB (LaCie)
100,0%	USB device  4-2 : HP Integrated Module (Broadcom Corp)
100,0%	USB device  3-1 : USB Receiver (Logitech)
100,0%	USB device  2-4 : HP Webcam-50 (QCM)
100,0%	USB device 2-1.5 : Samsung ML-2010 (Samsung)
100,0%	/sys/bus/usb/devices/2-1
100,0%	USB device usb7 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
100,0%	USB device usb6 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
100,0%	USB device usb5 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
100,0%	USB device usb4 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
100,0%	USB device usb3 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
100,0%	USB device usb2 : EHCI Host Controller (Linux 2.6.31-ARCH ehci_hcd)
100,0%	USB device usb1 : EHCI Host Controller (Linux 2.6.31-ARCH ehci_hcd)

Recent audio activity statistics
Active  Device name

Recent SATA AHCI link activity statistics
Active	Partial	Slumber	Device name

# on BATTERY Power

root ~ #  powertop -d
PowerTOP 1.12   (C) 2007, 2008 Intel Corporation 

Raccolta dati per 15 secondi 


Your CPU supports the following C-states : C1 C2 C3 C4 
Your BIOS reports the following C-states : C1 C4 
Cn	          Avg residency
C0 (cpu occupata)      (23,4%)
C0		  0,0ms ( 0,0%)
C1 mwait	  3,1ms (37,8%)
C4 mwait	  0,4ms (38,7%)
P-states (frequencies)
Wakeups-from-idle per second : 1194,1	interval: 15,0s
no ACPI power usage estimate available
Top causes for wakeups:
  37,5% (322,2)   [kernel scheduler] Load balancing tick
  23,4% (200,8)   [Rescheduling interrupts] <kernel IPI>
  16,3% (139,8)   chromium
   6,9% ( 58,9)   [extra timer interrupt]
   6,3% ( 53,9)   [eth0] <interrupt>
   3,2% ( 27,6)   xchat
   1,5% ( 12,7)   [kernel core] hrtimer_start (tick_sched_timer)
   1,3% ( 11,1)   [kernel core] ehci_irq (ehci_watchdog)
   0,9% (  8,1)   [kernel core] sk_reset_timer (tcp_delack_timer)
   0,5% (  4,3)   [ehci_hcd:usb2, uhci_hcd:usb4] <interrupt>
   0,4% (  3,8)   zfs-fuse
   0,4% (  3,2)   USB device 2-1.7 : Storage Device   (USB     )
   0,3% (  2,2)   [i915@pci:0000:00:02.0] <interrupt>
   0,2% (  1,7)   X
   0,2% (  1,6)   [acpi] <interrupt>
   0,2% (  1,3)   compiz
   0,1% (  0,9)   multiload-apple
   0,1% (  0,8)   [kernel core] neigh_periodic_timer (neigh_periodic_timer)
   0,1% (  0,5)   [Function call interrupts] <kernel IPI>
   0,1% (  0,5)   devkit-disks-da
   0,1% (  0,5)   hald-addon-stor
   0,1% (  0,5)   sensors-applet
   0,0% (  0,2)   ifconfig
   0,0% (  0,2)   system-tools-ba
   0,0% (  0,2)   nautilus
   0,0% (  0,2)   clock-applet
   0,0% (  0,2)   gnome-panel
   0,0% (  0,1)   [TLB shootdowns] <kernel IPI>
   0,0% (  0,1)   /usr/bin/termin
   0,0% (  0,1)   gnome-pty-helpe
   0,0% (  0,1)   cupsd
   0,0% (  0,1)   wicd-monitor
   0,0% (  0,1)   init
   0,0% (  0,1)   PS/2 keyboard/mouse/touchpad interrupt
   0,0% (  0,1)   [kernel core] neigh_add_timer (neigh_timer_handler)

A USB device is active 100,0% of the time:
USB device 2-1.5 : Samsung ML-2010 (Samsung)

Suggestion: Enable USB autosuspend for non-input devices by pressing the U key


Recent USB suspend statistics
Active  Device name
100,0%	USB device 2-1.7 : Storage Device   (USB     )
100,0%	USB device 2-1.6 : LaCie Hard Drive USB (LaCie)
  0,0%	USB device  4-2 : HP Integrated Module (Broadcom Corp)
100,0%	USB device  3-1 : USB Receiver (Logitech)
  0,0%	USB device  2-4 : HP Webcam-50 (QCM)
100,0%	USB device 2-1.5 : Samsung ML-2010 (Samsung)
100,0%	/sys/bus/usb/devices/2-1
  0,0%	USB device usb7 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
  0,0%	USB device usb6 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
  0,0%	USB device usb5 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
  0,0%	USB device usb4 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
100,0%	USB device usb3 : UHCI Host Controller (Linux 2.6.31-ARCH uhci_hcd)
100,0%	USB device usb2 : EHCI Host Controller (Linux 2.6.31-ARCH ehci_hcd)
  0,0%	USB device usb1 : EHCI Host Controller (Linux 2.6.31-ARCH ehci_hcd)

Recent audio activity statistics
Active  Device name

Recent SATA AHCI link activity statistics
Active	Partial	Slumber	Device name
Comment 5 Zhang Rui 2010-03-12 07:20:12 UTC
will you please try the latest vanilla kernel, say 2.6.33 or 2.6.34-rc1 to see if the problem still exists?
Comment 6 Stefano 2010-03-16 12:19:04 UTC
ok, i'll try 2.6.33 and 2.6.34-rc1 (compiling right now)
Comment 7 Stefano 2010-03-16 17:36:05 UTC
(In reply to comment #5)
> will you please try the latest vanilla kernel, say 2.6.33 or 2.6.34-rc1 to see
> if the problem still exists?

it is still here, but i've see a strange thing, if i boot without load the eth0/wlan0 and related modules, the wakeups remains 'normal' (under 100) with every kernel version (.31/.32/.33/.34) but just after i run this script:

-----
#!/bin/sh
WLAN=wlan0
LAN=eth0
IP=192.168.1.221
#---
# chiude tutti i programmi che usano la wlan
killall wpa_supplicant

# annulla tutte le interfacce
dhcpcd --release $LAN
dhcpcd --release $WLAN

# spegne e rimuove i driver della wlan
iwconfig $WLAN power off
# Spegne tutte le interfacce wlan
for foo in /sys/class/rfkill/rfkill*/state;
do
  echo 0 > $foo;
done
rmmod ath9k

# carica il driver lan
modprobe r8169
sleep 3

ifconfig $LAN  $IP 255.255.255.0 broadcast 192.168.1.255
ifconfig $LAN up
sleep 3
dhcpcd -r $IP $LAN 
-----

to bring my internet connection up, with kernel .31 wakeups goes around 1.000,
and:

Cn                Avg residency       P-states (frequencies)
C0 (cpu occupata)      ( 4,0%)
polling           0,0ms ( 0,0%)
C1 mwait          5,0ms (66,9%)
C4 mwait          0,3ms (29,1%)

cpu idle temperature stay around 44C

while with kernel > .31 wakeups goes > 35.000 and:

Cn                Avg residency       P-states (frequencies)
C0 (cpu occupata)      ( 27,0%)
polling           0,0ms ( 0,0%)
C1 mwait          5,0ms ( 0,0%)
C4 mwait          0,3ms (73,0%)

cpu idle temperature stay around 54C

i have attached:

powertop -d for kernel 34-rc1 with AND without network active interfaces, hope it helps...
Comment 8 Stefano 2010-03-16 17:37:19 UTC
Created attachment 25550 [details]
powertop -d with active network interfaces -> high wakeups
Comment 9 Stefano 2010-03-16 17:38:07 UTC
Created attachment 25551 [details]
powertop -d with NOT active network interfaces -> low wakeups
Comment 10 Stefano 2010-03-16 17:41:49 UTC
Created attachment 25552 [details]
modules list BEFORE active network interfaces
Comment 11 Stefano 2010-03-16 17:42:26 UTC
Created attachment 25553 [details]
modules list AFTER active network interfaces enabled
Comment 12 Zhang Rui 2010-03-17 06:05:22 UTC
please attach the lspci -vvvxxx both before and after loading the r8169 driver.
Comment 13 Stefano 2010-03-17 08:11:04 UTC
(In reply to comment #12)
> please attach the lspci -vvvxxx both before and after loading the r8169 driver.

be aware that the same problem happens also with ath9k driver, seems related to network...
i'll attach anyway the lspci cmd for kernel .34-rc1 ok ?
or you need also .33 and .31 ?
Comment 14 Zhang Rui 2010-03-17 08:13:55 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > please attach the lspci -vvvxxx both before and after loading the r8169 driver.
> 
> be aware that the same problem happens also with ath9k driver, seems related to
> network...

I mean before and after running the script in comment #7.

> i'll attach anyway the lspci cmd for kernel .34-rc1 ok ?
> or you need also .33 and .31 ?

.34-rc1 would be great.
Comment 15 Stefano 2010-03-17 08:22:30 UTC
ok, just attached thanks !
Comment 16 Stefano 2010-03-17 08:24:15 UTC
Created attachment 25564 [details]
lspci for kernel2.6.34-rc1 before network
Comment 17 Stefano 2010-03-17 08:24:46 UTC
Created attachment 25565 [details]
lspci for kernel2.6.34-rc1 after network
Comment 18 Zhang Rui 2010-03-25 05:47:09 UTC
as this is a 2.6.32-rc1 regression, it would be great if you can use git bisect to find out which commit introduces this bug.
Comment 19 Stefano 2010-03-30 16:46:33 UTC
(In reply to comment #18)
> as this is a 2.6.32-rc1 regression, it would be great if you can use git bisect
> to find out which commit introduces this bug.

unfortunately i'm not so 'power user' to make this :-(
Comment 20 Zhang Rui 2010-03-31 01:17:23 UTC
could you please verify if the problem still exists when you boot with boot option "idle=halt"?
Comment 21 Zhang Rui 2010-03-31 01:18:21 UTC
please attach the dmi output of your laptop.
I'll check if we need to add another dmi entry for your laptop, like we do in http://marc.info/?l=linux-acpi&m=126631358511521&w=2
Comment 22 Stefano 2010-03-31 07:44:52 UTC
(In reply to comment #20)
> could you please verify if the problem still exists when you boot with boot
> option "idle=halt"?

ok, i'll try and report later
Comment 23 Stefano 2010-03-31 07:45:57 UTC
(In reply to comment #21)
> please attach the dmi output of your laptop.
> I'll check if we need to add another dmi entry for your laptop, like we do in
> http://marc.info/?l=linux-acpi&m=126631358511521&w=2

ahem, where i can found dmi output ? ;-)
Comment 24 Zhang Rui 2010-03-31 07:49:24 UTC
just run "sudo dmidecode" and save the output.
Comment 25 Stefano 2010-03-31 08:03:35 UTC
Created attachment 25773 [details]
dmidecode for hp pavilion dm1
Comment 26 Stefano 2010-03-31 08:04:54 UTC
done (it was already here on first file attachment) :)
Comment 27 Stefano 2010-03-31 08:29:17 UTC
(In reply to comment #20)
> could you please verify if the problem still exists when you boot with boot
> option "idle=halt"?

using kernel 2.6.34-rc1 with idle=halt wakeups are pretty low, <1000, but powertop doesn't show any p/c-state.
i can attach a powertop -d if you want.
Comment 28 Len Brown 2010-04-03 20:10:42 UTC
Re: the baseline 2.6.31 case

AC:

> C0 (cpu occupata)      (11,5%)
> C0          0,0ms ( 0,0%)
> C1 mwait      2,1ms (60,2%)
> C4 mwait      0,2ms (28,2%)

> Wakeups-from-idle per second : 2071,9    interval: 15,0s

Battery:

> Cn              Avg residency
> C0 (cpu occupata)      (23,4%)
> C0          0,0ms ( 0,0%)
> C1 mwait      3,1ms (37,8%)
> C4 mwait      0,4ms (38,7%)

> Wakeups-from-idle per second : 1194,1    interval: 15,0s


Even in the baseline "working" case,
this system is seriously broken with 11%-23% busy time
and 2K - 1K wakeups/sec.

It is likely that the existing failure was magnified by
the cpuidle governor update in 2.6.32, as in bug 14742.

What happens to busy time and wakeups/sec if r8169/ath9k
are loaded and then unloaded? 
Any difference if the network cable is plugged-in or not
(or radio is enabled/disabled)

Please boot the latest kernel with "processor.max_cstate=1"
and report the powertop -d output.
Comment 29 Len Brown 2010-04-03 20:46:04 UTC
also, please paste here the output from "cat /proc/cpuinfo"
Comment 30 Stefano 2010-04-04 13:30:22 UTC
Created attachment 25845 [details]
cpuinfo on kernel 2.6.31.6
Comment 31 Stefano 2010-04-04 14:06:06 UTC
Created attachment 25846 [details]
powertop -d with processor.max_cstate=1 on kernel 2.6.34rc1
Comment 32 Stefano 2010-04-04 14:18:50 UTC
> Even in the baseline "working" case,
> this system is seriously broken with 11%-23% busy time
> and 2K - 1K wakeups/sec.

yes, with X,gnome etc loaded.

> What happens to busy time and wakeups/sec if r8169/ath9k
> are loaded and then unloaded? 
> Any difference if the network cable is plugged-in or not
> (or radio is enabled/disabled)

the strange thing is that the problem doesn't happen on module load, but
on driver usage, so when all modules are loaded (ath9k+r8169) wakeups
are about 13/15/sec (no X), when i run wpa_supplicant, wakeups are still low,
ONLY when i run "iwconfig wlan0 essid myessid" wakeups goes very high and there are no way , even if i unload the modules , to make wakeups goes low...

> Please boot the latest kernel with "processor.max_cstate=1"
> and report the powertop -d output.

done .

PS: with processor.max_cstate=1 and with idle=halt, my cpu T is high (compared to kernel 2.6.31.x) of about 6/7C
Comment 33 Zhang Rui 2010-06-09 06:00:27 UTC
does the problem still exists in the latest upstream kernel, say 2.6.34 or 2.6.35-rc2?
Comment 34 Zhang Rui 2010-06-30 06:12:05 UTC
close this bug as there is no response from the bug reporter.
Comment 35 Stefano 2010-06-30 06:35:52 UTC
sorry for delay, but i was on holiday and under hard work, so i have not much time to test.
For now i have the kernel:
Linux l0cmobi 2.6.34-ARCH #1 SMP PREEMPT Sat Jun 19 13:06:16 CEST 2010 i686 Genuine Intel(R) CPU U2300 @ 1.20GHz GenuineIntel GNU/Linux
and even the wakeups are not so high (~2000/s) the temp. of my cpu is still high versus the 2.6.31.x kernels...
i have attached powertop -d.
thanks and sorry for delay.
Comment 36 Stefano 2010-06-30 06:37:24 UTC
Created attachment 26974 [details]
powertop -d for kernel 2.6.34
Comment 37 Stefano 2010-06-30 06:38:59 UTC
(In reply to comment #35)
> sorry for delay, but i was on holiday and under hard work, so i have not much
> time to test.
> For now i have the kernel:
> Linux l0cmobi 2.6.34-ARCH #1 SMP PREEMPT Sat Jun 19 13:06:16 CEST 2010 i686
> Genuine Intel(R) CPU U2300 @ 1.20GHz GenuineIntel GNU/Linux
> and even the wakeups are not so high (~2000/s) the temp. of my cpu is still
> high versus the 2.6.31.x kernels...
> i have attached powertop -d.
> thanks and sorry for delay.

my menu.lst:

# (0) Arch Linux
title  Arch Linux
root   (hd0,4)
kernel /vmlinuz26 root=/dev/sda6 ro elevator=cfq quiet
initrd /kernel26.img
Comment 38 Dmitri Kolobov 2010-07-01 23:36:14 UTC
I have the same problem on new kernels (x86_64, 2.6.35-rc3-6-2),                                                                                                                                                                                          the temperature of the CPU in idle state is more than 50C (70-80C when loaded).                                                                                                                                    
(usual CPU idle temperature on kernel 2.6.31.5 is about 30C).

Here are corresponding reports:                                                                                                                                                                                   
https://bugzilla.novell.com/show_bug.cgi?id=596896                                                                                                                                                                
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/373245

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