Re: 2.6.22 regression: thermal trip points

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 02 Aug 2007 10:40:44 +0200 Knut Petersen <Knut_Petersen@t-online.de> wrote:

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

I didn't understand the arguments either, actually.

Here we had obviously-useful-to-you functionality which was taken away
without, afaik, providing any alternative.

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

Well we obviously need to do _something_.  And reverting that commit until
we get a decent replacement in place sounds like a fine idea to me.