[lm-sensors] Fancontrol

[lm-sensors] Fancontrol

[Henry]

Hi I'm using Lm sensors and fancontrol
I have not found a way to set constant CPU fan speed.

every time when the outside temperature drops the cpu fan stops then
starts and then stops.
this is very annoying I have to change the settings in
the /etc/fancontrol file when the weather changes

I'd like to see a feature where I can set the cpu fan speed to 3000 rpm
no matter what the cpu temperature is.
I know it can be dangerous with motherboards that don't have cpu
overheat protection but in many cases it would be useful

I don't use applications that demand high cpu load so low cpu fan speed
would be perfect to keep the noise down

Henry

[lm-sensors] Fancontrol

[Jim Cromie]

Henry wrote:

>Hi I'm using Lm sensors and fancontrol
>I have not found a way to set constant CPU fan speed.
>
>every time when the outside temperature drops the cpu fan stops then
>starts and then stops.
>this is very annoying I have to change the settings in
>the /etc/fancontrol file when the weather changes
>
>  
>
many fan-controller circuits are PWM, pulse width modulated.
these usually give a power knob with 256 steps, from 0 to full power.
Since you seem to not know whats on your board, guessing would be pointless.

have you tried compiling *all* the sensor modules, and seeing which ones 
are sensors-detect'd ?

[lm-sensors] Fancontrol

[Rudolf Marek]

Hello,

Perhaps what you want is to disable the automatic speed mamagement and force manual fixed speed.
Correct?

If so I would like to know what modules are you using - what chip you have.

Regards
Rudolf

[lm-sensors] Fancontrol

[Henry]

yes that's correct

My motherboard is:
MSI 865PE Neo2-F1S2R

Please let me know what aditional info do you need

Henry


On Tue, 2005-07-26 at 09:45 +0200, Rudolf Marek wrote:
> Hello,
> 
> Perhaps what you want is to disable the automatic speed mamagement and force manual fixed speed.
> Correct?
> 
> If so I would like to know what modules are you using - what chip you have.
> 
> Regards
> Rudolf

[lm-sensors] Fancontrol

[Rudolf Marek]

Please what modules are you using for monitoring?
If you dont know which one. Please include output of lsmod command and I will pick them up :)

Thanks

Regards

Rudolf

[lm-sensors] Fancontrol

[Henry]

here is the output of the lsmod command

Henry

On Wed, 2005-07-27 at 09:23 +0200, Rudolf Marek wrote:
> Please what modules are you using for monitoring?
> If you dont know which one. Please include output of lsmod command and I will pick them up :)
> 
> Thanks
> 
> Regards
> 
> Rudolf
-------------- next part --------------
Module                  Size  Used by
vfat                   16961  1 
fat                    44897  1 vfat
usb_storage            62857  0 
parport_pc             27777  1 
lp                     14893  0 
parport                40969  2 parport_pc,lp
autofs4                21700  0 
w83627hf               29161  0 
eeprom                 12385  0 
i2c_sensor              7489  2 w83627hf,eeprom
i2c_isa                 6081  0 
i2c_i801               11597  0 
i2c_dev                13249  0 
i2c_core               25921  6 w83627hf,eeprom,i2c_sensor,i2c_isa,i2c_i801,i2c_dev
sunrpc                136997  1 
dm_mod                 56773  0 
button                 10449  0 
battery                12485  0 
ac                      8773  0 
md5                     8001  1 
ipv6                  235105  14 
ohci1394               35033  0 
ieee1394              302965  1 ohci1394
joydev                 12545  0 
uhci_hcd               32729  0 
ehci_hcd               31941  0 
emu10k1_gp              7617  0 
gameport                8513  1 emu10k1_gp
snd_emu10k1            83529  0 
snd_rawmidi            27109  1 snd_emu10k1
snd_pcm_oss            50809  0 
snd_mixer_oss          20929  1 snd_pcm_oss
snd_pcm                89669  2 snd_emu10k1,snd_pcm_oss
snd_timer              27077  1 snd_pcm
snd_seq_device         11849  2 snd_emu10k1,snd_rawmidi
snd_ac97_codec         65169  1 snd_emu10k1
snd_page_alloc         13641  2 snd_emu10k1,snd_pcm
snd_util_mem            8641  1 snd_emu10k1
snd_hwdep              13125  1 snd_emu10k1
snd                    54821  9 snd_emu10k1,snd_rawmidi,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_seq_device,snd_ac97_codec,snd_hwdep
soundcore              12961  1 snd
e1000                  80205  0 
floppy                 57297  0 
ext3                  117961  4 
jbd                    59353  1 ext3
sata_promise           13509  0 
libata                 43077  1 sata_promise
sd_mod                 20289  0 
scsi_mod              112136  4 usb_storage,sata_promise,libata,sd_mod

[lm-sensors] Fancontrol

[Rudolf Marek]

Hello,

It seems the best would be to disable the fancontrol script it must load from /etc/
you can see it active with ps ax command.

Unfortunately I'm not very familiar with fancontrol stuff and I dont know your Linux distribution but here is general steps:

Steps for manual control:

1) disable (or delete fancontrol script that loads on startup of computer)
2) go to /sys/bus/i2c/devices/0-290/   (the directory 0-290 might be different, just inspect every directory in devices/ and find that one with "pwm1" ... files)
3) to change fan speed do: echo 128 > pwm1  (or pwm2 etc depends how is your fan connected, values are from 0=stop 255=fullspeed)
4) you can use pwmconfig to tell you the correlation values between fanspeed and PWM value.
5) put the echo ... > /sys/bus/....  line somewhere to startup scripts.

I hope this helps.

Regards

Rudolf

[lm-sensors] Fancontrol

[Henry]

On Thu, 2005-07-28 at 10:19 +0200, Rudolf Marek wrote:
> Hello,
> 
> It seems the best would be to disable the fancontrol script it must load from /etc/
> you can see it active with ps ax command.
> 
> Unfortunately I'm not very familiar with fancontrol stuff and I dont know your Linux distribution but here is general steps:
> 
> Steps for manual control:
> 
> 1) disable (or delete fancontrol script that loads on startup of computer)
> 2) go to /sys/bus/i2c/devices/0-290/   (the directory 0-290 might be different, just inspect every directory in devices/ and find that one with "pwm1" ... files)
> 3) to change fan speed do: echo 128 > pwm1  (or pwm2 etc depends how is your fan connected, values are from 0=stop 255=fullspeed)
> 4) you can use pwmconfig to tell you the correlation values between fanspeed and PWM value.
> 5) put the echo ... > /sys/bus/....  line somewhere to startup scripts.
> 
> I hope this helps.
> 
> Regards
> 
> Rudolf
> 

[lm-sensors] Fancontrol

[Henry]

Thanks

On Thu, 2005-07-28 at 10:19 +0200, Rudolf Marek wrote:
> Hello,
> 
> It seems the best would be to disable the fancontrol script it must load from /etc/
> you can see it active with ps ax command.
> 
> Unfortunately I'm not very familiar with fancontrol stuff and I dont know your Linux distribution but here is general steps:
> 
> Steps for manual control:
> 
> 1) disable (or delete fancontrol script that loads on startup of computer)
> 2) go to /sys/bus/i2c/devices/0-290/   (the directory 0-290 might be different, just inspect every directory in devices/ and find that one with "pwm1" ... files)
> 3) to change fan speed do: echo 128 > pwm1  (or pwm2 etc depends how is your fan connected, values are from 0=stop 255=fullspeed)
> 4) you can use pwmconfig to tell you the correlation values between fanspeed and PWM value.
> 5) put the echo ... > /sys/bus/....  line somewhere to startup scripts.
> 
> I hope this helps.
> 
> Regards
> 
> Rudolf
> 

[lm-sensors] Fancontrol

[Henry]

will the echo ...>/sys/busi2c/...  have any effect when I kill
the /sbin/fancontrol script?
I mean will it control the fan?

I thought that all those files are for the fancontrol script to operate.
If I kill the fancontrol script then no matter what the values are in in
the files the fan is still spinning like crazy

Henry 
On Thu, 2005-07-28 at 10:19 +0200, Rudolf Marek wrote:
> Hello,
> 
> It seems the best would be to disable the fancontrol script it must load from /etc/
> you can see it active with ps ax command.
> 
> Unfortunately I'm not very familiar with fancontrol stuff and I dont know your Linux distribution but here is general steps:
> 
> Steps for manual control:
> 
> 1) disable (or delete fancontrol script that loads on startup of computer)
> 2) go to /sys/bus/i2c/devices/0-290/   (the directory 0-290 might be different, just inspect every directory in devices/ and find that one with "pwm1" ... files)
> 3) to change fan speed do: echo 128 > pwm1  (or pwm2 etc depends how is your fan connected, values are from 0=stop 255=fullspeed)
> 4) you can use pwmconfig to tell you the correlation values between fanspeed and PWM value.
> 5) put the echo ... > /sys/bus/....  line somewhere to startup scripts.
> 
> I hope this helps.
> 
> Regards
> 
> Rudolf
> 

[lm-sensors] Fancontrol

[Henry]

Thanks this trick works!!!!

Henry

On Thu, 2005-07-28 at 10:19 +0200, Rudolf Marek wrote:
> Hello,
> 
> It seems the best would be to disable the fancontrol script it must load from /etc/
> you can see it active with ps ax command.
> 
> Unfortunately I'm not very familiar with fancontrol stuff and I dont know your Linux distribution but here is general steps:
> 
> Steps for manual control:
> 
> 1) disable (or delete fancontrol script that loads on startup of computer)
> 2) go to /sys/bus/i2c/devices/0-290/   (the directory 0-290 might be different, just inspect every directory in devices/ and find that one with "pwm1" ... files)
> 3) to change fan speed do: echo 128 > pwm1  (or pwm2 etc depends how is your fan connected, values are from 0=stop 255=fullspeed)
> 4) you can use pwmconfig to tell you the correlation values between fanspeed and PWM value.
> 5) put the echo ... > /sys/bus/....  line somewhere to startup scripts.
> 
> I hope this helps.
> 
> Regards
> 
> Rudolf
> 

Re: [lm-sensors] fancontrol

[Jean Delvare]

Hi Sergio,

It's a long long time since I last heard of Marius, I don't know if he
still cares about fancontrol.

OTOH we have a mailing list where this kind of inquiry should be sent,
so that others can comment and generally participate. I'm adding it to
Cc.

On Wed, 25 Mar 2009 05:02:56 +0300, sergio wrote:
> Hello Marius and Jean.
> 
> Sensors for fancontrol configures via hwmonN.
> But N depends on modules load order.

This is correct. This has been discussed on the mailing list recently:
http://lists.lm-sensors.org/pipermail/lm-sensors/2009-January/025195.html

> fancontrol should use chip name for configuration

This would indeed help a lot, although not all chip names are stable
either. All *-i2c-* and *-spi-* names depend in part of the module
loading order of i2c and spi bus drivers, respectively.

> I think there are to ways for fix this.
> 1) use sysfsutils (or do this manually)

No, no, no. Sysfsutils is dead, please let it rest it peace. Not that I
really understand what you'd have done with it anyway...

> 2) rewrite it on c and use lmsensors library

This is a possibility, yes. I do not particularly love bash scripts
when they exceed a hundred lines, so I wouldn't necessarily object to
a rewrite. That being said, the script approach has the advantage that
it is extremely easy for users to customize for their own needs. They
don't have to download the sources and rebuild a binary. For a fan
control script this seems to have value. Users might miss this
flexibility if we switch to C. One advantage though is that fancontrol
would finally honor temperature adjustments made in sensors.conf.

A third possibility which was discussed in the thread I mentioned above
is a helper binary, linked with libsensors, which would take care of
translating hwmonN names to libsensors chip names and back. This could
be a special option of "sensors" or be implemented as a standalone
binary. This would make it possible for all scripts (pwmconfig,
fancontrol and possibly others) to work with libsensors chip names.
This should be fairly easy to implement, but OTOH this only addresses
one of the weaknesses of script-based sensors access. You'll still miss
all the other libsensors goodies (labels, ignores, temperature
adjustments etc.) unless the helper binary in question also offers an
interface to individual sensor values.

