Message-ID: <46BEE247.4040904@s5r6.in-berlin.de>
Date:	Sun, 12 Aug 2007 12:34:47 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Jean Delvare <khali@...ux-fr.org>
CC:	"Mark M. Hoffman" <mhoffman@...htlink.com>,
	lm-sensors@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: 2.6.23-rc1 regression: hwmon/w83627ehf: wrong fan speed

Jean Delvare wrote:
> On Sat, 11 Aug 2007 17:41:39 +0200, Stefan Richter wrote:
>> While I test-booted 2.6.22(-rc) yesterday I had a look into the BIOS
>> setup.  There is a fan speed control based on a temperature threshold,
>> separately for CPU fan and case fan.  The thresholds are currently 55°C
>> and 50°C respectively.
> 
> Hopefully it is programming the W83627EHG at boot time and no longer
> touching it after that. You can check
> in /sys/class/hwmon/hwmon*/device, some of the pwm*_enable files should
> have value >= 2.

$ cat /sys/class/hwmon/hwmon*/device/{name,pwm*_enable}
w83627ehf
coretemp
coretemp
2
2
1

[...]
>> ksensors has different update interval settings, and although I had the
>> w83627ehf readings configured to be updated every 30 seconds, some
>> seemingly unrelated setting was at 5 seconds.  I changed that to 30
>> seconds too and the period of above loop increased to ca. 30 seconds
>> (127 times div = 8, 8 times div = 128).
> 
> Hmm. Is this "seemingly unrelated setting" the "Mainboard sensors"
> panel?

Yes.

> Maybe I get what's going on then. This panel gets the CPU
> temperature from the ACPI "thermal" driver (/proc/acpi/thermal). Your report
> suggests that the temperature value is taken from the W83627EHF's
> temp2, which is in bank 1. If I am correct, then simply reading
> from /proc/acpi/thermal/*/temperature would break the fan divider (when
> my fixup patch isn't applied, that is.)
> 
> I recommend that you don't load the ACPI "thermal" driver together with
> the w83627ehf driver, it won't give you any additional information and
> the race condition that exists between both drivers can still result in
> wrong values being reported from times to times (even with my patch.)

I reverted your patch, reloaded the modules, unloaded thermal, checked
readings with "sensors" (OK), started ksensors:  1.) Its "Mainboard
sensors" config panel is gone.  2.) The problem of the fan divider
oscillating between 8 and 128 is gone.  Fan speeds are now correct all
the time.

>> So the BIOS seems innocent.
> 
> Good news.
> 
> One remaining mystery is why you did not observe the problem with the
> older kernel. Maybe the ACPI thermal driver was not loaded (or not
> working) back then?

I found two differences:  Gentoo's udev init script autoloads thermal on
boot under 2.6.23-rc2 but it doesn't under 2.6.22(-rc5), for a reason
unknown to me.  If I manually load thermal under 2.6.22(-rc5), the
oscillation happens too --- also in the rythm of ksensors' update
interval but with a slightly different partition into div = 8 periods
and div = 128 periods.  Ksensors then happens to display the correct div
= 8 reading, while sensors shows either the wrong or the correct reading
depending on the moment it is issued.  By playing with the update
intervals in ksensors, ksensors can be tricked into getting the correct
value under 2.6.23-rc2 too.

So, it isn't really a regression from 2.6.22 to 2.6.23-rc1.  It merely
became more apparent after 2.6.23-rc1.

And yes, "cat /proc/acpi/thermal_zone/THRM/temperature" causes the CPU
fan divider to flip to 128 immediately.
-- 
Stefan Richter
-=====-=-=== =--- -==--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists