linux-kernel - Re: regression: 2.6.32-rc8 shuts down after reaching critical temperature

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

Date:	Fri, 11 Dec 2009 01:49:07 -0500 (EST)
From:	Len Brown <lenb@...nel.org>
To:	Christoph Hellwig <hch@....de>
Cc:	Thomas Renninger <trenn@...e.de>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Zhang Rui <rui.zhang@...el.com>, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: regression: 2.6.32-rc8 shuts down after reaching critical
 temperature

On Wed, 2 Dec 2009, Christoph Hellwig wrote:

> On Wed, Dec 02, 2009 at 04:07:52PM +0100, Thomas Renninger wrote:
> > Some more hints you may want to try:
> > 
> >   - Does cpufreq work at all?
> >     Does this dir exist: /sys/devices/system/cpu/cpu*/cpufreq
> 
> Yes.
> 
> >     If temp of:
> >     watch -n1 cat /proc/acpi/thermal_zone/THM1/temperature
> >     goes beyond 96 C
> >     an ACPI processor event must get thrown and this:
> >     /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
> >     will get limited (lower than ../cpufreq/cpuinfo_max_freq).
> 
> The speeds change quite constantly under a kernel compile workload, but
> most of the time it's at 2240800 vs cpuinfo_max_freq which is 2801000
> 
> >     echo xy >/sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
> >     may be bad workaround.
> 
> echo 2240800 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
> echo 2240800 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
> 
> made it survive a kernel compile for me, with an observed maximum
> temperature of 87 C.

Interesting.  I wonder if the T500 is using P-states for thermal control,
or if it is relying on us to hit passive trip and pull the P-states down.
In either case, the mystery remains what is different after 2.6.31.

Perhaps we can simplify...
Say you run two copies of "# cat /dev/zero > /dev/null" on 2.6.31.
Does the frequency go up to max and stay there forever,
or does it come down?

If it stays there, what do you see for the temperature,
and do you hear the fans?  Presumably the same test
under 2.6.32 will result in a prompt thermal shutdown.

please send the output from 
grep . /sys/devices/system/cpu/cpu*/cpufreq/*

thanks,
-Len Brown, Intel Open Source Technology Center

--
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/