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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
