LWN.net Logo

2.6.22 regression: thermal trip points

From:  Knut Petersen <Knut_Petersen-AT-t-online.de>
To:  linux-kernel-AT-vger.kernel.org
Subject:  2.6.22 regression: thermal trip points
Date:  Thu, 02 Aug 2007 10:40:44 +0200
Message-ID:  <46B1988C.3090302@t-online.de>
Cc:  Andrew Morton <akpm-AT-osdl.org>, trenn-AT-suse.de, pavel-AT-ucw.cz, mjg59-AT-srcf.ucam.org, lenb-AT-kernel.org
Archive-link:  Article, Thread

Hi everybody!

Kernel 2.6.22 decreases performance by about 50% on my system.
No, I do not like that. The reason is a broken BIOS, granted, but there
was a perfect workaround in the kernel that has been dropped.

mainboard: AOpen i915GMm-hfs, AWARD BIOS
cpu: Pentium-M 750 (0.8 to 1.86 MHz)
openSuSE 10.2 with kernel 2.6.22.1

The cpu fan can not be controled by linux kernel.
The BIOS will switch on the cpu fan a bit above 50 deg. Celsius.
The active and passive trip points both are set to 50 deg. Celsius.
Temperature of the idle cpu at 800 Mhz: 34 to 42 deg. C.
The BIOS never changes the trip points.
Cpufreq does work perfectly.

Previously there was the possibility  to add something like

echo  "100:0:65:70:0" > /proc/acpi/thermal_zone/THRM/trip_points
echo  2 > /proc/acpi/thermal_zone/THRM/polling_frequency
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

to e.g. /etc/init.d/boot.local. With 2.6.22 that solution does not exist
any longer. Now the code in thermal.c slows down the cpu under load
to prevent "overheating". Kernel compile time increases from about 12
to 18 minutes. No, I don´t like that, nobody would.

Possible solutions:

1. Get a better BIOS! --- There is none.

2. Fix DSDT!  --- Recompiling gives a number of errors ... I do not  know
how to fix it.

3. Don´t include thermal.c! --- That does help, but as this is a 24/7
system, the
cpu fan could break. At that time I do not want to rely on the BIOS to
save my
system (the next trip point is at 100 deg. Celsius).

4. Revert Len Browns commit 11ccc0f249cb01a129f54760b8ff087f242935d4

I would vote for option 4, but I do understand some of the arguments of
Len in
the 2.6.22-rc1-mm1 discussion in May. Yes, communicating trip points to
thermal.c is a hack, it will fail on systems that change trip points
dynamically
and it might be dangerous for the machine if unreasonable trip points
are chosen.
But it does help to keep the machine quiet, and to work around a too low
or too
trip points defined by the BIOS.

If it should be not acceptable to revert the questionable commit without
changes,
would it be acceptable to make rw trip_points a kernel config option?

cu,
 Knut Petersen


(Log in to post comments)

2.6.22 regression: thermal trip points

Posted Jun 12, 2008 7:42 UTC (Thu) by Jim_99 (guest, #52487) [Link]

Knut, you have a situation that is a degradation for your system. My Dell L400 P3 733 would
love the fan to come on at 50* C. Instead, it comes on @ 65* C. The only hit my system takes
is slightly less battery time, by as much as 15 minutes. I'll gladly take that trade off for
operating temps 10-15* C lower.

I vote to reinstate trip point adjustments. Dell doesn't support bios updates on discontinued
product(s) like my notebook. My notebook has become an internet appliance at best with the
trip points Ubuntu provides at installation basic issue code. 

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds