Bug 15377 - 2000 wake/sec after r8169 or ath9k load; becomes 35000 in 2.6.32 -- HP Pavilion DM1-1150SL
Summary: 2000 wake/sec after r8169 or ath9k load; becomes 35000 in 2.6.32 -- HP Pavili...
Status: REJECTED INSUFFICIENT_DATA
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Processor (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
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.