Is openSUSE in control of the CPU fan?

[Axeia]

I was wondering if openSUSE might be taking over control of the CPU fan from my BIOS?

I got the BIOS set to completely disable my CPU fan if the CPU temperature is below 45 degrees.
The temperature is well below this if I may believe the sensors command. (Which I do, as it matches the BIOS value).

Problem is .. my CPU fan never shuts down, could openSUSE be preventing that it does?

Attempted to flash my BIOS to the latest version to see if that might fix it, but didn't end too well and had to restore the version that was running on it before.

If it is openSUSE is interfering, how do I prevent it?

OS/DE: OpenSUSE 11.1 x86_64 KDE4.1
Motherboard: foxconn a7gm-s (with a not so up to date BIOS)
CPU: AMD Athlon 64 LE-1640 / 2.6 GHz Energy Efficient

[Axeia]

Not sure how useful this is.. information from /proc/acpi/thermal_zone/THRM

• cooling_mode <setting not supported>
• polling_frequency <polling disabled>
• state state: ok
• temperature temperature: 26 C
• trip_points critical (S5): 75 C

I also attempted to start 'pwmconfig' but got:

# pwmconfig
File /var/run/fancontrol.pid exists. This typically means that the
fancontrol deamon is running. You should stop it before running pwmconfig.
If you are certain that fancontrol is not running, then you can delete
/var/run/fancontrol.pid manually

So it appears there is a fancontrol deamon running (most likely) I can't find in the services
(though the list is long.. so I could have overlooked it, as I don't know exactly what I'm searching for)

Sensors output:

# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:       +26.0°C  (crit = +75.0°C)

k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp:  +30.0°C

As the 26 degrees matches the non k8temp it seems that I got the wrong info from /proc/acpi/thermal_zone/THRM/ ?

If in the KDE4 system monitor I filter for 'control' the only process I can't place is "console-kit-daemon" which seems to have something to do with user switching instead of fan control.
Only thing in system monitor I suspect that may be influencing the CPU fan speed is "hald-addon-acpi", but I doubt killing the process would be a wise thing to do.

So I'm still looking for a solution on how to either give my BIOS control over the CPU fan or I guess letting openSUSE control it.
(rather have my bios/hardware based solution doing it though)

[Axeia]

Well I got a bit reckless and did a
mv /var/run/fancontrol.pid /var/run/fancontrol.pidd

Then let it idle for a while, and still the fan didn't shut down. Would that mean that my BIOS is to blame?


Also to see if it could do without a fan I unplugged the fan and then stressed the CPU by running a 1080p blu-ray rip in SMPlayer with video output 'gl' which should make the CPU do all the work. (Don't think the opensource ATI drivers support hardware acceleration anyways?)

Temp didn't get above 54 degrees... so at the very least it wouldn't get into critical temperatures very fast if I could get this to work somehow.

[code933k]

Nope, it is not. And lm_sensors has nothing to do with that fact.
You don't have to blame your BIOS either (though most BIOS specs are terribly broken)
It is just a crazy *.DSTD fighting your bios for fan control but neither of them will do the right work so...

Anyway, add the following to your boot line (/boot/grub/menu.lst):

acpi_osi="Linux"

If it doesn't work for you, which is quite improbable, then try this instead:

acpi_osi="!Linux"

Be cautious and try to backup the file before booting or having a rescue CD at hand (ie. Murphy Laws...)

Well I hope that solved your problem.

PS:// For anybody wondering the same thing, this simple tip works OK in a Toshiba Satellite A305 + Insyde BIOS + Intel chipset.
My laptop wasn't able to turn off the CPU Cooling FAN either reporting so through dmesg (D3 error)

Have fun.