A fourth possibility is to let the user force the hwmonN number when
loading each hwmon driver, similar to what V4L drivers do. While this
works fine for experimented users, this can't be easily automated, so
it won't help mainstream users. So I suspect this would be a lot of
work for a very small benefit.

A fifth possibility is to try harder to always load the hwmon drivers
in the same order. In this respect, lm-sensors 3.1.0 should behave much
better than previous versions did. Did you give it a try?

> How can i help?
> I can try to rewrite it to c...

Honestly, I am not sure if it makes much sense to rewrite fancontrol as
it exists today in C. fancontrol is very limited in what it can do and
the conditions it checks. There are other control daemons out there
which are much more flexible, as they can change behaviors not only
based on temperature, and they can change a lot more settings than just
fan speeds. So, instead of rewriting fancontrol, I'd rather work on
integrating sensors better in existing daemons.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] fancontrol

[sergio]

Jean Delvare wrote:

> That being said, the script approach has the advantage that
> it is extremely easy for users to customize for their own needs. They
> don't have to download the sources and rebuild a binary. For a fan
> control script this seems to have value. Users might miss this
> flexibility if we switch to C. One advantage though is that fancontrol
> would finally honor temperature adjustments made in sensors.conf.
Another advantage, that it's more simple to include it in embedded
system. Current fancontrol doesn't work in busybox or dash.
I don't believe, that shell is good for daemons.

> A third possibility which was discussed in the thread I mentioned above
> is a helper binary, linked with libsensors, which would take care of
> translating hwmonN names to libsensors chip names and back.
IMHO this is worst way.

> A fifth possibility is to try harder to always load the hwmon drivers
> in the same order. In this respect, lm-sensors 3.1.0 should behave much
> better than previous versions did. Did you give it a try?
I have two similar machines with identical sensors. One with debian
lenny (3.0.2) other with sid (3.1.0). The sensors are: acpitz, k8temp
and it8718. On both machines acpitz and k8temp loads automagically and
it8718 from /etc/modules. If k8temp also present in /etc/modules it is
don't matter in which order this modules are written in this file.
acpitz always will hwmon0, k8temp -> hwmon1, and it8718 -> hwmon1 (if it
present in modules)
What difference should i see?

(Really, on machine with lenny it87 loads via force_load in
initramfs-tools hook, so it87 is (always?) first.)

So hwmon names jumping it's not very big problem for me.
It is never happens unexpectedly. Only when i change or upgrade something.

> Honestly, I am not sure if it makes much sense to rewrite fancontrol as
> it exists today in C. fancontrol is very limited in what it can do and
> the conditions it checks. There are other control daemons out there
> which are much more flexible, as they can change behaviors not only
> based on temperature, and they can change a lot more settings than just
> fan speeds. So, instead of rewriting fancontrol, I'd rather work on
> integrating sensors better in existing daemons.
OK. Let's leave fancontrol as simple script. But i don't know any other
fan control daemon. Can you give examples of such programs?

May be should add possibility to define real path to device 
(/sys/devices/platform/it87.552)?
Or this path isn't always identical?
(And not all hwmons has a device)

And what about udev for name stabilizing?
 > The usual solution (udev) doesn't work for us because hwmon devices
 > have no device nodes in /dev, only a sysfs interface.
Network interfaces is not present in /dev, but udev takes care about 
they names.

-- 
sergio

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] fancontrol

[Jean Delvare]

On Wed, 25 Mar 2009 18:33:04 +0300, sergio wrote:
> Jean Delvare wrote:
> 
> > That being said, the script approach has the advantage that
> > it is extremely easy for users to customize for their own needs. They
> > don't have to download the sources and rebuild a binary. For a fan
> > control script this seems to have value. Users might miss this
> > flexibility if we switch to C. One advantage though is that fancontrol
> > would finally honor temperature adjustments made in sensors.conf.
> Another advantage, that it's more simple to include it in embedded
> system. Current fancontrol doesn't work in busybox or dash.
> I don't believe, that shell is good for daemons.

Honestly, fan speed control under busybox doesn't strike me as the most
needed feature.

> > A third possibility which was discussed in the thread I mentioned above
> > is a helper binary, linked with libsensors, which would take care of
> > translating hwmonN names to libsensors chip names and back.
> IMHO this is worst way.

Why that?

> > A fifth possibility is to try harder to always load the hwmon drivers
> > in the same order. In this respect, lm-sensors 3.1.0 should behave much
> > better than previous versions did. Did you give it a try?
> I have two similar machines with identical sensors. One with debian
> lenny (3.0.2) other with sid (3.1.0). The sensors are: acpitz, k8temp
> and it8718. On both machines acpitz and k8temp loads automagically and
> it8718 from /etc/modules. If k8temp also present in /etc/modules it is
> don't matter in which order this modules are written in this file.
> acpitz always will hwmon0, k8temp -> hwmon1, and it8718 -> hwmon1 (if it
> present in modules)

I presume you mean it8718 -> hwmon2.

> What difference should i see?

On Debian, none. The improvement is only for distributions where
lm_sensors is a service which loads the required kernel modules when
started and removes them when stopped. Debian doesn't work that way, so
it shouldn't be affected by the problem in the first place.

> (Really, on machine with lenny it87 loads via force_load in
> initramfs-tools hook, so it87 is (always?) first.)

What is force_load? And why do you need it?

> So hwmon names jumping it's not very big problem for me.

Why are you reporting it then?

> It is never happens unexpectedly. Only when i change or upgrade something.

"change or upgrade something" is simply too vague for me to do anything
useful with the information.

> > Honestly, I am not sure if it makes much sense to rewrite fancontrol as
> > it exists today in C. fancontrol is very limited in what it can do and
> > the conditions it checks. There are other control daemons out there
> > which are much more flexible, as they can change behaviors not only
> > based on temperature, and they can change a lot more settings than just
> > fan speeds. So, instead of rewriting fancontrol, I'd rather work on
> > integrating sensors better in existing daemons.
> OK. Let's leave fancontrol as simple script. But i don't know any other
> fan control daemon. Can you give examples of such programs?

What I had in mind was cpufreqd:
http://freshmeat.net/projects/cpufreqd

