Re: [lm-sensors] Fintek f71882fg ACPI conflict

[Michael Zintakis <michael.zintakis@googlemail.com>]

> 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