lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 26 Jan 2010 02:47:40 -0600
From:	jeff@...rrett.org (Jeff Garrett)
To:	linux-kernel@...r.kernel.org, Len Brown <lenb@...nel.org>,
	linux-acpi@...r.kernel.org
Subject: acpi_idle: Very idle Core i7 machine never enters C3

Hi,

I was trying to chase down a theory that my desktop machine (a core i7)
is running warm (the fan sounds like it's at full speed all the time,
and I think it's not always acted this way -- hence the theory).

powertop is never showing it spending any time in C3...

I compiled a kernel without USB/sound/radeon, and ran without X.  I was
able to get the wakeups/sec down below 20, but no time is spent in C3.

sysfs looks to agree with powertop here (time = 0 on C3):
/sys/devices/system/cpu/cpu0/cpuidle/state0/desc: CPUIDLE CORE POLL IDLE
/sys/devices/system/cpu/cpu0/cpuidle/state0/latency: 0
/sys/devices/system/cpu/cpu0/cpuidle/state0/name: C0
/sys/devices/system/cpu/cpu0/cpuidle/state0/power: 4294967295
/sys/devices/system/cpu/cpu0/cpuidle/state0/time: 457
/sys/devices/system/cpu/cpu0/cpuidle/state0/usage: 59
/sys/devices/system/cpu/cpu0/cpuidle/state1/desc: ACPI FFH INTEL MWAIT 0x0
/sys/devices/system/cpu/cpu0/cpuidle/state1/latency: 1
/sys/devices/system/cpu/cpu0/cpuidle/state1/name: C1
/sys/devices/system/cpu/cpu0/cpuidle/state1/power: 1000
/sys/devices/system/cpu/cpu0/cpuidle/state1/time: 308177
/sys/devices/system/cpu/cpu0/cpuidle/state1/usage: 3975
/sys/devices/system/cpu/cpu0/cpuidle/state2/desc: ACPI FFH INTEL MWAIT 0x10
/sys/devices/system/cpu/cpu0/cpuidle/state2/latency: 17
/sys/devices/system/cpu/cpu0/cpuidle/state2/name: C2
/sys/devices/system/cpu/cpu0/cpuidle/state2/power: 500
/sys/devices/system/cpu/cpu0/cpuidle/state2/time: 873440787
/sys/devices/system/cpu/cpu0/cpuidle/state2/usage: 239038
/sys/devices/system/cpu/cpu0/cpuidle/state3/desc: ACPI FFH INTEL MWAIT 0x20
/sys/devices/system/cpu/cpu0/cpuidle/state3/latency: 17
/sys/devices/system/cpu/cpu0/cpuidle/state3/name: C3
/sys/devices/system/cpu/cpu0/cpuidle/state3/power: 350
/sys/devices/system/cpu/cpu0/cpuidle/state3/time: 0
/sys/devices/system/cpu/cpu0/cpuidle/state3/usage: 0

This may be a complete red herring, but I added some printk logic to
acpi_idle_bm_check(), and it is getting called often, but bm_status is
always 1.  [I infer from this that the idle logic is trying to go into
C3, but this check is stopping it...  Unless I misread something.]

Is this expected behavior or is this a legitimate problem?

How might I investigate this further?

Attaching dmesg, /proc/cpuinfo, powertop -d output.

Thanks,
Jeff Garrett

View attachment "dmesg" of type "text/plain" (40068 bytes)

View attachment "powertop" of type "text/plain" (1964 bytes)

View attachment "cpuinfo" of type "text/plain" (3241 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