Re: Fintek f71882fg ACPI conflict

Re: Fintek f71882fg ACPI conflict

[Guenter Roeck]

On Wed, Jun 27, 2012 at 12:56:00AM +0100, Michael Zintakis wrote:
> Hello,
> 
> I hope this is the right place to place my query!
> 
> I am trying to take control and initialise my fan censors and
> "sensors-detect" is telling me that the chip on the board is "Fintek
> f71869a at 0x290, revision 32". However, when I run sensors (the
> service) this driver is not loaded (I can't see any of the fan
> sensors either) and dmesg is showing me the following:
> 
> [ 2312.804747] f71882fg: Found f71869a chip at 0x290, revision 32
> [ 2312.804902] ACPI Warning: 0x00000290-0x00000297 SystemIO
> conflicts with Region \_TZ_.IP__ 1 (20120111/utaddress-251)
> [ 2312.804919] ACPI Warning: 0x00000290-0x00000297 SystemIO
> conflicts with Region \_SB_.PCI0.LPCB.SIO1.RNTR 2
> (20120111/utaddress-251)
> [ 2312.804934] ACPI: If an ACPI driver is available for this device,
> you should use it instead of the native driver
> 
> Could anybody tell me what the above means please? Is there a
> conflict between ACPI and the Fintek kernel module sensors (the
> service) is trying to load? Is there a separate "ACPI driver" I
> should be using instead? If so, how can I activate it so that I
> could get to read my fan sensors?
> 
> When I run "sensors" (the program) I see very limited information,
> like this:
> 
> acpitz-virtual-0
> Adapter: Virtual device
> temp1:        +48.0°C  (crit = +127.0°C)
> temp2:        +26.8°C  (crit = +127.0°C)
> temp3:        +26.8°C  (crit = +100.0°C)
> 
> coretemp-isa-0000
> Adapter: ISA adapter
> Core 0:       +51.0°C  (crit = +100.0°C)
> Core 1:       +51.0°C  (crit = +100.0°C)
> 
> This is not OK because I don't have any RPMs of any of the fans (I
> have 3 fans running) and various voltages I have on this board. I am
> using Fedora Core 17 with kernel version 3.3.4 with the latest
> version of lm_sensors (3.3.2, I think).
> 
> Many thanks!
> 
Hi Michael,

Please see http://hansdegoede.livejournal.com/7932.html; it should explain what
is going on.

Unfortunately, the generic ACPI driver does not permit much fan control.
There are some board specific ACPI drivers, providing better support (eg ASUS
and Thinkpad), but for the most part you either get no or very limited fan
monitoring/control support.

I don't know if generic support for ACPI based hardware monitoring can be
improved. Since it might be useful to know, I am copying the ACPI maintainer
and the ACPI mailing list. Maybe they can provide some additional information or
pointers.

Thanks,
Guenter

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

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Michael Zintakis]

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

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Matthew Garrett]

On Thu, Jun 28, 2012 at 12:00:56AM +0100, Michael Zintakis wrote:

> 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?

Because there's no handshaking between the firmware and the OS driver, 
and accesses to hardware sensors are often indexed. Imagine this 
scenario:

ACPI                             lmsensors
----                             ---------
select temperature register
                                 select fan speed register
read value
                                 read value

ACPi will read the fan speed register instead of the temperature 
register, and the value may be far too high and cause a critical 
shutdown of the system.

That's the *good* outcome. The bad outcome involves these register 
accesses racing in a way that disables fan control or thermal trip 
points and risks causing hardware damage. It's not safe for two 
different codepaths to access the same hardware without having any kind 
of locking, so if your system firmware declares that ACPI is using the 
temperature device the hardware sensors framework will refuse to.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Michael Zintakis]

