fan control

fan control

[Daniele Boffi]

I noticed that not only can I check the status of the fan in /proc/acpi/fan but
I can change it. Since this issue does not seem to be documented (am I wrong?)
I want to be sure I am not doing anything wrong.

Here is the structure of my /proc/acpi/fan directory

$ ls -R /proc/acpi/fan
/proc/acpi/fan:
C1D9  C1DA  C1DB  C1DC

/proc/acpi/fan/C1D9:
state

/proc/acpi/fan/C1DA:
state

/proc/acpi/fan/C1DB:
state

/proc/acpi/fan/C1DC:
state

If the fan is off, I see:

$ cat /proc/acpi/fan/*/*
status:                  off
status:                  off
status:                  off
status:                  off

If it is spinning slowly, I get

$ cat /proc/acpi/fan/*/*
status:                  off
status:                  off
status:                  off
status:                  on

If it is at maximum speed, I have

$ cat /proc/acpi/fan/*/*
status:                  on
status:                  on
status:                  on
status:                  on

And analogous things for the intermediate situations.

Now, I noticed that if I echo 0 into the state files, the fan start spinning.
So that, for instance, if I am in the case when only the first state is on,
then

$ cat /proc/acpi/fan/*/*
status:                  off
status:                  off
status:                  off
status:                  on
$ echo -n 0 > /proc/acpi/fan/C1DB/state
$ cat /proc/acpi/fan/*/*
status:                  off
status:                  off
status:                  on
status:                  on

and the fan spins faster...

To go back, it is sufficient to echo 3 into the same file and the
corresponding state goes off.
I understand this procedure might be very dangerous. How am I sure that, after
playing with the fans, the control of them goes back to the thermal zones?

Any pointer is appreciated.

Daniele


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Raul Aranda Blasco]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

> I understand this procedure might be very dangerous. How am I sure that, after
> playing with the fans, the control of them goes back to the thermal zones?

  After stop it, try to compile a kernel, it must level up the
temperature and spin up the fan.


-- 
Un saludo
    Raul Aranda Blasco
    raul.aranda-fE4FmR91nWqXOwHavGvsmg@public.gmane.org
    http://elistan.dragon-lance.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: fan control

[Daniele Boffi]

> > I understand this procedure might be very dangerous. How am I sure that, after
> > playing with the fans, the control of them goes back to the thermal zones?
> 
>   After stop it, try to compile a kernel, it must level up the
> temperature and spin up the fan.
> 

I think I didn't explain the question correctly. The fans and the thermal zones
do work well. No problems at all. I was just wondering about the consequences
of playing with the fans (like I did with changing their status). If I reboot,
then the next session is OK..., but within the same session, suppose I just
switch the fans from one to two and then back to one. Then, I start some heavy
job and the temperature increases. Will then the kernel spin the fun up or my
previous action prevents it from doing so?

Daniele


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Raul Aranda Blasco]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

On Thu, 2003-05-01 at 20:33, Daniele Boffi wrote:
> I think I didn't explain the question correctly. The fans and the thermal zones
> do work well. No problems at all. I was just wondering about the consequences
> of playing with the fans (like I did with changing their status). If I reboot,
> then the next session is OK..., but within the same session, suppose I just
> switch the fans from one to two and then back to one. Then, I start some heavy
> job and the temperature increases. Will then the kernel spin the fun up or my
> previous action prevents it from doing so?

  That's what I meant before

  After changing the fan speeds and stopping them, try to compiling a
kernel and use "acpi -V" to see how the temperature goes up and the fan
starts to work (managed by the thermal zone).


-- 
Un saludo
    Raul Aranda Blasco
    raul.aranda-fE4FmR91nWqXOwHavGvsmg@public.gmane.org
    http://elistan.dragon-lance.net

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: fan control

[Herbert Nachtnebel]

> > > I understand this procedure might be very dangerous. How am I sure that, after
> > > playing with the fans, the control of them goes back to the thermal zones?
> > 
> >   After stop it, try to compile a kernel, it must level up the
> > temperature and spin up the fan.
> > 

Yes it will, if not please report it to the list.

Herbert.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Daniele Boffi]

> > > > I understand this procedure might be very dangerous. How am I sure that, after
> > > > playing with the fans, the control of them goes back to the thermal zones?
> > > 
> > >   After stop it, try to compile a kernel, it must level up the
> > > temperature and spin up the fan.
> > > 
> 
> Yes it will, if not please report it to the list.

Herbert and Raul,

Thanks for your help.

Indeed, it seem that after rebooting my machine forgets about the fact that I
was playing with the fan status. What I don't understand in Raul's message is
why I should compile a new kernel. The one I have is OK and does not seem to be
screwed up by my experiments with the fan. Should it be? This is what seems
like from Herbert's message. I don't want to make experiments with the risk of
burning my CPU, but yesterday night (after a reboot) the (outside) temperature
was low and the fan was off, even though in my previous experiment I put it in
position one. This for me is the confirmation that everything is OK. What I
don't know yet is whether this is OK also within the same session. If there is
any documentation about that, please let me know (for instance, I found echo 0
and echo 3 just by guessing).

Daniele



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Ducrot Bruno]

On Fri, May 02, 2003 at 10:31:02AM +0200, Daniele Boffi wrote:
> > > > > I understand this procedure might be very dangerous. How am I sure that, after
> > > > > playing with the fans, the control of them goes back to the thermal zones?
> > > > 
> > > >   After stop it, try to compile a kernel, it must level up the
> > > > temperature and spin up the fan.
> > > > 
> > 
> > Yes it will, if not please report it to the list.
> 
> Herbert and Raul,
> 
> Thanks for your help.
> 
> Indeed, it seem that after rebooting my machine forgets about the fact that I
> was playing with the fan status. What I don't understand in Raul's message is
> why I should compile a new kernel.

This is not for installing a new kernel purpose.  This is for
testing the behaviour you asked for when the system do some
work (compiling a kernel is just find for this kind of test).

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Franck SICARD]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Fri, May 02, 2003 at 10:31:02AM +0200, Daniele Boffi wrote:
> Indeed, it seem that after rebooting my machine forgets about the fact that I
> was playing with the fan status. What I don't understand in Raul's message is
> why I should compile a new kernel. The one I have is OK and does not seem to be
> screwed up by my experiments with the fan.

he want that you compile a new kernel to do a test (you could choose
any other action that is CPU hungry (compile X11, crack prime number,
...)). By doing so the temperature of the CPU should increase, and then
you will see if the fan switch on.
There is no risk that you burn your CPU. if the fan don't go up and you
system freeze, just switch it off (no panic you have time) and report to
the list that the fan did not switch on.

	Franck

-- 
Franck SICARD            <Franck.Sicard-ogSpCaIBj4NeoWH0uzbU5w@public.gmane.org>           http://3demi.net/
PGP key=DFDFA865 fingerprint=8E2E 167E 9503 461B AD76 D962 2EEE 9869 DFDF A865

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: fan control

[Markus Gaugusch]

On May 2, Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> On Fri, May 02, 2003 at 10:31:02AM +0200, Daniele Boffi wrote:
> > What I don't understand in Raul's message is why I should compile a
> > new kernel.
>
> This is not for installing a new kernel purpose.  This is for
> testing the behaviour you asked for when the system do some
> work (compiling a kernel is just find for this kind of test).

The following is much easier: cat /dev/zero > /dev/null

Markus


-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Stefan Behnel]

Daniele Boffi wrote:
> Indeed, it seem that after rebooting my machine forgets about the fact that I
> was playing with the fan status.

I'd be confused if it didn't.


> What I don't understand in Raul's message is
> why I should compile a new kernel.

He meant it as a stress test. Do something that demands a bit of CPU power to see if the fan jumps back on after you switched it off.


> The one I have is OK and does not seem to be
> screwed up by my experiments with the fan. Should it be? This is what seems
> like from Herbert's message.

No, see above.


> I don't want to make experiments with the risk of
> burning my CPU

That's why Raul suggested to keep an eye on the output of "acpi" while playing around with the fans.


>, but yesterday night (after a reboot) the (outside) temperature
> was low and the fan was off, even though in my previous experiment I put it in
> position one. This for me is the confirmation that everything is OK.

Sounds like you switched your computer off in between. Then, as I said, that's absolutely normal.


> What I
> don't know yet is whether this is OK also within the same session.

Try to find out then. As long as you keep an eye on the CPU temperature, you're unlikely to burn it.


> If there is
> any documentation about that, please let me know (for instance, I found echo 0
> and echo 3 just by guessing).

I don't know. But 0-5 are the general ACPI power states, 0 being "on" and "5" being "off". 1-4 are different shades in between.

Stefan



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Daniele Boffi]

> > >   After stop it, try to compile a kernel, it must level up the
> > > temperature and spin up the fan.
> > > 
> 
> Yes it will, if not please report it to the list.
> 

OK, sorry for the confusion. I took the risk of burning my CPU (you succeded in
convincing me that it was not a big risk) and.... since I am wrinting from my
laptop... this means that I didn't burn it.

During some heavy job, the temperature reached 73 C maximum (which is not too
hot, I think). cat /proc/acpi/fan/*/* showed