As far as I remember it already supports temperature values as inputs,
and its configuration file was pretty flexible so adding fan speed
control shouldn't be that hard.

There may be other similar daemons that can be extended. Or feel free
to start your own, but then pretty please make its configuration file
much more flexible and clear than fancontrol's one. Shouldn't be too
hard ;) If you come up with something really good then I will be happy
to kill the pwmconfig and fancontrol scripts in favor of your work.

> May be should add possibility to define real path to device 
> (/sys/devices/platform/it87.552)?

This is a possibility, yes, and it shouldn't be too hard to implement.
Want to give it a try?

> Or this path isn't always identical?

Depends. For platform devices it should be totally stable. For I2C
devices the I2C adapter number may change. But it's a lot more stable
than hwmon# numbers either way.

> (And not all hwmons has a device)

This is correct. For hwmon without a device, obviously the hwmon# class
device is the only way if you don't take the libsensors route.

> And what about udev for name stabilizing?
>  > The usual solution (udev) doesn't work for us because hwmon devices
>  > have no device nodes in /dev, only a sysfs interface.
> Network interfaces is not present in /dev, but udev takes care about 
> they names.

Tell me about it. It's a nightmare, we keep getting bug reports about
it. Not to say that it can't be done properly for hwmon devices. But do
you have some concrete proposal? "Let's just use udev" doesn't tell me
much.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] fancontrol

[sergio]

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

Jean Delvare wrote:

> Honestly, fan speed control under busybox doesn't strike me as the most
> needed feature.
Why? Many home nas'es and high performance routers have a fan.

>>> A third possibility which was discussed in the thread I mentioned above
>>> is a helper binary, linked with libsensors, which would take care of
>>> translating hwmonN names to libsensors chip names and back.
>> IMHO this is worst way.
> Why that?
It's look like a crutch.

>> ... If k8temp also present in /etc/modules it is
>> don't matter in which order this modules are written in this file.
>> acpitz always will hwmon0, k8temp -> hwmon1, and it8718 -> hwmon1 (if it
>> present in modules)
> I presume you mean it8718 -> hwmon2.
Yes.

>> (Really, on machine with lenny it87 loads via force_load in
>> initramfs-tools hook, so it87 is (always?) first.)
> What is force_load? And why do you need it?
force_load is function for initramfs-tools hook script (which runs at
build time). It adds a module (and its dependencies) to the initramfs
image and also unconditionally loads the module during boot.
I need it for speed down fan, because it very noisy. Why i need do it at
initrd time? This initrd waits for password for encrypted rootfs...

>> So hwmon names jumping it's not very big problem for me.
> Why are you reporting it then?
Because the problem exists. And i would like that it was not.

>> It is never happens unexpectedly. Only when i change or upgrade something.
> "change or upgrade something" is simply too vague for me to do anything
> useful with the information.
I said this in support of the above-said. I understand which my actions
(and real reason) leads to name changing. But i don't memorize it.

> There may be other similar daemons that can be extended.
So, now only fancontrol can manage fan speed.

> Or feel free to start your own, but then pretty please make its
> configuration file much more flexible and clear than fancontrol's one.
> Shouldn't be too hard ;) If you come up with something really good then I
> will be happy to kill the pwmconfig and fancontrol scripts in favor of your work.
OK.

>> May be should add possibility to define real path to device 
>> (/sys/devices/platform/it87.552)?
> This is a possibility, yes, and it shouldn't be too hard to implement.
> Want to give it a try?
See attachment.

> Not to say that it can't be done properly for hwmon devices. But do
> you have some concrete proposal? "Let's just use udev" doesn't tell me
> much.
I don't clearly understand how udev works.


-- 
sergio




[-- Attachment #2: fancontrol.patch.bz2 --]
[-- Type: application/octet-stream, Size: 905 bytes --]

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] fancontrol

[Jean Delvare]

Hi Sergio,

On Fri, 27 Mar 2009 06:03:20 +0300, sergio wrote:
> Jean Delvare wrote:
> 
> > Honestly, fan speed control under busybox doesn't strike me as the most
> > needed feature.
> Why? Many home nas'es and high performance routers have a fan.

And they need it to be software controlled? I doubt it. I'd expect them
to either have low-speed fans that don't need control, or if they need
control, I'd expect hardware control (either thermostatic or
finer-grained but controlled by the hardware monitoring chip itself.)
Anything else would be bad design.

Do you actually know of one NAS or router running busybox and needing
software-based fan speed control? Or is this just a theory?

> >>> A third possibility which was discussed in the thread I mentioned above
> >>> is a helper binary, linked with libsensors, which would take care of
> >>> translating hwmonN names to libsensors chip names and back.
> >> IMHO this is worst way.
> > Why that?
> It's look like a crutch.

Apparently I wasn't clear but I expected a detailed explanation. "I
don't like it" alone doesn't qualify, and thus doesn't let us make any
progress towards a solution.

> >> (Really, on machine with lenny it87 loads via force_load in
> >> initramfs-tools hook, so it87 is (always?) first.)
> > What is force_load? And why do you need it?
> force_load is function for initramfs-tools hook script (which runs at
> build time). It adds a module (and its dependencies) to the initramfs
> image and also unconditionally loads the module during boot.

That's kind of a misnomer, as it isn't forcing anything. It just load
the driver early.

> I need it for speed down fan, because it very noisy. Why i need do it at
> initrd time? This initrd waits for password for encrypted rootfs...

OK, I understand your setup now. But I fail to see how the it87 driver
alone helps. Loading the it87 driver shouldn't change any fan speed. So
I suppose that you also included the fancontrol script in your
initramfs, or maybe some custom script just slowing down one fan?

> >> So hwmon names jumping it's not very big problem for me.
> > Why are you reporting it then?
> Because the problem exists. And i would like that it was not.

> > There may be other similar daemons that can be extended.
> So, now only fancontrol can manage fan speed.

This isn't what I said, and this isn't correct. Just search for "fan
control" on Freshmeat for example, it returns a number of projects. And
there may be more, but please don't expect me to do your homework. I
simply do not have the time for this.

