On Thu, 02 Aug 2007 10:40:44 +0200 Knut Petersen <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/