>> Could any of the more knowledgeable on here explain why
>> is it such a bad idea please?
>>     
>
> Because there's no handshaking between the firmware and the OS driver, 
> and accesses to hardware sensors are often indexed. Imagine this 
> scenario:
>
> ACPI                             lmsensors
> ----                             ---------
> select temperature register
>                                  select fan speed register
> read value
>                                  read value
>
> ACPi will read the fan speed register instead of the temperature 
> register, and the value may be far too high and cause a critical 
> shutdown of the system.
>
> That's the *good* outcome. The bad outcome involves these register 
> accesses racing in a way that disables fan control or thermal trip 
> points and risks causing hardware damage. It's not safe for two 
> different codepaths to access the same hardware without having any kind 
> of locking, so if your system firmware declares that ACPI is using the 
> temperature device the hardware sensors framework will refuse to.
>   
All noted, thanks for the explanation - pretty hairy stuff! The tragic 
thing is, I have no way of telling ACPI to *not* use or "implement" its 
own fan, voltage, temperature management and let a more capable piece of 
software (the f71882fg driver in this case) do that job!

What is the alternative? There is none that I could see. I tried using 
memmap to force ACPI not to use the memory region claimed by f71882fg 
(0x290 - 8 bytes long according to the driver), but that didn't help 
much. What am I supposed to do - deactivate ACPI completely? That would 
be like going after a fly with a bazooka!

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Jean Delvare]

On Thu, 28 Jun 2012 12:15:43 +0100, Michael Zintakis wrote:
> > That's the *good* outcome. The bad outcome involves these register 
> > accesses racing in a way that disables fan control or thermal trip 
> > points and risks causing hardware damage. It's not safe for two 
> > different codepaths to access the same hardware without having any kind 
> > of locking, so if your system firmware declares that ACPI is using the 
> > temperature device the hardware sensors framework will refuse to.
>
> All noted, thanks for the explanation - pretty hairy stuff! The tragic 
> thing is, I have no way of telling ACPI to *not* use or "implement" its 
> own fan, voltage, temperature management and let a more capable piece of 
> software (the f71882fg driver in this case) do that job!

This has been my very claim for several years now. My next step is to
find someone involved in the ACPI specification that would be willing
to discuss the problem with me and implement a solution in the next
ACPI specification.

Don't hold your breath though, it will take years before the problem
actually gets solved for the end user - if that ever happens.

-- 
Jean Delvare

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Michael Zintakis]

> Don't hold your breath though, it will take years before the problem
> actually gets solved for the end user - if that ever happens.
>   
Pretty grim that!

In the meantime, considering the specifics of my particular case and the 
memory regions involved (again, I think they are 0x290-0x297, a total of 
8 bytes in length according to the driver, though if someone more 
knowledgeable in the f71882fg driver specifics know otherwise, please 
feel free to correct this if that assumption is wrong), would it be 
possible to manually hack into the ACPI code and forcefully prevent it 
from claiming those memory regions and not get involved in "managing" 
that particular device?

I appreciate this could be quite ugly, but I am that desperate - I don't 
want ACPI doing the "managing" and want the f71822fg driver to have a 
free reign (without the risks, as previously noted!), albeit with the 
help of my bash script at times. :-)

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Jean Delvare]

On Thu, 28 Jun 2012 13:53:49 +0100, Michael Zintakis wrote:
> In the meantime, considering the specifics of my particular case and the 
> memory regions involved (again, I think they are 0x290-0x297, a total of 
> 8 bytes in length according to the driver, though if someone more 
> knowledgeable in the f71882fg driver specifics know otherwise, please 
> feel free to correct this if that assumption is wrong), would it be 
> possible to manually hack into the ACPI code and forcefully prevent it 
> from claiming those memory regions and not get involved in "managing" 
> that particular device?

Not that I know of. That would rather be a question for the ACPI
people, but I'm afraid the answer is that ACPI is supposed to be the
best thing since sliced bread and you should just let it do its stuff
and not ask questions :( I too would love to be able to tell ACPI to
let my hardware monitoring chip (and/or SMBus controller) alone.

-- 
Jean Delvare

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Robert Hancock]