status:                  off
status:                  off
status:                  off
status:                  off

at the beginning (about 50 C).
Then, which is strange, it looked like

status:                  off
status:                  off
status:                  on
status:                  off

when the temperature was more than 62 C and, finally

status:                  off
status:                  on
status:                  on
status:                  off

The fan was spinning accordingly.
After the end of the job, the fan stopped, temperature went down to 60 C and
acpi reported everything off.
I think everything works as expected, there is some issue with reporting the
status in /proc/acpi, since usually I never see the second state (from bottom)
on if the first one is off.

Opposite (passed) test.
I spinned up the fan at maximum speed (all states on) when temperature was
about 60 C. After temperature went below 48 C the fan stopped and all status
is reported off in /proc/acpi.

As a conclusion, I am now convinced that my bios is smart enough and that
there is no risk of burning the CPU. Acpi does a good job, some report is not
correct (same is happening with processor performance: works fine but is
always reporting status P0).

Daniele


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Herbert Nachtnebel]

> Then, which is strange, it looked like
> 
> status:                  off
> status:                  off
> status:                  on
> status:                  off
>
> when the temperature was more than 62 C and, finally

That's not strange. It's only the way the BIOS presents your devices. >From the naming of your FAN devices I see that you are using a Compaq notebook. They replace the meaningful names they use for developing with a rather strange sort of autogenerated names to obscure the interpreted ACPI source code. Linux presents all devices with the name declared in the DSDT (in contrast to the other operating system). For you it now  appears that the FANs aren't sorted in the correct way.

