[lm-sensors] Creating alarm for fans

[Karl Schmidt]

Jean Delvare wrote:
> Hi Karl,
> 
> On Sat, 05 Sep 2009 17:03:40 -0500, Karl Schmidt wrote:
>> No size specified (using byte-data access)
>> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>> I will probe file /dev/i2c-1, address 0x2e, mode byte
>> Continue? [Y/n] y
>>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
>> 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff    ................
>> 20: 64 79 c3 c3 c1 24 1a 17 b2 02 95 02 aa 02 ab 02    dy???$??????????
>> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5c 89    ..............\?
>> 40: 05 00 00 00 00 4d 00 ff 00 ff 00 ff 00 ff 81 7f    ?....M........??
>> 50: 81 7f 81 7f a3 02 58 02 ff ff ff ff 02 02 02 a7    ??????X?....????
>> 60: a7 a7 e0 00 00 00 00 2d 2d 2d 64 64 64 44 40 00    ???....---dddD at .
>> 70: 00 00 00 09 09 09 09 09 09 00 30 00 40 00 00 1c    ...??????.0. at ..?
>> 80: 00 a4 00 00 44 2a 86 c3 0d 00 4d 4d 0b 0b 0c 00    .?..D*???.MM???.
>> 90: cc cc cc cc 0c 0c 0c 5a f1 c0 ae 00 ff 00 ff 00    ???????Z???.....
>> a0: 00 00 0c 00 00 00 00 0b 0b fe ff fe ff ff ff ff    ..?....???.?....
>> b0: ff 00 00 00 00 00 28 28 0e 0e 2b 2b 00 00 00 00    ......((??++....
>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
>> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
>> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 
> I have just checked the DME1737 datasheet. This chip doesn't have
> real-time status registers but interrupt status registers. In these
> registers, each bit can be enabled or disabled individually. If
> interrupts are globally enabled, this lets the vendor decide which
> events should trigger an interrupt.
> 
> The interrupt enable registers are at 0x7E, 0x80 and 0x82. As you can
> see, you have only zeroes in these registers, meaning that all
> interrupts are disabled. This is why you don't see any alarm flag.
> According to the datasheet, this isn't the default value. So this
> suggests your mainboard vendor willingly disabled all the individual
> interrupt bits.
> 
> The global interrupt enable flag is also disabled (register 0x7c bit
> 2), which is the default. This makes me wonder why the vendor disabled
> the individual bits, given that they wouldn't trigger any interrupt
> anyway.

Strange - I dug up a new BIOS I can put in the unit - I need to be physically there to do it.. may 
be a few days.

> 
> Then we may also discuss whether it is desirable to enable individual
> interrupt bits when the rest of the configuration is such that physical
> interrupts will never trigger anyway. If both the global interrupt bit
> and the group enable bits are clear, this should be safe as far as I
> can see. This would let users see the alarm flags even when the BIOS
> disabled them without a good reason. What do you think?
> 
> Karl, I suggest that you go check the BIOS options of your system.
> Maybe there are ways to enable or disable an action (such as beeping or
> thermal throttling) on some hardware monitoring events? This might
> explain what we're seeing. If there are such options, please toggle
> them, check whether this gives your alarms in "sensors", and provide a
> new i2c dump for each relevant combination.
> 
> If you can't find any such option, and want your alarm flags to raise,
> here is how you can do that on your system:
> 
> # modprobe i2c-dev
> # rmmod dme1737
> # i2cset -y 0 0x2e 0x7e 0xec
> # i2cset -y 0 0x2e 0x80 0x7e
> # i2cset -y 0 0x2e 0x82 0x0e
> # modprobe dme1737
> 
> This will restore the interrupt bits to what the datasheet lists as
> the default. I expect this to let you see alarm flags on out-of-limits
> conditions again.
> 

OK - this is what I did in the mean time - just to test:
---------------------------------
# modprobe i2c-dev
root at kiwi:~# rmmod dme1737
root at kiwi:~# i2cset -y 0 0x2e 0x7e 0xec
No size specified (using byte-data access)
Value 0xec written, readback matched
root at kiwi:~# i2cset -y 0 0x2e 0x80 0x7e
No size specified (using byte-data access)
Value 0x7e written, readback matched
root at kiwi:~# i2cset -y 0 0x2e 0x82 0x0e
No size specified (using byte-data access)
Value 0x0e written, readback matched
root at kiwi:~# modprobe dme1737 ignore=1,0x2e

# sensors
k8temp-pci-00c3
Adapter: PCI adapter
temp1:       +20.0°C

dme1737-i2c-0-2e
Adapter: SMBus nForce2 adapter at 1c00
in0:         +2.61 V  (min =  +0.00 V, max =  +2.00 V)   ALARM
in1:         +1.43 V  (min =  +0.00 V, max =  +2.99 V)
in2:         +3.35 V  (min =  +0.00 V, max =  +4.38 V)
in3:         +5.10 V  (min =  +0.00 V, max =  +6.64 V)
in4:        +12.09 V  (min =  +0.00 V, max = +15.94 V)
in5:         +3.30 V  (min =  +0.00 V, max =  +4.38 V)
in6:         +3.00 V  (min =  +0.00 V, max =  +4.38 V)
fan1:       7826 RPM  (min = 8000 RPM)
fan2:       8157 RPM  (min = 9000 RPM)
fan3:       7929 RPM  (min =    0 RPM)
fan4:       7894 RPM  (min =    0 RPM)
temp1:       +36.2°C  (low  = -127.0°C, high = +127.0°C)
temp2:       +26.3°C  (low  = -127.0°C, high = +127.0°C)
temp3:       +22.9°C  (low  = -127.0°C, high = +127.0°C)
cpu0_vid:   +1.550 V
----------------------------------------

I did get the voltage alarm that is set! But sadly still no fan alarms, but you are obviously on the 
correct track.

I will the latest BIOS in and retest - In the BIOS change-logs.. I have version 3.00

There are these changes:
* Adjusted CPU temperature readings
* Changed the routing for the SMDC card to IRQ4
* Updated AMD PowerNOW! functionality

http://www.tyan.com/support_download_bios.aspx?model=S.S2865

I bet this will fix things -- will let you know and supply a config with BIOS comments etc..
I will also check that PNPOS is set to off - see if there are any sensor settings etc.. Anyother 
BIOS settings to look for ?


Thanks again..




--------------------------------------------------------------------------------
Karl Schmidt                                  EMail Karl at xtronics.com
Transtronics, Inc.                              WEB http://xtronics.com
3209 West 9th Street                             Ph (785) 841-3089
Lawrence, KS 66049                              FAX (785) 841-0434

42.7% of all statistics are made up on the spot.

--------------------------------------------------------------------------------