linux-kernel - Re: High cpu temperature with 2.6.32, bisection shows commit 69d258 (fwd)

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]

Message-ID: <alpine.LNX.2.00.1002102245200.1675@localhost.localdomain>
Date:	Wed, 10 Feb 2010 22:51:38 +0200 (EET)
From:	Dimitrios Apostolou <jimis@....net>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Alex Chiang <achiang@...com>, Len Brown <lenb@...nel.org>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Yinghai Lu <yinghai@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: High cpu temperature with 2.6.32, bisection shows commit 69d258
 (fwd)

Hi Arjan,

it seems that the changes inside processor module have bitten another 
user, see relevant thread at archlinux bugtracker:
http://bugs.archlinux.org/task/17771

It can be summarised with the following quote:

I've tested jimis's suggestion about booting with init=/bin/sh and later 
modprobing next modules.
I confirm that module called "processor" in any kernel26 2.6.32.* is a 
root problem of high power consumption.
Here's output of modprobing it:

ACPI: SSDT 000000003f6d94fb 00238 (v01 PmRef Cpu0Ist 000003000 INTL 
20050624)
ACPI: SSDT 000000003f6d8e8c 005EA (v01 PmRef Cpu0Cst 000003001 INTL 
20050624)
Marking TSC unstable due to TSC halts in idle
processor LNXCPU:00: registered as cooling_device0
ACPI: SSDT 000000003f6d9733 000C8(v01 PmRef Cpu1Ist 000003000 INTL 
20050624)
ACPI: SSDT 00000000376d9476 00085 (v01 PmRef Cpu1Cst 000003000 INTL 
20050624)
Swtiching to clocksource hpet
processor LNXCPU:01: registered as cooling_device1

As I understand, in his case the C3 state is unstable and exits 
immediately. I have asked him to post the dmidecode output so you can put 
him on the exception list too. However I now believe that more and more 
users will be facing the same problem, it's not something you find easily, 
especially on desktop machines! What do you think?

Thanks,
Dimitris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/