> As a conclusion, I am now convinced that my bios is smart enough and that
> there is no risk of burning the CPU. Acpi does a good job, some report is not
> correct (same is happening with processor performance: works fine but is
> always reporting status P0).

The risk of burning the CPU is really very small. There exist a critical temprature where the system is powered off immediately. Only when the BIOS vendor has screwed the thermal zone table (oh yes, also that exists) it could happen that your CPU is burned.

Regards, Herbert.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Herbert Nachtnebel]

> I am afraid I couldn't get it. I think the fans are sorted correctly (in
> reverse order). Usally I see something like

That's really not difficult - you have

/proc/acpi/fan:
C1D9  C1DA  C1DB  C1DC

and the alphanumeric ordering of the names of your FAN's don't represents the ordering in which they are activated from the thermal zone. If you now use ls/find/cat to display the state, you will not see the behaviour you expect.

Herbert.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Daniele Boffi]

> > I am afraid I couldn't get it. I think the fans are sorted correctly (in
> > reverse order). Usally I see something like
> 
> That's really not difficult - you have
> 
> /proc/acpi/fan:
> C1D9  C1DA  C1DB  C1DC
> 
> and the alphanumeric ordering of the names of your FAN's don't represents the ordering in which they are activated from the thermal zone. If you now use ls/find/cat to display the state, you will not see the behaviour you expect.

OK, but the usual order they start is C1DC, C1DB, C1DA, and C1D9.
In that case I had C1DB on when C1DC was off and this sounds strange (I think
is an error in reporting the status of C1DC), unless the names of the fans
had changed (i.e., in what I call "strange situation", C1BD played the role
which is usually of C1DC).
I think it is more likely that C1DC was on and not reported (indeed from
the sound of the fan the speed, even difficult to detect exactly, seemed higher
than just one status on).