> >> May be should add possibility to define real path to device 
> >> (/sys/devices/platform/it87.552)?
> > This is a possibility, yes, and it shouldn't be too hard to implement.
> > Want to give it a try?
> See attachment.

Please don't compress patches, it only makes them harder to review.

Review:

> diff -Naur lm_sensors-3.1.0.orig/doc/fancontrol.txt lm_sensors-3.1.0/doc/fancontrol.txt
> --- lm_sensors-3.1.0.orig/doc/fancontrol.txt	2009-01-29 11:58:36.000000000 +0300
> +++ lm_sensors-3.1.0/doc/fancontrol.txt	2009-03-27 05:42:12.000000000 +0300
> @@ -99,10 +99,9 @@
>  VARIABLE2=[...]
>  
>  Each variable has its own line. The variable name is followed by an equal sign
> -and the device=value pairs. These consist of the relative path to the pwm
> -output (from /sys/bus/i2c/devices or /sys/class/hwmon depending on the kernel
> -version) for which the value is valid, equal sign followed by the value and
> -are separated by a blank.
> +and the device=value pairs. These consist of the path to the pwm output for
> +which the value is valid, equal sign followed by the value and are separated
> +by a blank. Path can be absolute or relative (from /sys/bus/i2c/devices or /sys/class/hwmon depending on the kernel version).

Please fold long lines.

>  
>  Example:
>  
> diff -Naur lm_sensors-3.1.0.orig/prog/pwm/fancontrol lm_sensors-3.1.0/prog/pwm/fancontrol
> --- lm_sensors-3.1.0.orig/prog/pwm/fancontrol	2009-02-28 22:42:51.000000000 +0300
> +++ lm_sensors-3.1.0/prog/pwm/fancontrol	2009-03-27 05:58:30.000000000 +0300
> @@ -159,8 +159,11 @@
>  	LoadConfig /etc/fancontrol
>  fi
>  
> -# Detect if config file uses the hwmon class or not yet
> -if echo "${AFCPWM[0]}" | egrep -q '^hwmon[0-9]'
> +# Detect path to sensors
> +if echo "${AFCPWM[0]}" | egrep -q '^/'
> +then
> +	DIR=/
> +elif echo "${AFCPWM[0]}" | egrep -q '^hwmon[0-9]'
>  then
>  	DIR=/sys/class/hwmon
>  else

Simple enough, the only drawback is that you can't mix absolute and
relative paths in the same configuration file. As not all hwmon class
devices have a device backing them up, this could be a problem for some
users.

Maybe it is the right time to rework this part of the script and
resolve each path in the configuration file separately. Absolute paths
would stay as is, and relative paths would be prefixed with
either /sys/class/hwmon/ (if they start with hwmon[0-9])
or /sys/bus/i2c/devices/ (if they don't).

Also, to be truly useful for users, the possibility to use absolute
paths should be used by the pwmconfig script, by following and
resolving the device link of hwmon class devices before writing the
configuration file. Care to give it a try?

> diff -Naur lm_sensors-3.1.0.orig/prog/pwm/fancontrol.8 lm_sensors-3.1.0/prog/pwm/fancontrol.8
> --- lm_sensors-3.1.0.orig/prog/pwm/fancontrol.8	2009-01-29 11:58:36.000000000 +0300
> +++ lm_sensors-3.1.0/prog/pwm/fancontrol.8	2009-03-27 01:01:06.000000000 +0300
> @@ -81,10 +81,9 @@
>  .fi
>  .PP
>  Each variable has its own line. The variable name is followed by an equal sign
> -and the device=value pairs. These consist of the relative path to the pwm
> -output (from /sys/bus/i2c/devices or /sys/class/hwmon
> -depending on the kernel version) for which the value is valid, equal sign
> -followed by the value and are separated by a blank. Example:
> +and the device=value pairs. These consist of the path to the pwm output for
> +which the value is valid, equal sign followed by the value and are separated
> +by a blank. Path can be absolute or relative (from /sys/bus/i2c/devices or /sys/class/hwmon depending on the kernel version). Example:

Please fold long lines.

>  .IP
>  MINTEMP=w83627hf-isa-0290/pwm2@ w83627hf-isa-0290/pwm1T

Totally outdated example, BTW, it should be updated.

>  .PP


> > Not to say that it can't be done properly for hwmon devices. But do
> > you have some concrete proposal? "Let's just use udev" doesn't tell me
> > much.
> I don't clearly understand how udev works.

OK, so it was just hand-waiving. Wonderful.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] fancontrol

[sergio]

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

Hi Jean.


> Do you actually know of one NAS or router running busybox and needing
> software-based fan speed control? Or is this just a theory?
Theory.

>> force_load is function for initramfs-tools hook script...
> That's kind of a misnomer, as it isn't forcing anything.
May be, you can suggest the better name?
 > It just load the driver early.
Yes.

> OK, I understand your setup now. But I fail to see how the it87 driver
> alone helps. Loading the it87 driver shouldn't change any fan speed. So
> I suppose that you also included the fancontrol script in your
> initramfs, or maybe some custom script just slowing down one fan?
simple echo

> Please don't compress patches, it only makes them harder to review.
ok

> Please fold long lines.
Excuse me, i don't pay attention.

 > As not all hwmon class devices have a device backing them up, this
 > could be a problem for some users.
But it is possible to specify absolute path for them.

> Also, to be truly useful for users, the possibility to use absolute
> paths should be used by the pwmconfig script, by following and
> resolving the device link of hwmon class devices before writing the
> configuration file. Care to give it a try?
I know. This fix is very simple and quick.
Path mixing and pwmconfig is not so easy to fix.
But not only paths should be reworked. Pid file is hardcoded. Egrep is 
deprecated. Configuration file is not very simple. Maybe it is the right 
time to rework whole fancontrol and pwmconfig. Or it will be better to 
save time for write new daemon. I can't find any suitable one of some 
which can be extended.

>>> Not to say that it can't be done properly for hwmon devices. But do
>>> you have some concrete proposal? "Let's just use udev" doesn't tell me
>>> much.
>> I don't clearly understand how udev works.
> OK, so it was just hand-waiving. Wonderful.
I was interested in you opinion about udev, no more.

-- 
sergio