On 06/28/2012 07:27 AM, Jean Delvare wrote:
> On Thu, 28 Jun 2012 13:53:49 +0100, Michael Zintakis wrote:
>> In the meantime, considering the specifics of my particular case and the
>> memory regions involved (again, I think they are 0x290-0x297, a total of
>> 8 bytes in length according to the driver, though if someone more
>> knowledgeable in the f71882fg driver specifics know otherwise, please
>> feel free to correct this if that assumption is wrong), would it be
>> possible to manually hack into the ACPI code and forcefully prevent it
>> from claiming those memory regions and not get involved in "managing"
>> that particular device?
>
> Not that I know of. That would rather be a question for the ACPI
> people, but I'm afraid the answer is that ACPI is supposed to be the
> best thing since sliced bread and you should just let it do its stuff
> and not ask questions :( I too would love to be able to tell ACPI to
> let my hardware monitoring chip (and/or SMBus controller) alone.

The ACPI conflict gets triggered when the BIOS AML code creates an 
operation region to access the same device that the driver is trying to 
bind to. There apparently are some BIOSes that do this and yet don't use 
it to actually access the hardware monitoring chip. In this case there 
is no true conflict and the acpi_enforce_resources=lax option is safe to 
use. Unfortunately there's really no way for the kernel to tell whether 
or not this is the case.

In this case, however, where the BIOS does in fact expose an ACPI 
thermal zone and relies on AML code to perform fan control, etc. then it 
seems quite likely that it's not safe to access the same hardware 
monitoring controller while AML code may be doing so at the same time. 
The only way I can see that you could make ACPI "leave the hardware 
monitoring chip alone" is to either have the kernel block its accesses 
(quite likely breaking all fan/temperature control) or disable ACPI 
entirely (in this case the BIOS likely either leaves the fan control in 
"run at max speed always" mode or uses SMIs to gain control where needed 
to adjust fan speeds, which causes the same concurrent access problem).

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Michael Zintakis]

> In this case, however, where the BIOS does in fact expose an ACPI 
> thermal zone and relies on AML code to perform fan control, etc. then 
> it seems quite likely that it's not safe to access the same hardware 
> monitoring controller while AML code may be doing so at the same time. 
> The only way I can see that you could make ACPI "leave the hardware 
> monitoring chip alone" is to either have the kernel block its accesses 
> (quite likely breaking all fan/temperature control) or disable ACPI 
> entirely (in this case the BIOS likely either leaves the fan control 
> in "run at max speed always" mode or uses SMIs to gain control where 
> needed to adjust fan speeds, which causes the same concurrent access 
> problem).
Interesting and it sort-of confirms my "findings" from yesterday's bout 
I've had with ACPI.

When I completely deactivate ACPI ("acpi=off" in the kernel command 
line), there is obviously no more conflict errors reported, but what I 
also discovered is that the problem I've had with the fans not able to 
start (when they are at standstill initially) is not there any more!

When I forcefully stop a fan by "echo 1 > pwmX" (you were right, when I 
deactivate any sort of temperature, fan & voltage management in BIOS and 
ACPI is OFF, the fans run at maximum speed), then select "automatic" 
management and pass control over to the f71882fg driver, when the 
temperature rises enough for the fan to start spinning, but not enough 
to push it over the "safe" minimum speed threshold, this raises an alarm 
event (fanX_alarm gets triggered) and the f71882fg driver then, 
completely by itself, pushes the fan to its maximum speed momentarily 
and the fan starts spinning - exactly the behaviour I was "simulating" 
with my bash script.

Obviously, the pwm value then gets decreased by the driver below the 
"safe" minimum speed limit causing the fan to stop again and trigger the 
alarm again, but I could easily overcome this problem by setting 
pwmX_auto_point5_pwm to keep the fan at safe speed once it is started.

When I do this, everything is running absolutely flawlessly - I've ran 
this for 3 hours, putting various load levels on the system to see how 
it reacts to temperature changes and the f71882fg driver does a superb 
job without the need for my bash script!