Daniele


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Herbert Nachtnebel]

Please tell me the contents of /proc/acpi/thermal_zone/THRM/trip_points.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Daniele Boffi]

> Please tell me the contents of /proc/acpi/thermal_zone/THRM/trip_points.

I have three thermal zones. The one related to CPU is:

/proc/acpi/thermal_zone/TZ1/trip_points

critical (S5):           93 C
passive:                 91 C: tc1=1 tc2=2 tsp=100 devices=0xc184c940
active[0]:               78 C: devices=0xc18f1a40
active[1]:               72 C: devices=0xc18f1b80
active[2]:               67 C: devices=0xc18f1c80
active[3]:               40 C: devices=0xc18f1d80



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Ducrot Bruno]

On Fri, May 02, 2003 at 11:24:02AM +0200, Stefan Behnel wrote:
> 
> Daniele Boffi wrote:

[]

> 
> Try to find out then. As long as you keep an eye on the CPU temperature, 
> you're unlikely to burn it.
> 
> 
> >If there is
> >any documentation about that, please let me know (for instance, I found 

It is in the ACPI spec.  There is also an example in the thermal
chapter on how to implement a 2 speed fan which seems to be the
same as for your laptop.

> >echo 0
> >and echo 3 just by guessing).
> 
> I don't know. But 0-5 are the general ACPI power states, 0 being "on" and 
> "5" being "off". 1-4 are different shades in between.

To be more precise, there is 6 system state (S0 system functional,
S5 system off), but 'only' 4 for devices in general (G0 fully on, G3 off).

The meaning for the Gx is more or less different, since
this is dependant of the bus from which the device is attached.
Please look at the spec for more info about this.

Cheers,
-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Herbert Nachtnebel]

> > Please tell me the contents of /proc/acpi/thermal_zone/THRM/trip_points.
>
> I have three thermal zones. The one related to CPU is:

Oops, sorry. To intimate with my rewritten naming and didn't expect more than one tz.

> /proc/acpi/thermal_zone/TZ1/trip_points
> 
> critical (S5):           93 C
> passive:                 91 C: tc1=1 tc2=2 tsp=100 devices=0xc184c940
> active[0]:               78 C: devices=0xc18f1a40
> active[1]:               72 C: devices=0xc18f1b80
> active[2]:               67 C: devices=0xc18f1c80
> active[3]:               40 C: devices=0xc18f1d80

Ok, four trip points, four FAN "devices"/states, lowest one at 40 deg. 
You told us that your lowest temperature is about 50 deg. Hence the last one
should be on and you don't see it => something to investigate.

What hardware are you using?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Daniele Boffi]

> Ok, four trip points, four FAN "devices"/states, lowest one at 40 deg. 
> You told us that your lowest temperature is about 50 deg. Hence the last one
> should be on and you don't see it => something to investigate.
> 

In this moment:

$ cat /proc/acpi/thermal_zone/TZ1/temperature
temperature:             50 C

$ cat /proc/acpi/fan/FAN*/state
status:                  on
status:                  off
status:                  off
status:                  off

(I changed the name of the fans to the more readable FAN[0-3], OK?)

This is correct.
If I  echo -n 3 > /proc/acpi/fan/FAN0/state

then the fan stops.
After reaching the second trip point, the fan starts up and I have the
following status report

$ cat /proc/acpi/fan/FAN*/state
status:                  off
status:                  on
status:                  off
status:                  off

This is what is strange.

> What hardware are you using?

Compaq Evo N800v

Cheers,

Daniele


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Herbert Nachtnebel]

> In this moment:
>
> $ cat /proc/acpi/thermal_zone/TZ1/temperature
> temperature:             50 C
>
> $ cat /proc/acpi/fan/FAN*/state
> status:                  on
> status:                  off
> status:                  off
> status:                  off

Ah, here it is - correct.

> (I changed the name of the fans to the more readable FAN[0-3], OK?)

:-)

> if I  echo -n 3 > /proc/acpi/fan/FAN0/state

> then the fan stops.
> After reaching the second trip point, the fan starts up and I have the
> following status report

You have explicitely turned it off.

