From: Guenter Roeck <linux@roeck-us.net>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Fan Control on 6027R TRF running Debian Wheezy
Date: Sun, 12 Oct 2014 17:20:59 +0000 [thread overview]
Message-ID: <543AB87B.8020508@roeck-us.net> (raw)
In-Reply-To: <5437E87B.8030206@truthbox.ch>
On 10/12/2014 10:15 AM, Phil Pokorny wrote:
> On Sun, Oct 12, 2014 at 9:12 AM, Felix Schulthess <fsch@truthbox.ch> wrote:
>
>>> You cannot control the fan speeds. They are managed by the onboard
>>> controller. You can choose one of several profiles in the bios but that
>>> is it.
>>
>> That explains a lot. Thank you for your help, I am going to do some
>> further research in this direction and read up on FreeIPMI.
>>
>> Still, if I can't control the fan speeds but they are instead controlled
>> by some onboard controller, then how could the installation on the
>> fancontrol and lm-sensors mess up the control loop so bad? This still
>> keeps me wondering.
>>
>
> You can't control the fan speeds because there is already another device on
> the motherboard that is tasked with the job of controlling them. As you
> found, you can poke the control chips, but that doesn't mean you can
> control the speeds predictably. Imagine two cooks in a kitchen trying to
> cook different meals with the same ingredients. They come and go in the
> kitchen unaware of the others meddling and confused why things are changing
> when they are away. You end up with no food. Only one cook in the kitchen.
>
> It's also possible that when you ran SDT it's default config was to change
> the BIOS/BMC setting on the fans speeds to full speed. As you found it was
> a permanent change to the setting, not some strange interaction between
> lm_sensors and sdt and the BMC.
>
>
>> Maybe, the sensors somehow blocked the CPU temperature readout. This
>> could have caused the superdoctor program to resort to some failsafe
>> behavior (i.e. spinning the fans up to max RPM). Just wondering.
>
>
> Also possible.
>
No idea how that could happen, unless there is a means for an application
or kernel module to block access to specific CPU registers. That would be
news to me, though.
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
prev parent reply other threads:[~2014-10-12 17:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-10 14:08 [lm-sensors] Fan Control on 6027R TRF running Debian Wheezy Felix Schulthess
2014-10-10 14:53 ` Phil Pokorny
2014-10-12 16:12 ` Felix Schulthess
2014-10-12 16:53 ` Felix Schulthess
2014-10-12 17:15 ` Phil Pokorny
2014-10-12 17:20 ` Guenter Roeck [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=543AB87B.8020508@roeck-us.net \
--to=linux@roeck-us.net \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.