* [lm-sensors] Fancontrol
@ 2005-07-24 17:15 Henry
2005-07-25 13:44 ` Jim Cromie
` (17 more replies)
0 siblings, 18 replies; 19+ messages in thread
From: Henry @ 2005-07-24 17:15 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
@ 2005-07-25 13:44 ` Jim Cromie
2005-07-26 9:45 ` Rudolf Marek
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Jim Cromie @ 2005-07-25 13:44 UTC (permalink / raw)
To: lm-sensors
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 ?
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
2005-07-25 13:44 ` Jim Cromie
@ 2005-07-26 9:45 ` Rudolf Marek
2005-07-26 18:13 ` Henry
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Rudolf Marek @ 2005-07-26 9:45 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
2005-07-25 13:44 ` Jim Cromie
2005-07-26 9:45 ` Rudolf Marek
@ 2005-07-26 18:13 ` Henry
2005-07-27 9:23 ` Rudolf Marek
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Henry @ 2005-07-26 18:13 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (2 preceding siblings ...)
2005-07-26 18:13 ` Henry
@ 2005-07-27 9:23 ` Rudolf Marek
2005-07-27 16:05 ` Henry
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Rudolf Marek @ 2005-07-27 9:23 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (3 preceding siblings ...)
2005-07-27 9:23 ` Rudolf Marek
@ 2005-07-27 16:05 ` Henry
2005-07-28 10:21 ` Rudolf Marek
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Henry @ 2005-07-27 16:05 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (4 preceding siblings ...)
2005-07-27 16:05 ` Henry
@ 2005-07-28 10:21 ` Rudolf Marek
2005-07-28 15:18 ` Henry
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Rudolf Marek @ 2005-07-28 10:21 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (5 preceding siblings ...)
2005-07-28 10:21 ` Rudolf Marek
@ 2005-07-28 15:18 ` Henry
2005-07-28 15:19 ` Henry
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Henry @ 2005-07-28 15:18 UTC (permalink / raw)
To: lm-sensors
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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (6 preceding siblings ...)
2005-07-28 15:18 ` Henry
@ 2005-07-28 15:19 ` Henry
2005-07-28 15:41 ` Henry
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Henry @ 2005-07-28 15:19 UTC (permalink / raw)
To: lm-sensors
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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (7 preceding siblings ...)
2005-07-28 15:19 ` Henry
@ 2005-07-28 15:41 ` Henry
2005-07-30 7:02 ` Henry
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Henry @ 2005-07-28 15:41 UTC (permalink / raw)
To: lm-sensors
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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] Fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (8 preceding siblings ...)
2005-07-28 15:41 ` Henry
@ 2005-07-30 7:02 ` Henry
2009-03-25 9:04 ` [lm-sensors] fancontrol Jean Delvare
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Henry @ 2005-07-30 7:02 UTC (permalink / raw)
To: lm-sensors
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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [lm-sensors] fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (9 preceding siblings ...)
2005-07-30 7:02 ` Henry
@ 2009-03-25 9:04 ` Jean Delvare
2009-03-25 15:33 ` sergio
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Jean Delvare @ 2009-03-25 9:04 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [lm-sensors] fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (10 preceding siblings ...)
2009-03-25 9:04 ` [lm-sensors] fancontrol Jean Delvare
@ 2009-03-25 15:33 ` sergio
2009-03-25 21:35 ` Jean Delvare
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: sergio @ 2009-03-25 15:33 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [lm-sensors] fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (11 preceding siblings ...)
2009-03-25 15:33 ` sergio
@ 2009-03-25 21:35 ` Jean Delvare
2009-03-27 3:03 ` sergio
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Jean Delvare @ 2009-03-25 21:35 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [lm-sensors] fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (12 preceding siblings ...)
2009-03-25 21:35 ` Jean Delvare
@ 2009-03-27 3:03 ` sergio
2009-03-27 8:39 ` Jean Delvare
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: sergio @ 2009-03-27 3:03 UTC (permalink / raw)
To: lm-sensors
[-- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [lm-sensors] fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (13 preceding siblings ...)
2009-03-27 3:03 ` sergio
@ 2009-03-27 8:39 ` Jean Delvare
2009-03-27 16:30 ` sergio
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Jean Delvare @ 2009-03-27 8:39 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [lm-sensors] fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (14 preceding siblings ...)
2009-03-27 8:39 ` Jean Delvare
@ 2009-03-27 16:30 ` sergio
2009-05-09 11:43 ` Jean Delvare
2010-03-29 11:46 ` Ioan Rusan
17 siblings, 0 replies; 19+ messages in thread
From: sergio @ 2009-03-27 16:30 UTC (permalink / raw)
To: lm-sensors
[-- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [lm-sensors] fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (15 preceding siblings ...)
2009-03-27 16:30 ` sergio
@ 2009-05-09 11:43 ` Jean Delvare
2010-03-29 11:46 ` Ioan Rusan
17 siblings, 0 replies; 19+ messages in thread
From: Jean Delvare @ 2009-05-09 11:43 UTC (permalink / raw)
To: lm-sensors
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [lm-sensors] fancontrol
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
` (16 preceding siblings ...)
2009-05-09 11:43 ` Jean Delvare
@ 2010-03-29 11:46 ` Ioan Rusan
17 siblings, 0 replies; 19+ messages in thread
From: Ioan Rusan @ 2010-03-29 11:46 UTC (permalink / raw)
To: lm-sensors
[-- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2010-03-29 11:46 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-07-24 17:15 [lm-sensors] Fancontrol Henry
2005-07-25 13:44 ` Jim Cromie
2005-07-26 9:45 ` Rudolf Marek
2005-07-26 18:13 ` Henry
2005-07-27 9:23 ` Rudolf Marek
2005-07-27 16:05 ` Henry
2005-07-28 10:21 ` Rudolf Marek
2005-07-28 15:18 ` Henry
2005-07-28 15:19 ` Henry
2005-07-28 15:41 ` Henry
2005-07-30 7:02 ` Henry
2009-03-25 9:04 ` [lm-sensors] fancontrol Jean Delvare
2009-03-25 15:33 ` sergio
2009-03-25 21:35 ` Jean Delvare
2009-03-27 3:03 ` sergio
2009-03-27 8:39 ` Jean Delvare
2009-03-27 16:30 ` sergio
2009-05-09 11:43 ` Jean Delvare
2010-03-29 11:46 ` Ioan Rusan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.