> $ cat /proc/acpi/fan/FAN*/state
> status:                  off
> status:                  on
> status:                  off
> status:                  off
> 
> This is what is strange.

Well, not really. ACPI fan (speed) control is a little bit artificial. In your case there are four devices presented to the system which has to be activated or deactivated according to the temprature measured by TZ1. What the system doesn't know is that these four devices are in fact the same and are translated into different rotating speeds of the FAN. To correctly achieve the result you are expect, the acpi subsystem would have to guess that an activated FAN device means that all other FAN devices before that device also are activated. A little bit much guessing, not?

Have a look, if the temperature is dropping again under the second treshold in your above situation than you will see that the state of the devices will be correctly again.

Ciao,
Herbert.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Daniele Boffi]

> Have a look, if the temperature is dropping again under the second treshold in your above situation than you will see that the state of the devices will be correctly again.

Well, for the state of the device to be corrected detected, the temperature
needs drop below the first critical point (no fan at all). When the fan starts
again, then everything is OK. This confirms what you explained before.

Thanks,

Daniele


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Éric Brunet]

On Fri, May 02, 2003 at 01:38:19PM +0200, Ducrot Bruno wrote:
> > >echo 0
> > >and echo 3 just by guessing).

About fan control, I would love to be able to stop my fan, but it doesn't
work. I can echo anything to /proc/acpi/fan/FAN/state, it has no bearing
on the fan, and the only result is a line in the log:
> acpi_bus-0199 [18] acpi_bus_set_power    : Device is not power manageable
(kernel is 2.5.67)

I guess it is related to the fact that, according to
/proc/acpi/thermal_zone/THRM/trip_points:
> critical (S5):           100 C
> passive:                 90 C: tc1=4 tc2=3 tsp=60 devices=0xdf7d1ea8
> active[0]:               80 C: devices=0xdf75d9a8
the fan is not supposed to shut down. Did I mention that the computer was
not a laptop ?

However, the computer is a shuttle xpc, temperature does not ever go over
35°C, and I have the feeling that if I dividez my 5 the CPU frequency,
the computer should be able to live without fan.

What makes me hopefull are the methods FON and FOFF in the dsdt:
>    Method (FON, 0, NotSerialized)
>    {
>        SBYT (0x13, 0x46)
>        SBYT (0x14, 0x57)
>        Store (GBYT (0x54), Local0)
>        SBYT (0x14, Local0)
>        Store (GBYT (0x53), Local0)
>        SBYT (0x13, Local0)
>    }
>
>    Method (FOFF, 0, NotSerialized)
>    {
>        Store (GBYT (0x14), Local0)
>        SBYT (0x54, Local0)
>        SBYT (0x14, 0xD0)
>        Store (GBYT (0x13), Local0)
>        SBYT (0x53, Local0)
>    }

FOFF and FON (Fan Off and Fan On, I think) are called by SFAN (Set Fan.
SFAN(0) calls FOFF and SFAN(0xFF) calls FON). SFAN(0x00) appears
in \_PTS (is that Put To Sleep ?) and SFAN(0xFF) appears in \_WAK.

In short, the fan can be stopped in the software, but it is only done at
sleep time. Now it should be possible to translate the definition of FON
and FOFF in a series of writes to some ioports, I guess, but I have no
idea how to do that...

If you are interested, my dsdt is at http://perso.nerim.net/~tudia/download/dsdt

Éric Brunet





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: fan control

[Adachi, Kenichi]

Hi,

> About fan control, I would love to be able to stop my fan, but it
doesn't
> work. I can echo anything to /proc/acpi/fan/FAN/state, it has no
bearing
> on the fan, and the only result is a line in the log:
> > acpi_bus-0199 [18] acpi_bus_set_power    : Device is not power
manageable
> (kernel is 2.5.67)
> 
acpi_bus_set_power() complains that the target device is not enabled to
be power managed as its "power_manageable" flag, which will be set for
devices who have _PS0 or _PR0 in DSDT upon device enumeration, is
__NOT__ set. And, indeed, your FAN device in DSDT doesn't explicitly
list its power resource by _PR0 Object.

   5369 000034ba: Scope _TZ_ (\_TZ_)
   5370 000034c2:   Device FAN_ (\_TZ_.FAN_)
   5371 000034c9:     Name _HID (\_TZ_.FAN_._HID)
   5372 000034ce:       PNP0c0b (0x0b0cd041)
   5373 000034d3:     Method _INI (\_TZ_.FAN_._INI)
   5374 000034d9:       ArgCount 0; NotSerialized
   5375 000034da:       Store
   5376 000034db:         TP1H (000032ad)
   5377 000034df:         CTOS
   5378 000034e3:       Store
   5379 000034e4:         TP1L (000032b2)
   5380 000034e8:         CTHY


