Re: 2.6.22 regression: thermal trip points

Re: 2.6.22 regression: thermal trip points

[Len Brown]

On Thursday 02 August 2007 04:40, Knut Petersen wrote:

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

Thanks for the sighting, Knut!
This regression is dramatic when put in the terms of 50% performance hit!
I guess the good news is that thermal throttling is doing the job
we are asking it to:-)

The statement above regarding the existence of active trip points
and the kernel not being able to control the fan are inconsistent
with each other.

Please open a sighting for this machine here:

http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
vs. Power-Thermal
and attach the output from acpidump, cat /proc/acpi/thermal_zone/*/*
and assign it to len.brown@intel.com

BTW. does the board boot and run properly with "acpi=off"?

thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.22 regression: thermal trip points

[Len Brown]

On Thursday 02 August 2007 05:45, Adrian Schröter wrote:
> On Thursday 02 August 2007 11:42:27 wrote Thomas Renninger:
> > On Thu, 2007-08-02 at 10:40 +0200, Knut Petersen 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
> >
> > Is this a DELL laptop that gets throttled by 75% to throttling state 6
> > if 60 degrees are exceeded?
> > Adrian has such a machine..., no idea what is going on with that one,
> > but only workaround to get any use out of this machine is to override at
> > least the passive trip point.
> 
> JFYI, there are plenty of these systems around, it was one out of four 
> standard Novell modells. I am mabye just the first one who uses Factory on 
> it, but expect more bugreports when 10.3 gets released ...

That's very good news, Adrian.  In the past all we had to go on
was the memory of a machine that died several years ago.
But if you've got a live failure, that is really valuable.

Please go here
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
and submit a new sighting vs. Power-Thermal
and attach the output from acpidump, cat /proc/acpi/thermal_zone/*/*
and assign it to len.brown@intel.com

thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.22 regression: thermal trip points

[Renato S. Yamane]

Len Brown escreveu:
> On Thursday 02 August 2007 04:40, Knut Petersen wrote:
>> 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.

On my Toshiba M45-S355 (Toshiba Bios, Pentium M 750 - 0.8 at 1.86GHz, 
Debian Etch) I see the same using Kernel 2.6.21.6

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

I never do that, but see below (Kernel 2.6.21.6):

cat /proc/acpi/thermal_zone/TZCL/trip_points
critical (S5):           105 C

cat /proc/acpi/thermal_zone/TZCL/polling_frequency
polling frequency:       2 seconds

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand

Regards,
Renato S. Yamane

Re: 2.6.22 regression: thermal trip points

[Knut Petersen]

Len Brown :
>  
>
> Thanks for the sighting, Knut!
> This regression is dramatic when put in the terms of 50% performance hit!
> I guess the good news is that thermal throttling is doing the job
> we are asking it to:-)
>
>
>   
Thermal management by cpufreq is working really fine ;-)

My problems are definitely not related to a linux bug. All trip_points
are fixed, hardcoded in the system BIOS at address 0x000FF810.

Yes, I could hack  and flash a custom BIOS.

After reading a lot I think I even could fix the DSDT.

But all that would only be a solution for my system. The principal
question is, if that hook that allowed to override unreasonable
trip point definitions is too dangerous to be a part of the linux kernel.

You and some others believed it should not be part of the kernel,
and so it was eliminated a while ago. Some people want it back,
either because
- they need it desperately to allow their machines healthy operation,
- they need it to restore performance of their machines, or
- they want a really quiet system.

Root should be allowed to smoke his system - ask him if he really
wants to do so, ask him to echo "Yes, it´s me who is guilty" to
some file prior to allow trip point changes, but do not eliminate
hooks useful for the management of buggy machines from our
kernel.

We do need writable trip points again. And, Thomas, some people
also need to raise the defaults.

cu,
 Knut

Re: 2.6.22 regression: thermal trip points

[Len Brown]

On Friday 03 August 2007 08:53, Knut Petersen wrote:
> Len Brown :
> >  
> >
> > Thanks for the sighting, Knut!
> > This regression is dramatic when put in the terms of 50% performance hit!
> > I guess the good news is that thermal throttling is doing the job
> > we are asking it to:-)
> >
> >
> >   
> Thermal management by cpufreq is working really fine ;-)

Unfortunately, I a lot of people don't understand that the ";-)"
after this statement and they really think that cpufreq is a
solution for thermal management.  It isn't.  Systems still
need to be thermally sane when they are fully utilized and
cpufreq helps not.

> My problems are definitely not related to a linux bug. All trip_points
> are fixed, hardcoded in the system BIOS at address 0x000FF810.
> 
> Yes, I could hack  and flash a custom BIOS.
> 
> After reading a lot I think I even could fix the DSDT.

No, you should never have to override your BIOS --
except for debugging.

If Windows works out-of-the-box on this system,
then Linux should too - even if we have to use a DMI-based
workaround for a BIOS bug.

I'm looking forward to seeing the bug report that you are
going to file.  Please include the dmidecode output in addition
to the acpidump output.

thanks,
-Len

Re: 2.6.22 regression: thermal trip points

[Len Brown]

On Friday 03 August 2007 07:43, Renato S. Yamane wrote:
> Len Brown escreveu:
> > On Thursday 02 August 2007 04:40, Knut Petersen wrote:
> >> 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.
> 
> On my Toshiba M45-S355 (Toshiba Bios, Pentium M 750 - 0.8 at 1.86GHz, 
> Debian Etch) I see the same using Kernel 2.6.21.6
> 
> >> 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
> 
> I never do that, but see below (Kernel 2.6.21.6):
> 
> cat /proc/acpi/thermal_zone/TZCL/trip_points
> critical (S5):           105 C
> 
> cat /proc/acpi/thermal_zone/TZCL/polling_frequency
> polling frequency:       2 seconds
> 
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> ondemand
> 

Renato,
I don't understand how your Toshiba is similar to Knut's Aopen.
You've got a single critical trip point at 105C, but no active or passive
trip points.

Are you reporting some kind of failure?

The only thing wrong with your system is that polling_frequency != 0 --
but that is probably a distro configuration issue rather than
a kernel issue.

thanks,
-Len