[-- Attachment #2: fancontrol.patch --]
[-- Type: text/x-diff, Size: 2976 bytes --]

diff -Naur lm_sensors-3.1.0.orig/doc/fancontrol.txt lm_sensors-3.1.0/doc/fancontrol.txt
--- lm_sensors-3.1.0.orig/doc/fancontrol.txt	2009-01-29 11:58:36.000000000 +0300
+++ lm_sensors-3.1.0/doc/fancontrol.txt	2009-03-27 18:04:23.000000000 +0300
@@ -99,14 +99,14 @@
 VARIABLE2=[...]
 
 Each variable has its own line. The variable name is followed by an equal sign
-and the device=value pairs. These consist of the relative path to the pwm
-output (from /sys/bus/i2c/devices or /sys/class/hwmon depending on the kernel
-version) for which the value is valid, equal sign followed by the value and
-are separated by a blank.
+and the device=value pairs. These consist of the path to the pwm output for
+which the value is valid, equal sign followed by the value and are separated
+by a blank. Path can be absolute or relative (from /sys/bus/i2c/devices or
+/sys/class/hwmon depending on the kernel version).
 
 Example:
 
-MINTEMP=w83627hf-isa-0290/pwm2=40 w83627hf-isa-0290/pwm1=54
+MINTEMP=hwmon0/device/pwm1=40 hwmon0/device/pwm2=54
 
 You have to play with the temperature values a bit to get happy. For initial
 setup I recommend using the pwmconfig script. Small changes can be made by
diff -Naur lm_sensors-3.1.0.orig/prog/pwm/fancontrol lm_sensors-3.1.0/prog/pwm/fancontrol
--- lm_sensors-3.1.0.orig/prog/pwm/fancontrol	2009-02-28 22:42:51.000000000 +0300
+++ lm_sensors-3.1.0/prog/pwm/fancontrol	2009-03-27 17:55:40.000000000 +0300
@@ -159,8 +159,11 @@
 	LoadConfig /etc/fancontrol
 fi
 
-# Detect if config file uses the hwmon class or not yet
-if echo "${AFCPWM[0]}" | egrep -q '^hwmon[0-9]'
+# Detect path to sensors
+if echo "${AFCPWM[0]}" | egrep -q '^/'
+then
+	DIR=/
+elif echo "${AFCPWM[0]}" | egrep -q '^hwmon[0-9]'
 then
 	DIR=/sys/class/hwmon
 else
diff -Naur lm_sensors-3.1.0.orig/prog/pwm/fancontrol.8 lm_sensors-3.1.0/prog/pwm/fancontrol.8
--- lm_sensors-3.1.0.orig/prog/pwm/fancontrol.8	2009-01-29 11:58:36.000000000 +0300
+++ lm_sensors-3.1.0/prog/pwm/fancontrol.8	2009-03-27 18:05:36.000000000 +0300
@@ -81,12 +81,12 @@
 .fi
 .PP
 Each variable has its own line. The variable name is followed by an equal sign
-and the device=value pairs. These consist of the relative path to the pwm
-output (from /sys/bus/i2c/devices or /sys/class/hwmon
-depending on the kernel version) for which the value is valid, equal sign
-followed by the value and are separated by a blank. Example:
+and the device=value pairs. These consist of the path to the pwm output for
+which the value is valid, equal sign followed by the value and are separated
+by a blank. Path can be absolute or relative (from /sys/bus/i2c/devices or
+/sys/class/hwmon depending on the kernel version). Example:
 .IP
-MINTEMP=w83627hf-isa-0290/pwm2=40 w83627hf-isa-0290/pwm1=54
+MINTEMP=hwmon0/device/pwm1=40 hwmon0/device/pwm2=54
 .PP
 You have to play with the temperature values a bit to get happy. For initial
 setup I recommend using the \fBpwmconfig\fP script. Small changes can be made by

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] fancontrol

[Jean Delvare]

Hi Sergio,

Sorry for the late answer, this one felt under the radar.

On Fri, 27 Mar 2009 19:30:49 +0300, sergio wrote:
> >> force_load is function for initramfs-tools hook script...
> > That's kind of a misnomer, as it isn't forcing anything.
> May be, you can suggest the better name?
>  > It just load the driver early.
> Yes.

"load_early" would seem like a reasonable name then.

> > Also, to be truly useful for users, the possibility to use absolute
> > paths should be used by the pwmconfig script, by following and
> > resolving the device link of hwmon class devices before writing the
> > configuration file. Care to give it a try?
>
> I know. This fix is very simple and quick.
> Path mixing and pwmconfig is not so easy to fix.
> But not only paths should be reworked. Pid file is hardcoded.

Didn't seem to cause trouble to anyone so far.

> Egrep is deprecated.

Didn't know that. Replacing all instances of "egrep" with "grep -E"
should fix it, shouldn't it?

> Configuration file is not very simple.

It's both too simple from a syntax perspective, and too hard to read
and inflexible as a result, I agree :(

> Maybe it is the right 
> time to rework whole fancontrol and pwmconfig. Or it will be better to 
> save time for write new daemon. I can't find any suitable one of some 
> which can be extended.

This is your time, feel free to spend it any way you like ;)

I've applied your patch, thanks for your contribution.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[lm-sensors] fancontrol

[Ioan Rusan]

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

Hello

   I writhed for my fun a fancontrol in C. Currently is do only managing 
