Fintek f71882fg ACPI conflict

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!

MZ

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Hello Guenter and All,

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
                     memmapdK$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%5), 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

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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 | [email protected]

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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!

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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. :-)

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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).

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[ ... ]

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.

No, the driver doesn't. The chip does that.

[ ... ]

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

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).

See above; you can use pwmX_auto_channels_temp for that purpose.

Guenter

[ .. ]

Do you mean sysfs ?

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.

Maybe fan control is not set to automatic by the BIOS ?

Guenter

Yeah, sorry. Everything under /sys/class/hwmon/...

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).

It is indeed set to 2.

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).

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

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

Yep, that seems to be the case indeed.

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?

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

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

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

[ ... ]

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

Greetings, Michael Zintakis!

This SHOULD NOT be the case. Precisely because of the issue you've outlined below:

All fans SHOULD spin at some low rate to make the system work. Alternatively, the BIOS may provide a kickstart, when there's rise of temperature over certain threshold, like you did in your script. I suggest you raise this issue with your board manufacturer.

P.S.
All capitalization in accordance with RFC#2119.

--
WBR,
Andrey Repin ([email protected]) 28.06.2012, <07:08>

Sorry for my terrible english...

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

I disagree. When the outside temperature is low (say 10-12 degrees C) there is no need for the fans to spin at all. In fact, this is exactly what I have in my other PC - the box fan stops and only the CPU fan is operational at that time, which helps me save a bit on the electricity bill and reduces the noise.

Yeah, it should, but it doesn't, hence why I am using the driver and my script.

I did, but it seems they are a complete numpties - their "technical support" department is neither technical and they offer pitiful support, so I am left to my own devices so to speak.

No problem!

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors