Ticket #2356 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

it87 in 2.6.27: no fan divisors, fan speeds are wrong

Reported by: ticket Owned by: khali
Priority: major Milestone:
Component: kernel Version: kernel
Keywords: it87 fan_speed Cc: mjt+lmsensors@…

Description (last modified by khali) (diff)

Just updated my system to 2.6.27, and the first thing I noticed is that sensors now shows wrong fan speeds, as it was the (fixed) case before.

It's an Asus M3A78-EM motherboard (AMD 780G/SB700 chipset), with "IT8712F chip at 0x290, revision 8" sensor (from dmesg). On 2.6.26 and before, I used to set fan*_div to higher value (not the default of 2), or else fan speeds were way off. My only fan in the PSU is usually rotating at 400..800RPM, and it is connected to the CPU Fan connector, with which it was possible to set fan1_div to 16 or even 32, not to 8 max as with PSU Fan connector (which were not sufficient to get correct speeds). Now, as there's no fan_div anymore, it again shows incorrect fan speed. Right now:

it8712-isa-0290
Adapter: ISA adapter
VCore 1:     +0.99 V  (min =  +4.02 V, max =  +4.08 V)   ALARM
VCore 2:     +3.68 V  (min =  +4.05 V, max =  +4.08 V)   ALARM
+3.3V:       +3.33 V  (min =  +4.02 V, max =  +4.05 V)   ALARM
+5V:         +5.13 V  (min =  +5.99 V, max =  +6.85 V)   ALARM
+12V:       +12.74 V  (min =  +0.00 V, max = +16.32 V)   
-12V:       -15.46 V  (min =  +3.81 V, max =  +3.93 V)   ALARM
-5V:         +4.03 V  (min =  +3.96 V, max =  +4.03 V)   ALARM
Stdby:       +6.42 V  (min =  +0.00 V, max =  +6.83 V)   
VBat:        +3.28 V
PSU Fan:    4753 RPM  (min =  399 RPM)
CPU Temp:    +38.0°C  (low  = +65.0°C, high = +70.0°C)  sensor = transistor
M/B Temp:    +41.0°C  (low  = +60.0°C, high = +65.0°C)  sensor = transistor
cpu0_vid:   +1.550 V

(don't ask about voltages - did not get there yet, all I need are the fans and the temps).

I don't remember if the value reported was the same as with 2.6.26 without fan_div tweaks. The thing is that it obviously changes since fan speed follows temperature, and is controlled by the circuit in the PSU. What I remember for sure is that *after* upping fan_div on 2.6.26, the value more-or-less matched the same value as reported by bios (esp. when a fan is attached to non-regulated connector or when q-fan feature is turned off).

I've seen the diff between 2.6.26 and 2.6.27, and understand my sensor *should* work out of the box. But it doesn't. It looks like the divisor should be somewhere in the driver instead, or the driver is reading the wrong value.

By the way, very similar effects were observed on many other Asus motherboards with it8712 chips.

Thanks!

Change History

Changed 6 years ago by khali

  • owner changed from somebody to khali
  • status changed from new to assigned
  • description modified (diff)

fan_div is not supposed to change the reported fan speed in the first place. If it did, then it means that the it87 driver in kernels <= 2.6.26 did not handle your chip properly. This is a known problem for the IT8712F revision 8, which we tried to fix in kernel 2.6.27. Maybe the fix isn't perfect, but you shouldn't consider that the 2.6.27 kernel broke your fan sensors: they were not working before either.

What's your PSU model? 400 RPM is very slow for a computer fan.

While the fan speed reported in the BIOS is a good hint, I wouldn't blindly trust it. It is possible that the BIOS engineers missed the fact that revision 8 of the IT8712F was not compatible with earlier revision and the BIOS reports an incorrect speed. It would be very useful if you could try the same PSU on another motherboard where the hardware monitoring chip is known to report accurate fan speeds.

Please attach a dump of your chip:

rmmod it87
isadump 0x295 0x296

Changed 6 years ago by ticket

The fan in the PSU is taken from a Scythe Ninja Plus Rev. B CPU Cooler - I replaced a fan in my PSU with that one. It's from Scythe Streamline series, I don't remember exactly its rating but think it's either 1000 or 1200 model (nominal RPM at nominal voltage, -- i.e., it should rotate at 1000RPM (or 1200) given 12V input). The in-PSU regulator at normal temperature gives about 4.5 volts to it, so it's not that wrong for it to rotate at ~400RPM. I tested it at 2.5 volts (without measuring RPMs) and it starts and rotates pretty stable. I can try to connect it to another mobo with it8718 chip, which will be somewhat... problematic due to all the case mods I did.. ;) That to say - maybe it's not exactly 400, but it's not that far from reality.

I rebooted into 2.6.26, and here's the current readings:

PSU Fan:     598 RPM  (min =  399 RPM, div = 16)
CPU Temp:    +39.0°C  (low  = +65.0°C, high = +70.0°C)  sensor = transistor
M/B Temp:    +42.0°C  (low  = +60.0°C, high = +65.0°C)  sensor = transistor

That does not look completely wrong.. ;)

