On 2/17/07, Andras Lorincz <[EMAIL PROTECTED]> wrote:
On 2/16/07, Len Brown <[EMAIL PROTECTED]> wrote:
> On Friday 16 February 2007 13:25, you wrote:
> > On 2/16/07, Len Brown <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