Thanks,
- Adachi, Kenichi



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: fan control

[Ducrot Bruno]

On Tue, May 06, 2003 at 07:56:06PM +0900, Adachi, Kenichi wrote:
> Hi,
> 
> > About fan control, I would love to be able to stop my fan, but it
> doesn't
> > work. I can echo anything to /proc/acpi/fan/FAN/state, it has no
> bearing
> > on the fan, and the only result is a line in the log:
> > > acpi_bus-0199 [18] acpi_bus_set_power    : Device is not power
> manageable
> > (kernel is 2.5.67)
> > 
> acpi_bus_set_power() complains that the target device is not enabled to
> be power managed as its "power_manageable" flag, which will be set for
> devices who have _PS0 or _PR0 in DSDT upon device enumeration, is
> __NOT__ set. And, indeed, your FAN device in DSDT doesn't explicitly
> list its power resource by _PR0 Object.
> 
>    5369 000034ba: Scope _TZ_ (\_TZ_)
>    5370 000034c2:   Device FAN_ (\_TZ_.FAN_)
>    5371 000034c9:     Name _HID (\_TZ_.FAN_._HID)
>    5372 000034ce:       PNP0c0b (0x0b0cd041)
>    5373 000034d3:     Method _INI (\_TZ_.FAN_._INI)
>    5374 000034d9:       ArgCount 0; NotSerialized
>    5375 000034da:       Store
>    5376 000034db:         TP1H (000032ad)
>    5377 000034df:         CTOS
>    5378 000034e3:       Store
>    5379 000034e4:         TP1L (000032b2)
>    5380 000034e8:         CTHY
> 

A way to go is to add the missing in the asl.
(Eric, I think it's better than the module I send you privately).

--- dsdt.dsl	2003/05/06 14:01:15	1.1
+++ dsdt.dsl	2003/05/06 14:11:40
@@ -319,12 +319,12 @@
     {
         Method (_MSG, 1, NotSerialized)
         {
-            Store (Local0, Local0)
+            Noop
         }
 
         Method (_SST, 1, NotSerialized)
         {
-            Store (Local0, Local0)
+            Noop
         }
     }
 
@@ -3035,7 +3035,6 @@
                         DISD (0x01)
                     }
 
-                    Store (Local0, Local0)
                 }
 
                 Method (_CRS, 0, NotSerialized)
@@ -3645,6 +3644,8 @@
         }
     }
 
+    Name (FANS, One)
+
     Method (FON, 0, NotSerialized)
     {
         SBYT (0x13, 0x46)
@@ -3653,6 +3654,7 @@
         SBYT (0x14, Local0)
         Store (GBYT (0x53), Local0)
         SBYT (0x13, Local0)
+	Store (One, FANS)
     }
 
     Method (FOFF, 0, NotSerialized)
@@ -3662,10 +3664,27 @@
         SBYT (0x14, 0xD0)
         Store (GBYT (0x13), Local0)
         SBYT (0x53, Local0)
+	Store (Zero, FANS)
     }
 
     Scope (\_TZ)
     {
+        PowerResource(PFAN,0,0)
+	{
+	    Method(_STA)
+	    {
+	        Return(\FANS)
+	    }
+	    Method(_ON)
+	    {
+	        \FON()
+	    }
+	    Method(_OFF)
+	    {
+	        \FOFF()
+	    }
+	
+	}
         Device (FAN)
         {
             Name (_HID, EisaId ("PNP0C0B"))
@@ -3674,6 +3693,7 @@
                 Store (TP1H, CTOS)
                 Store (TP1L, CTHY)
             }
+	    Name(_PR0, Package() { PFAN })
         }
 
         ThermalZone (THRM)

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com