Here's isadump:

# isadump 0x295 0x296
I will probe address register 0x295 and data register 0x296.
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 11 04 6f 00 00 00 00 00 00 80 40 64 07 8c ff ff 
10: d3 ff fe 77 87 7f 7f 7f 00 ff ff 06 ff 05 05 05 
20: 3e e6 cf bf c7 60 ff ef cd 27 2a 80 fe f5 f5 f5 
30: ff fb ff fd fd fb ff df ff 00 ff fe ff fe fe 00 
40: 46 41 41 3c fb ff ff ff 2d ff ff ff ff ff ff ff 
50: 35 18 7f 7f 7f 00 40 56 90 56 ff 12 80 00 00 00 
60: 7f 7f 7f 00 00 7f ff ff 7f 7f 7f 00 00 7f ff ff 
70: 7f 7f 7f 00 00 7f ff ff ff ff ff ff ff ff ff ff 
80: 00 00 00 00 ff ff ff 3e 00 00 ff c0 02 00 99 99 
90: 7f 7f 7f 00 00 7f ff ff 7f 7f 7f 00 00 7f ff ff 
a0: 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff 
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

(and yes, I did (or tried) something in order to reduce overall noise level of this system, in particular by "inventing" air-flow channel that goes over HDD, north bridge, south bridge, the CPU power circuity, CPU cooler and into the PSU where the only fan is. It's an AMD 780G-based system with 4850e (45W) CPU and a quiet HDD and DVD-drive. The case itself is modified a bit too, I added noise dampering foam into the mix, covering almost all internal surfaces of the case. The end result is that only HDD seeking is audible, and even that only during nights when ambient noise level is the lowest possible. Over than that, the system is almost silent. Even the beeper is almost inaudible, thanks to all the dampering... ;) After 40 mins of burning the CPU (4x `openssl speed' processes), GPU (displaying a DVD fullscreen), and HDD (running SMART selftest), the max temp of the CPU (it is the last component of my air-flow channel before the PSU) will be ~55..58 degrees Celsius, with the fan rotating at ~950RPM, according to the 2.6.26 it87 driver with fan_div=16).

Changed 6 years ago by khali

It is very difficult for tachometers to read fan speeds properly when the voltage drops below a certain limit. +4.5V for a +12V fan is pretty low, so I am not surprised that the fan speed readings are wacky.

A good test would be to connect a normal fan (+12V, not regulated) with known nominal speed to one of the fan headers of your motherboard, with kernel 2.6.27. I wouldn't be surprised if the fan speed was reported just fine.

As a general rule, unless the fan speed is controlled by the monitoring chip itself or you use a 4-wire fan, fan speed monitoring and fan speed control become mutually exclusive at some point.

Changed 6 years ago by ticket

The thing is that "normal fan" readings are right in all cases - with any fan_div value with 2.6.26, with 2.6.27 and in BIOS. It's only the low-RPM values which are incorrect with 2.6.27 or with low fan_div with 2.6.26 (but not in BIOS). I.e., it seems that the thing actually works.

Here are some more details.

2.6.26, fan_div=2 (default), slowing the fan down (with a variable resistor) from 2000 RPM (nominal 12V). Up to some value the reading is ok, decreasing up to ~1000. After which the reading jumps up to 6000. Normal value can be restored back by setting fan_div to 4 (or any higher value - does not matter). Decreasing the speed further again results in the value jumping, from ~800 back to ~6000. It's again fixable with fan_div=8+.

I wasn't able to test "slower" bad points (with larger fan_div values), since this fan I were used for testing works quite unstable below ~500RPM (or the tachometer, or both).

With fan_div=16, all speeds at least in range 500..2000RPM are shown correctly, or, rather, realistically. And if the value looks realistically, increasing fan_div does not change it: e.g. a 2000RPM fan at nominal speed is shown as such (2000) with 2,4,8, or 16 fan_div.

So... I'm pretty much sure the thing works, at least somehow. Yes I understand the specs says there' no divisors in this revision of the chip (honestly I didn't read it - probably I should), but changing fan_div works in 2.6.26. And with 2.6.27, it does not anymore.

Changed 5 years ago by ticket

And today I noticed that the whole issue is really a non-issue, yet may be useful still.

The thing is that the wrong reading of 2.6.27 happens only AFTER 2.6.26 were booted before. If I power-cycle the system and freshly boot 2.6.27, it shows correct values right away, be it 400RPM or 4000RPM (by "correct" here, again, I mean more-or-less close to reality, not completely unreal numbers).

In other words, 2.6.26 seems to be doing some hardware programming which results in a wrong state of the chip in 2.6.27, which does not do that programming nor does it do the "restoration" of it (and the bios does not reset the config back, either).

There is still a possible improvement for 2.6.27 version, namely, to re-do the programming that was done by 2.6.26. But equally effective and much more easy "fix" is to power-cycle the machine. After which, it all gets restored back to life.

And hence this ticket can be closed now.

Changed 5 years ago by khali

  • status changed from assigned to closed
  • resolution set to fixed

Thanks for the follow-up :)

Note: See TracTickets for help on using tickets.