From: Michael Zintakis <michael.zintakis@googlemail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: lm-sensors@lm-sensors.org, Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org
Subject: Re: [lm-sensors] Fintek f71882fg ACPI conflict
Date: Thu, 28 Jun 2012 00:00:56 +0100 [thread overview]
Message-ID: <4FEB90A8.8050901@googlemail.com> (raw)
In-Reply-To: <20120627171505.GB12712@roeck-us.net>
Hello Guenter and All,
> Please see http://hansdegoede.livejournal.com/7932.html; it should explain what
> is going on.
>
This is precisely what I stumbled upon when reading the documentation
about the kernel acpi parameters today and tried it straight away
(though, in all honesty, I didn't have a clue that it is actually a bad
idea until I read the article above - thanks for posting!). Could any of
the more knowledgeable on here explain why is it such a bad idea please?
I also tried another, much cleaner solution which was described in that
kernel documentation file, namely:
memmap=nn[KMG]$ss[KMG]
[KNL,ACPI] Mark specific memory as reserved.
Region of memory to be used, from ss to ss+nn.
Example: Exclude memory from 0x18690000-0x1869ffff
memmap=64K$0x18690000
or
memmap=0x10000$0x18690000
So, I tried to use the following kernel command line parameter:
"memmap=0x08$0x00000290" in order to force ACPI to mark this memory
space as "reserved" and not use it, but that didn't work for some
reason. When I tried to load the f71882fg driver the same error
happened. :-(
The only solution, it seems, is by using "acpi_enforce_resources=lax" -
that way it all works out.
Relying on ACPI is not an option for me whatsoever - I am using this
board to run critical applications 24/7 and I *need* to have active fan,
voltage and temperature management at *all* times.
ACPI cannot provide that!
The only piece of software which could provide what I need is the
f71882fg driver and it does it very well, though, there I have one
issue, which you, or anyone else could address for me, if possible. The
issue is this:
Initially, when the board is first powered up, all fans (all 3 of them)
are at a standstill because the board temperature is low. After some
time passes by, when the temperature starts to rise steadily, it comes a
point where the BIOS/the f71882fg driver increase the pwm parameter of
the fans, but there comes a problem: due to the fact that the current
increase is very gentle and also due to the fact of the actual physical
fan inertia (for a lack of better word), the fan does *not* start.
That causes overheating!
If I gently push the fan or blow towards it, it starts spinning and
BIOS/f71882fg takes over and controls it very well and it all works,
until there comes a point again where the fan stops (outside temperature
drops for example), in which case the whole cycle repeats.
I devised one ugly hack to fix this: I created a shell script, which
runs every 10 seconds and checks to see if fanX_alarm=1 (this happens,
for example, when there is current applied to the fan - i.e. its "pwmX"
value is >0 and "fanX_input=0", i.e. the fan is not moving - the
scenario I described above). If that is the case, then the script,
temporarily, switches to "manual" control (pwmX_enable=1), throttles up
the fan up to a maximum (i.e. pwmX=255), checks that the fan is running,
and then restores automatic control (reverts pwmX_enable back to 2).
That way, when the fan is initially stopped and the BIOS/f71882fg driver
applies some current to it in order to get it going and can't do it, it
gets a gentle "push" from my script, after which automatic control takes
over again and all is well.
That way it works, but I don't like it - there has to be another, more
"civilised" way of doing this, surely!
One last question (though this is more specific to the f71882fg driver):
I have a procfs file called "pwmX_auto_pointY" (Y being from 1-5), which
indicates the various pwm current value which is to be applied for
different points: 4 being when the controlling temperature is low (the
value of pwmX_auto_point4_temp to be precise) and 1 being where the
current is at its maximum - normally 255.
Now, what is the purpose of pwmX_auto_point5 - does this hold the pwm
value where the fan is in an idle state (i.e. the temperature is below
pwmX_auto_point4_temp)? Because on all 3 fans, I have this set to 1,
which, I am assuming is when the fans are stopped.
Even if I bring this value to some "idle" current, that won't help much
because when I first boot the system, the fans are *always* still, so
even if the idle state is >1, that won't help me much, so there must be
another - better - way than using a script to "kickstart" the fans
initially, surely!
Apologies for this long post, but I have been banging my head against
the wall with these problems for the past week with no end in sight!
MZ
next prev parent reply other threads:[~2012-06-27 23:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4FEA4C10.2060904@googlemail.com>
2012-06-27 17:15 ` Fintek f71882fg ACPI conflict Guenter Roeck
2012-06-27 23:00 ` Michael Zintakis [this message]
2012-06-28 1:45 ` [lm-sensors] " Matthew Garrett
2012-06-28 11:15 ` Michael Zintakis
2012-06-28 12:40 ` Jean Delvare
2012-06-28 12:53 ` Michael Zintakis
2012-06-28 13:27 ` Jean Delvare
2012-06-29 5:35 ` Robert Hancock
2012-06-29 12:11 ` Michael Zintakis
2012-06-29 16:34 ` Guenter Roeck
2012-06-28 5:20 ` Guenter Roeck
2012-06-28 11:31 ` Michael Zintakis
2012-06-28 17:12 ` Guenter Roeck
2012-06-28 17:39 ` Michael Zintakis
2012-06-28 18:57 ` Guenter Roeck
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=4FEB90A8.8050901@googlemail.com \
--to=michael.zintakis@googlemail.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).