The only downside is, if one could call it that, that I have to setup 
everything under /sys/class/hwmon/hwmonX/driver/ manually - from 
"pwmX_auto_pointY_temp/pwm" to "fanX_full_speed" and the like, but I 
could live with that, no problem.

Now, it seems to me that ACPI is the culprit, has been all along, and I 
need to get rid of the conflict in order to achieve that level of 
operation - without this I am going to struggle! Turning ACPI off 
completely is not an option for me at all - in such a case one 
noticeable effect is that my multi-core CPU doesn't get recognised (it 
is only recognised as a single-core) and the SMP-part of the kernel is 
not functioning. That, clearly, is unacceptable to me.

So, is there a way to make ACPI "leave my hardware monitoring chip 
alone" without fully deactivating it? I don't care if all 
fan/temperature control is going to "break" - I think the f71882fg chip 
driver is perfectly capable of doing that without the "help" from ACPI. 
So, is there any way - even with brute-force hacking of the kernel - to 
prevent ACPI from getting anywhere near my hwmon chip (please say "yes" 
:-) )?

Last couple of queries regarding the f71882fg driver:

What is the purpose of "pwmX_auto_channels_temp" (I have default values 
of 4, 2 and 1 for my 3 fans), "pwmX_auto_pointY_temp_hyst" and 
"pwmX_interpolate"? I think the latter could be a boolean value whether 
the f71882fg driver should interpolate values between the temperature 
points in order to determine fan speed, but can't be sure.

Also, is it possible to select which temperature reading should be used 
when selecting the fan speed? By default, to determine fan1's speed, 
temp1 is used and pwm1 value is then manipulated. Is it possible to 
instruct the driver to use a different sensor reading for the 
temperature in order to determine the speed of the fan?
 

MZ

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Guenter Roeck]

On Fri, Jun 29, 2012 at 01:11:04PM +0100, Michael Zintakis wrote:
> 
[ ... ]
> Interesting and it sort-of confirms my "findings" from yesterday's
> bout I've had with ACPI.
> 
> When I completely deactivate ACPI ("acpi=off" in the kernel command
> line), there is obviously no more conflict errors reported, but what
> I also discovered is that the problem I've had with the fans not
> able to start (when they are at standstill initially) is not there
> any more!
> 
> When I forcefully stop a fan by "echo 1 > pwmX" (you were right,
> when I deactivate any sort of temperature, fan & voltage management
> in BIOS and ACPI is OFF, the fans run at maximum speed), then select
> "automatic" management and pass control over to the f71882fg driver,

You are giving too much credit to the driver. The driver only reads and sets
register values, but does not perform any activities beyond that.

> when the temperature rises enough for the fan to start spinning, but
> not enough to push it over the "safe" minimum speed threshold, this
> raises an alarm event (fanX_alarm gets triggered) and the f71882fg
> driver then, completely by itself, pushes the fan to its maximum
> speed momentarily and the fan starts spinning - exactly the
> behaviour I was "simulating" with my bash script.
> 
No, the driver doesn't. The chip does that.

[ ... ]

> Last couple of queries regarding the f71882fg driver:
> 
> What is the purpose of "pwmX_auto_channels_temp" (I have default
> values of 4, 2 and 1 for my 3 fans), "pwmX_auto_pointY_temp_hyst"

pwmX_auto_channels_temp Temperature input channel. Matches temp[1-4]_input to
the pwm channel X.

> and "pwmX_interpolate"? I think the latter could be a boolean value

pwmX_interpolate: Data sheet says "Set 1 will enable the interpolation of the
fan expect table", whatever that means. My guess is that, if enabled, the chip
does not just take the temperatures in the auto_point table and sets the
respective pwm value, but interpolates for temperatures in between.

pwmX_auto_pointY_temp_hyst is, as the name suggests, a hysteresis value.
pwm value increases if a temperature trip point is reached (from below),
and decreases to the previous value if the respective hysteresis point
is reached (from above).