speed fan and detect startup value and stop value for fans (for example, 
my cpu fan is stoping at 18 and start at value 30 set in pwm file).
In the future I want to implement:
- control fan reading hdd temp (currently is using only fans that are 
visible in /sys/class/hwmon/*)
- detect fan controlers
- detect GPU temp (this is a plan for far far away time)
- save settings in files
- use multiple temp sensors (for example, use mb sensors...for normal 
operations, but if CPU temp si jumping a trigger value...speed all case 
fans - usefull if cpu heat sink is good, but you need and a good airflow 
in case)
- a nice gui for fans/sensors (this is a plan to start in 
october-november...)
  

If lm-sensors team are interested about this, please announce me. To 
know if is worth to make some cosmetics for apps etc.

The current code is working almost...without erros.
I attached a older version (currently, the new version is not on my 
laptop..)

Ioan Rusan


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: main.c --]
[-- Type: text/x-csrc; name="main.c", Size: 8971 bytes --]

#include "main.h"
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(int argc, char **argv){
    char *config_file;
    int i;
    int autoload = 0;
    int autodetect = 0;
    int ii = 0;
    config_file = NULL;
    if(argc < 2){
	printf("Usage: fanmanager --config full_path_to_config_file\n");
	exit(-1);
    }
    for(i = 0; i < argc; i++){
	if(strstr(argv[i], "--config") != 0)
	    config_file = argv[i+1];
	if(strstr(argv[i], "--autoload") != 0)
	    autoload = atoi(argv[i+1]);
	if(strstr(argv[i], "--autodetect") != 0)
	    autodetect = 1;
	if(strstr(argv[i], "--detect_startup") !=0)
	  autodetect = 2;
    }
    if(config_file == NULL){
      printf("There are no config file!\n");
      exit(0);
    }
    if(load_fan_settings(config_file) !=0){
      printf("Error loading config file");
      exit(0);
    }
    printf("Enable fan control for %d fans...\n", number_of_fans);
    enable_fan_control();
    if(autodetect == 1){
	autodetect_fan_range();
	exit(0);
    }
    if(autodetect == 2){
      detect_startup_value();
      exit(0);
    }
    for(;;){
	system("clear");
	if(autoload !=0){
	    ii++;
	    if(ii == autoload){
		load_fan_settings(config_file);
	        ii = 0;
	    }
	}

	for(i = 0; i <= number_of_fans; i++){
	    load_fan_status(i);
	}
	calc_fan_speed();
	for(i = 0; i <= number_of_fans; i++){
	    printf("Temp: %d, min_speed: %d, start_speed: %d, max_temp = %d, current_fan_speed %d, current_fan_rpm %d, \noutput_fan_speed %s, input_temp_sensor %s, input_fan_speed %s\n", fan[i].current_temp, fan[i].min_speed, fan[i].start_temp, fan[i].max_temp, fan[i].current_fan_speed, fan[i].fan_rpm, fan[i].output_fan_speed, fan[i].input_temp_sensor, fan[i].input_fan_speed);
	}
	for(i = 0; i <= number_of_fans; i++)
	    set_fan_speed(i);
        usleep(300000);
    }
    return 0;
}

int autodetect_fan_range(){
  int i;
  int found = 0;
  int half, last_min, min;
  for (i = 0;  number_of_fans >= i; i++){
    last_min = 255;
    fan[i].current_fan_speed = 255;
    fan[i].min_speed = 255;
    set_fan_speed(i);
	printf("SpeedUp fan %d\n", i);
    sleep(5);
    min = 255;
    do{
	fan[i].current_fan_speed--;
	if(set_fan_speed(i) != 0){
	  printf("Error setting new speed\n");
	  break;
	}
	sleep(1);
	load_fan_status(i);
	printf("rpm: %d, fan_speed %d\n", fan[i].fan_rpm, fan[i].current_fan_speed);
	if(fan[i].fan_rpm == 0){
	    found = 1;
	    fan[i].min_speed = fan[i].current_fan_speed+1;
	}else
	    found = 0;
    }while(found == 0);
  }
}

int detect_startup_value(){
  int i,ii;
  for(i = 0; number_of_fans >= i; i++){
    fan[i].current_fan_speed = 0;
    set_fan_speed(i);
    printf("Wait for fans to stop");
    sleep(5);
    for(ii = 0; ii < 255; ii++){
      	printf("rpm: %d, fan_speed %d\n", fan[i].fan_rpm, fan[i].current_fan_speed);
      fan[i].current_fan_speed = ii;
      set_fan_speed(i);
      sleep(1);
      load_fan_status(i);
      if(fan[i].fan_rpm > 0){
	fan[i].min_speed = ii;
	printf("Fan %d is starting at value %d", i, ii);
	ii = 255;
      }
    }
  }
}

int enable_fan_control(){
  FILE *fp;
  char *file_name, *int_point;
  int i;
  file_name = (char *) malloc(1024);
  printf("%d\n", number_of_fans);
  for(i = 0; number_of_fans >= i; i++){
    memcpy(file_name, fan[i].output_fan_speed, strlen(fan[i].output_fan_speed));
    int_point = file_name+strlen(fan[i].output_fan_speed);
    memcpy(int_point, "_enable", 8);
    printf("Enable for %s\n", file_name);
    fp = fopen(file_name, "w");
    if(fp == NULL){
      printf("Enable fan %d failed\n", i);
    }
    fwrite("1", 1, 1, fp);
    fclose(fp);
  }
  free(file_name);
  return 0;
  
}
char *extract_value(char *string){
    char *buffer;
    char *buffer1;
    char *val;
    int first = 0;
    buffer1 = (char *) malloc(1024);
    buffer = (char *) malloc(1024);
    memcpy(buffer1, string, 1023);
    strtok(buffer1, "=");
    while (buffer != NULL){
	val = strtok(NULL, "=");
	if(strlen(val) < 1023)
	    memcpy(buffer, val, strlen(val));
	else
	    memcpy(buffer, val, 1023);
	free(buffer1);
	return buffer;
    }
    free(buffer1);
}

int load_fan_settings(char *file_config){
    FILE *fp;
    char *line;
    char *buffer;
    int fan_number = 0;
    int check = 7;
    fp = fopen(file_config, "r");
    line = (char *) malloc(1024);
    number_of_fans = -1;
    while(!feof(fp)){
      memset(line, 0, 1023);
      fgets(line, 1023, fp);
      buffer = extract_value(line);
      if(strstr(line, "SENSOR=") != 0){
	if(check < 7){
	  prinf("configuration file with erros for sensor %d", number_of_fans);
	  exit(-1);
	}
	check = 7;
	number_of_fans++;
	fan_number = (atoi(buffer)-1);
	if(fan_number < 0)
	    exit(-2);
	if(number_of_fans > 0)
	    fan = (fans *) realloc(fan, (number_of_fans + 1) * sizeof(fans));
	else
	    fan = (fans *) calloc((number_of_fans + 1), sizeof(fans));
	fan[fan_number].fan_id = fan_number;
      }
      fan[fan_number].max_temp = 50;
      fan[fan_number].min_temp = 30;
      fan[fan_number].min_speed = 255;
	if(strstr(line, "MAX_TEMP") != NULL){
	  if(atoi(buffer) < 255){
	    fan[fan_number].max_temp = atoi(buffer);
	    check++;
	  }else{
	    printf("for MAX_TEMP range is 0 to 255\n");
	    exit(-1);
	  }
	}
	if(strstr(line, "MIN_TEMP") != NULL){
	  if(atoi(buffer) < 255){
	    fan[fan_number].start_temp = atoi(buffer);
	    check++;
	  }else{
	    printf("for MIN_TEMP range is 0 to 255\n");
	    exit(-1);
	  }
	}
	if(strstr(line, "MIN_SPEED") != NULL){
	  if(atoi(buffer) < 255){
	    fan[fan_number].min_speed = atoi(buffer);
	    check++;
	  }else{
	    printf("for MIN_SPEED range is 0 to 255\n");
	    exit(-1);
	  }
	}
	if(strstr(line, "TEMP_INPUT") != NULL){
	    memcpy(fan[fan_number].input_temp_sensor, buffer, strlen(buffer) - 1);
	    check++;
	}
	if(strstr(line, "OUTPUT_FAN") != NULL){
	    memcpy(fan[fan_number].output_fan_speed, buffer, strlen(buffer) - 1);
	    check++;
	}
	if(strstr(line, "INPUT_FAN") != NULL){
	    memcpy(fan[fan_number].input_fan_speed, buffer, strlen(buffer) - 1);
	    check++;
	}
	if(strstr(line, "LINIAR_FAN") != NULL){
	    fan[fan_number].liniar_fan = atoi(buffer);
	    check++;
	}
    }
    if(check < 7){
      printf("error in config file\n");
      exit(-1);
    }
    free(line);
    return 0;
}

int set_fan_speed(int fan_number){
    FILE *fp;
    char *mem_zone;
    mem_zone = (char *) calloc(255, 1);
    sprintf(mem_zone, "%d", fan[fan_number].current_fan_speed);
    fp = fopen(fan[fan_number].output_fan_speed, "w");
    if(fp != NULL)
	fwrite(mem_zone, sizeof(mem_zone), 1, fp);
    else{
	printf("Error opening fan device %s \n",fan[fan_number].output_fan_speed);
	return -1;
    }

    fclose(fp);
    return 0;
}

int load_fan_status(int fan_number){
    FILE *fp;
    char *buffer;
    buffer = (char *) calloc(32,1);
    fp = fopen(fan[fan_number].output_fan_speed, "r");
    if(fp == NULL){
	printf("Error opening %s\n", fan[fan_number].output_fan_speed);
    }else{
        fscanf(fp, "%s", buffer);
        fan[fan_number].current_fan_speed = atoi(buffer);
        fclose(fp);
    }

    fp = fopen(fan[fan_number].input_temp_sensor, "r");
    if(fp == NULL){
	printf("Error opening %s\n", fan[fan_number].input_temp_sensor);
    }else{
        memset(buffer, 0, 31);
        fscanf(fp, "%s", buffer);
	if((atoi(buffer)/1000) < 255)
	  fan[fan_number].current_temp = (atoi(buffer)/1000);
	else
	  fan[fan_number].current_temp = 255;
        fclose(fp);
    }
    fp = fopen(fan[fan_number].input_fan_speed, "r");
    if(fp == NULL){
    	printf("Error opening %s\n", fan[fan_number].input_fan_speed);
    }else{
        memset(buffer, 0, 31);
        fscanf(fp, "%s", buffer);
	if((atoi(buffer) < 65355))
	  fan[fan_number].fan_rpm = atoi(buffer);
	else
	  fan[fan_number].fan_rpm = 65355;
        fclose(fp);
    }

    free(buffer);
    if(fp == NULL)
	return -1;
    return 0;
}
int full_speed(){
  return 0;
}

int calc_fan_speed(){
  unsigned int i = 0;
  unsigned int diviziune, temp_diff, current_need_speed;

  for(i = 0; i <= number_of_fans; i++){
    if(fan[i].current_temp >= fan[i].max_temp){
 	fan[i].current_fan_speed = 255;
    }else{
	temp_diff = fan[i].max_temp - fan[i].start_temp;
	if((temp_diff < 0) || (temp_diff > 255) || (fan[i].min_speed < 0))
	  diviziune = 1;
	else
	  diviziune = (255 - fan[i].min_speed)/temp_diff;
	if(fan[i].current_temp >= fan[i].start_temp)
    	    current_need_speed = (fan[i].current_temp - fan[i].start_temp) * diviziune;
    	else
    	    current_need_speed = 0;
	if((current_need_speed > 255) || (current_need_speed < 0))
	  current_need_speed = 255;
	printf("diviziune: %d, current_need_speed %d\n", diviziune, current_need_speed);
	if(current_need_speed < fan[i].min_speed)
          fan[i].current_fan_speed = fan[i].min_speed;
	else{
	    if(fan[i].liniar_fan == 0){
		fan[i].current_fan_speed = current_need_speed * current_need_speed;
	    }else
		fan[i].current_fan_speed = current_need_speed;
	}
    }
  }

  return 0;
}

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: main.h --]
[-- Type: text/x-chdr; name="main.h", Size: 689 bytes --]


typedef struct fans{
    int fan_id;
    char input_temp_sensor[255];
    char input_fan_speed[255];
    char output_fan_speed[255];
    unsigned char current_fan_speed;
    unsigned int fan_rpm;
    int current_temp;
    unsigned int min_speed;
    int start_temp;
    int max_temp;
    char liniar_fan;
    char intermediar_step;
}fans;


fans *fan;
int number_of_fans;
int load_fan_settings(char *file_config);
int load_fan_status(int fan_number);
int set_fan_speed(int fan_number);
int full_speed();
int calc_fan_speed();
int get_value_setting(char *source, char *store);
char *extract_value(char *string);
int autodetect_range();
int detect_startup_value();
int enable_fan_control();

[-- Attachment #4: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors