linux-kernel - 2.6.22 regression: thermal trip points

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

Message-ID: <46B1988C.3090302@t-online.de>
Date:	Thu, 02 Aug 2007 10:40:44 +0200
From:	Knut Petersen <Knut_Petersen@...nline.de>
To:	linux-kernel@...r.kernel.org
CC:	Andrew Morton <akpm@...l.org>, trenn@...e.de, pavel@....cz,
	mjg59@...f.ucam.org, lenb@...nel.org
Subject: 2.6.22 regression: thermal trip points

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