Re: Fintek f71882fg ACPI conflict

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

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


[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux