linux-kernel - Re: acpi_idle: Very idle Core i7 machine never enters C3

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Feb 2010 10:30:24 -0600
From:	Jeff Garrett <jeff@...rrett.org>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-kernel@...r.kernel.org, Len Brown <lenb@...nel.org>,
	linux-acpi@...r.kernel.org
Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3

On Mon, Feb 01, 2010 at 03:10:38PM +0100, Pavel Machek wrote:
> On Tue 2010-01-26 02:47:40, Jeff Garrett wrote:
> > 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.
> 
> > 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?
> 
> DMA keeps system awake? Possibly USB?

X is not running.  USB is not enabled at all (CONFIG_USB_SUPPORT is not
set), and likewise for sound & drm.  What could be doing the DMA?  :)

If there is DMA, it could be disk or network related.  However, I
find it hard to believe that this activity is so constant on a nearly
idle system...  Of course, I haven't thought of a way to test this yet.

Attaching my config & dmesg of my latest try.

Thanks,
-Jeff

View attachment "config" of type "text/plain" (80091 bytes)

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