On 2/17/07, Andras Lorincz <andras.lorincz@xxxxxxxxx> wrote:
On 2/16/07, Len Brown <lenb@xxxxxxxxxx> wrote: > On Friday 16 February 2007 13:25, you wrote: > > On 2/16/07, Len Brown <lenb@xxxxxxxxxx> wrote: > > > On Friday 16 February 2007 02:46, Andras Lorincz wrote: > > > > > > > and the output of cat /proc/acpi/thermal_zone/*/* is: > > > > > > > > cooling mode: active > > > > polling frequency: 30 seconds > > > > state: ok > > > > temperature: 49 C > > > > critical (S5): 105 C > > > > passive: 79 C: tc1=3 tc2=1 tsp=80 > > > > devices=0xf7e9c720 > > > > active[0]: 65 C: devices=0xc17e4d9c > > > > active[1]: 55 C: devices=0xc17e4d38 > > > > > > > > Some remarks: > > > > > > > > - the polling frequency is not set by default so I > > > > run a script on startup which sets the polling > > > > frequency to 30 secs > > > > > > if you don't set polling frequency it is 0? > > > Does anything not work in that case? > > > > > > That is the ideal case -- as polling frequency 0 > > > means that the system is event-driven. > > > > > > If you need to enable polling b/c something isn't working, > > > 3 seconds may be more prudent than 30 seconds. > > > > > > > - the state reported by > > > > /proc/acpi/thermal_zone/THRM/state changes correctly > > > > according to changing temperatures but it is not in > > > > accordance with the real state of the cooler. > > > > > > Do you have /proc/acpi/fan/*/* files? > > > What do they say? > > > > > > -Len > > > > > > > Now I'm playing around with 2.6.20. If I don't set the polling > > frequency at boot time then cat > > /proc/acpi/thermal_zone/polling_frequency gives me: > > > > <polling disabled> > > > > I also tried setting the polling frequency to 0 but doesn't help. ls > > /proc/acpi/fan gives me: > > right, polling frequency of 0 disables polling. > when polling is disabled, the thermal system is event driven. > > why do you want to enable polling -- what is not working > when it is disabled? > > > FAN0 FAN1 > > > > and ls /proc/acpi/fan/FAN0 and ls /proc/acpi/fan/FAN1 give me: > > > > state > > s/ls/cat/ > > -Len > > The CPU cooler doesn't start spinning when temperature raises, although the output of `cat /proc/acpi/thermal_zone/THRM/state` changes according to the temperature, so if temperature is less than 55 then `cat /proc/acpi/thermal_zone/THRM/state` returns state ok, if temperature is between 55 and 65 then it returns state active[1] and finally if temperature is higher then 65, `cat /proc/acpi/thermal_zone/THRM/state` returns active[0] but the cpu cooler won't ever start. If I issue the commands `echo 3 > /proc/acpi/fan/FAN0/state` and `echo 0 > /proc/acpi/fan/FAN0/state` then the cooler starts but then never stops even if the temperature falls bellow 55 and manually also can be stopped by `echo 3 > /proc/acpi/fan/FAN0/state`. The same situation with polling set or not.
I also decompiled and recompiled dsdt with iasl and on compilation I get this: Intel ACPI Component Architecture ASL Optimizing Compiler version 20060912 [Dec 20 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a dsdt.dsl 155: Method (_WAK, 1, NotSerialized) Warning 1079 - ^ Reserved method must return a value (_WAK) ASL Input: dsdt.dsl - 3980 lines, 138169 bytes, 1868 keywords AML Output: dsdt.aml - 17440 bytes 535 named objects 1333 executable opcodes Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 613 Optimizations Do you think that this warning has something to do with it? One spooky thing: 2 times happened that the cooler worked once with 2.6.19 and once with 2.6.20-rc7 when the polling frequency was set to 30 s. When the temperature reached 55C, the cooler started spinning and bellow stoped (so it was working as it was supposed to) but couldn't manage with the same kernels to get the cooler working although I don't remember to have done some extra configuration... spooky :). So it worked twice and after reboot, with the same kernels and nothing changed, things stopped working. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