> whether the f71882fg driver should interpolate values between the
> temperature points in order to determine fan speed, but can't be
> sure.
> 
> Also, is it possible to select which temperature reading should be
> used when selecting the fan speed? By default, to determine fan1's
> speed, temp1 is used and pwm1 value is then manipulated. Is it
> possible to instruct the driver to use a different sensor reading
> for the temperature in order to determine the speed of the fan?
> 

See above; you can use pwmX_auto_channels_temp for that purpose.

Guenter

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Guenter Roeck]

On Thu, Jun 28, 2012 at 12:00:56AM +0100, Michael Zintakis wrote:
> Hello Guenter and All,
> 
[ .. ]

> One last question (though this is more specific to the f71882fg
> driver): I have a procfs file called "pwmX_auto_pointY" (Y being

Do you mean sysfs ?

> 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.
> 
Correct. 1 is too low, though. Default value per datasheet is 0x80.
Whatever it is, it should be high enough for the fans to start spinning.
The F71882FG does not have a register to set a "start spinning" pwm value,
so your minimum must guarantee that the fans do start to spin.

What is your setting for pwmX_enable ? It should probably be set to
automatic(2) so the chip can automatically control the fan speed depending
on the temperature.

> 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!
> 
Maybe fan control is not set to automatic by the BIOS ?

Guenter

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Michael Zintakis]

> Do you mean sysfs ?
>   
Yeah, sorry. Everything under /sys/class/hwmon/...

> Correct. 1 is too low, though. Default value per datasheet is 0x80.
> Whatever it is, it should be high enough for the fans to start spinning.
>   
That won't be enough! I did a bit of experimenting and discovered the 
following:

The minimum value for pwm on all fans necessary to keep them going is 75 
(decimal) - below that value the fan just stops. The minimum value to 
kick-start the fan and make it spin from standstill is 190 (also 
decimal) - nothing below this value is sufficient to move the fan from 
its standstill position (in my script I use the maximum value - 255 - to 
be on the safe side).

So, even if I set the pwmX_auto_point5_pwm to 75 that won't be enough to 
kick-start the fan initially. On the other hand, if I set it to 190 that 
would be enough, but the fan will continue to spin at this rate which is 
very high (I may as well abandon fan/temperature management then).

> The F71882FG does not have a register to set a "start spinning" pwm value,
> so your minimum must guarantee that the fans do start to spin.
>
> What is your setting for pwmX_enable ? It should probably be set to
> automatic(2) so the chip can automatically control the fan speed depending
> on the temperature.
>   
It is indeed set to 2.

>> 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!
>>
>>     
> Maybe fan control is not set to automatic by the BIOS ?
>   
It is and it is why I am keeping this automatic BIOS fan management in 
place and my script only intervenes to kick-start the fans when they are 
still, otherwise this automatic control is doing a good job. The problem 
is the actual kick-start (and the fact that there is no way I could 
force ACPI to abandon the region of memory used by the driver).

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Guenter Roeck]

On Thu, Jun 28, 2012 at 12:31:30PM +0100, Michael Zintakis wrote:
> 
> >Do you mean sysfs ?
> Yeah, sorry. Everything under /sys/class/hwmon/...
> 
> >Correct. 1 is too low, though. Default value per datasheet is 0x80.
> >Whatever it is, it should be high enough for the fans to start spinning.
> That won't be enough! I did a bit of experimenting and discovered
> the following:
> 
> The minimum value for pwm on all fans necessary to keep them going
> is 75 (decimal) - below that value the fan just stops. The minimum
> value to kick-start the fan and make it spin from standstill is 190
> (also decimal) - nothing below this value is sufficient to move the
> fan from its standstill position (in my script I use the maximum
> value - 255 - to be on the safe side).
> 
> So, even if I set the pwmX_auto_point5_pwm to 75 that won't be
> enough to kick-start the fan initially. On the other hand, if I set
> it to 190 that would be enough, but the fan will continue to spin at
> this rate which is very high (I may as well abandon fan/temperature
> management then).
> 
> >The F71882FG does not have a register to set a "start spinning" pwm value,
> >so your minimum must guarantee that the fans do start to spin.
> >
> >What is your setting for pwmX_enable ? It should probably be set to
> >automatic(2) so the chip can automatically control the fan speed depending
> >on the temperature.
> It is indeed set to 2.
> 
> >>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!
> >>
> >Maybe fan control is not set to automatic by the BIOS ?
> It is and it is why I am keeping this automatic BIOS fan management
> in place and my script only intervenes to kick-start the fans when
> they are still, otherwise this automatic control is doing a good
> job. The problem is the actual kick-start (and the fact that there
> is no way I could force ACPI to abandon the region of memory used by
> the driver).

That isn't BIOS fan management - it is completely handled by the chip itself.
Problem is most likely that the BIOS does not "kick-start" the fan(s),
and the chip does not have a register to set a "start fan" pwm value (other
chips such as the NCT677X do have a register for that purpose). So you may
be stuck with your manual method if you want to keep the fan running at speeds
lower than pwm=190. Another option might be to find a fan which starts at lower
pwm values, and/or does not need to be kick-started.

Guenter

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Michael Zintakis]

> That isn't BIOS fan management - it is completely handled by the chip itself.
>   
Whatever it is, it seems to be "automatic" - i.e. I don't determine what 
needs to be done, but the BIOS/the driver does this "on my behalf", 
which is good enough for me, provided I know how to avoid the ACPI 
conflict, because I am not about to start playing Russian roulette with 
my hardware.

I've spend some time earlier today looking at the ACPI code and it seems 
as though the first conflicting region (\_TZ_.IP__ 1) is from the ACPI 
thermal driver. I think I could easily deactivate this with 
"thermal.off=1". The second region though  (\_SB_.PCI0.LPCB.SIO1.RNTR) 
is a complete mystery to me.

There are a couple of lines in my dmesg file where these IO regions are 
mentioned:

[    0.117903] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[...]
[    0.117952] pci 0000:00:00.0: [8086:0bf3] type 0 class 0x000600
[...]
[    0.203459] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[...]
[    0.203550] pci_bus 0000:04: resource 4 [io  0x0000-0x0cf7]

So, provided I could avoid the first conflict by using thermal.off=1, I 
need to find out what is causing the second one and find out how to 
prevent it...

> Problem is most likely that the BIOS does not "kick-start" the fan(s),
> and the chip does not have a register to set a "start fan" pwm value (other
> chips such as the NCT677X do have a register for that purpose).
Yep, that seems to be the case indeed.

>  So you may
> be stuck with your manual method if you want to keep the fan running at speeds
> lower than pwm=190.
Would it be possible for such feature to be implemented in the f71882fg 
driver? Most of the stuff which is done with my bash script will be very 
easy to implement in the driver as it involves nothing more than playing 
with the registry values and adding a bit of logic to it. Would that be 
possible?

>  Another option might be to find a fan which starts at lower
> pwm values, and/or does not need to be kick-started.
>   
I've had enough problem selecting the fans which suit my needs (i.e. 
noise levels, RPM speed, power consumption etc) and I am not prepared to 
go through that again, no way!


MZ

Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Guenter Roeck]

On Thu, Jun 28, 2012 at 06:39:03PM +0100, Michael Zintakis wrote:

[ ... ]

> >Problem is most likely that the BIOS does not "kick-start" the fan(s),
> >and the chip does not have a register to set a "start fan" pwm value (other
> >chips such as the NCT677X do have a register for that purpose).
> Yep, that seems to be the case indeed.
> 
> > So you may
> >be stuck with your manual method if you want to keep the fan running at speeds
> >lower than pwm=190.
> Would it be possible for such feature to be implemented in the
> f71882fg driver? Most of the stuff which is done with my bash script
> will be very easy to implement in the driver as it involves nothing
> more than playing with the registry values and adding a bit of logic
> to it. Would that be possible?
> 
No, that is not in the scope of a kernel driver. You could use fancontrol(8),
but that would mean you have to switch to manual fan control (from chip
perspective).

Guenter