Re: [lm-sensors] Creating alarm for fans

[Karl Schmidt <karl@xtronics.com>]

[-- Attachment #1: Type: text/plain, Size: 7453 bytes --]

Jean Delvare wrote:
> Hi Karl,
> 
> On Fri, 04 Sep 2009 16:40:13 -0500, Karl Schmidt wrote:
>> Jean Delvare wrote:
>>> Hi Karl,
>>>
>>>
>>> Alarms are computed by the chips in hardware. "sensors" merely reports
>>> what the driver tells it to, and the driver in turn merely reports the
>>> hardware state.
>> Let me make sure I have this correct - lm-sensor would then have to put a value
>> into a register in the hardware-sensor-chip and then the chip creates the alarm?
> 
> Yes, this is the idea. The chip's limits are programmed using "set"
> statements in /etc/sensors3.conf, which are written to the chip using
> "sensors -s". After that, the comparisons and alarm raising is done by
> the chip itself.
> 
>>> It is interesting that you have two full-featured hardware monitoring
>>> chips in your system. I'm rather surprised, I admit.
>> I'm wondering if it is really just one chip - I tried commenting out one at a time to see if somehow 
>> appearing twice was the problem. I think it may be a host image due to incomplete hard ware encoding.
>>
>>
>> This is a Tyan S2865
>>
>> In case there is something being misidentified I have the spec sheet link here:
>>
>> ftp://ftp.tyan.com/datasheets/d_s2865_100.pdf
>>
>>
>> The lm-config from tyan has:
>>
>> #To your etc/modules.conf file, add the lines:
>> # 	alias char-major-89 i2c-dev
>> #
>> # To your /etc/rc.xxx files, add the lines:
>> # 	modprobe i2c-nforce2
>> # 	modprobe lm85 force_emc6d100=0,0x2e
>> # sensors -s #
>> # Edited by: Raphael Deng <raphaeld@tyan.com> 03.28.05
>> #
>> # As LM-Sensors not support the SMSC DME1737 Chip, I use the SMSC
>> # EMC6D100 chip to instead of it and the sensor 3.3V StandBy and
>> # Battery Volt cannot be monitored.
>>
>> They then use
>> chip "emc6d100-*"
>>
>> But this was from 2005.. I don't think it is right for todays version??
> 
> Correct, we now do have support for the DME1737, which is definitely
> present on that board.
> 
> I pretty much doubt, OTOH, that the board also has an LM85 chip. The
> configuration file provided by Tyan themselves doesn't mention it, nor
> does the datasheet. And the almost identical readings between both
> chips make me believe this is actually the same chip. So apparently
> Tyan wired the same chip on the 2 SMBus channels, which isn't exactly
> smart.
> 
> Now, one thing I would like to understand is how the lm85 driver was
> loaded in the first place. In the dump you sent, the chip is clearly
> identified as an SMSC chip, with the device ID of the DME1737. So, if
> the lm85 driver identifies this chip as a different device, it must
> have been told to, by the means of a module parameter.
> 
> Please provide the output of:
> 
> modprobe -c | grep lm85

# modprobe -c|grep lm85

[returns nothing ]

#lsmod |grep lm85
lm85                   35492  0
hwmon_vid               7296  2 lm85,dme1737
i2c_core               27936  4 i2c_nforce2,lm85,dme1737,i2c_dev


- ah but looking at /et/modules I have:
---------------------------------
# Generated by sensors-detect on Tue Mar 13 22:13:10 2007
# I2C adapter drivers
i2c-nforce2
# Chip drivers

#make it look like lm85b
lm85 force_lm85b=0,0x2e
#lm85
eeprom
k8temp
# Warning: the required module k8temp is not currently installed
# on your system. For status of 2.6 kernel ports check
# http://www.lm-sensors.org/wiki/Devices. If driver is built
# into the kernel, or unavailable, comment out the following line.
#k8temp

# Generated by sensors-detect on Fri Aug 28 12:15:00 2009
# I2C adapter drivers
i2c-nforce2
------------------

> 
> I bet you have a force_lm85b module parameter there. If so, please
> remove it.
You are correct! Removed it - /etc/modules (modules to load at boot time) now reads:


options dme1737 ignore=1,0x2e
# Generated by sensors-detect on Sat Sep  5 12:51:21 2009
# I2C adapter drivers
i2c-nforce2
# Chip drivers
dme1737
k8temp

?? It is still seeing that chip both times.

dme1737-i2c-0-2e
Adapter: SMBus nForce2 adapter at 1c00
<sinp>
dme1737-i2c-0-2e
Adapter: SMBus nForce2 adapter at 1c00

I rmmod dme1737 - and then
modprobe dme1737 option ignore=1,0x2e

failed to work -

but
modprobe dme1737 ignore=1,0x2e

OK - it now sees just one chip - but alarms still won't work - I think the keyword 'option' 
shouldn't be used in /etc/modules - confirmed with a reboot.

> #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)
> 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:       7917 RPM  (min =    0 RPM)
> fan4:       7929 RPM  (min =    0 RPM)
> temp1:       +37.1°C  (low  = -127.0°C, high = +127.0°C)
> temp2:       +26.8°C  (low  = -127.0°C, high = +127.0°C)
> temp3:       +23.4°C  (low  = -127.0°C, high = +127.0°C)
> cpu0_vid:   +1.550 V

Is it ignoring the wrong one??


More digging <time passes >

There is this ,.,.
# modinfo dme1737
filename:       /lib/modules/2.6.26-2-amd64/kernel/drivers/hwmon/dme1737.ko
license:        GPL
description:    DME1737 sensors
author:         Juerg Haefliger <juergh@gmail.com>
depends:        i2c-core,hwmon-vid
vermagic:       2.6.26-2-amd64 SMP mod_unload modversions
parm:           force_start:Force the chip to start monitoring inputs (bool)
parm:           force_id:Override the detected device ID (ushort)
parm:           force:List of adapter,address pairs to boldly assume to be present (array of short)
parm:           force_dme1737:List of adapter,address pairs which are unquestionably assumed to 
contain a `dme1737' chip (array of short)
parm:           probe:List of adapter,address pairs to scan additionally (array of short)
parm:           ignore:List of adapter,address pairs not to scan (array of short)


> 
> I would also be curious to see the full output sensors-detect after
> unloading both the lm85 and the dme1737 drivers.

See attached

> 
> If I am correct then you should add "options dme1737 ignore=1,0x2e"
> to /etc/modprobe.conf or some such. Then do not load the lm85 driver,
> only the dme1737 driver, and then you should have a single chip showing
> up in the output of "sensors" (except for k8temp of course) and things
> should be somewhat clearer. Only then we can go on with the missing
> alarms problem, if it is still present.'

I figure you will need a new listing of this:





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

Man is the only animal that blushes - or needs to. -- Mark Twain

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

[-- Attachment #2: sensors-detect.txt --]
[-- Type: text/plain, Size: 5603 bytes --]

# sensors-detect revision 5249 (2008-05-11 22:56:25 +0200)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

We can start with probing for (PCI) I2C or SMBus adapters.
Do you want to probe now? (YES/no): Probing for PCI bus adapters...
Use driver `i2c-nforce2' for device 0000:00:01.1: nVidia Corporation nForce4 SMBus (MCP)

We will now try to load each adapter module in turn.
Module `i2c-nforce2' already loaded.
If you have undetectable or unsupported I2C/SMBus adapters, you can have
them scanned by manually loading the modules before running this script.

We are now going to do the I2C/SMBus adapter probings. Some chips may
be double detected; we choose the one with the highest confidence
value in that case.
If you found that the adapter hung after probing a certain address,
you can specify that address to remain unprobed.

Next adapter: SMBus nForce2 adapter at 1c00 (i2c-0)
Do you want to scan it? (YES/no/selectively): Client found at address 0x2e
Handled by driver `dme1737' (already loaded), chip type `dme1737'
Client found at address 0x50
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Yes
    (confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'...                                No
Client found at address 0x51
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Yes
    (confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'...                                No

Next adapter: SMBus nForce2 adapter at 1c40 (i2c-1)
Do you want to scan it? (YES/no/selectively): Client found at address 0x2e
Handled by driver `dme1737' (already loaded), chip type `dme1737'
Client found at address 0x50
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Yes
    (confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'...                                No
Client found at address 0x51
Probing for `Analog Devices ADM1033'...                     No
Probing for `Analog Devices ADM1034'...                     No
Probing for `SPD EEPROM'...                                 Yes
    (confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'...                                No

Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no): Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM78-J' at 0x290...     No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Fintek'...                       No
Trying family `ITE'...                                      No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'...                   No
Trying family `SMSC'...                                     Yes
Found `SMSC DME1737 Super IO'                               
    (hardware monitoring capabilities accessible via SMBus only)

Some south bridges, CPUs or memory controllers may also contain
embedded sensors. Do you want to scan for them? (YES/no): Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   Success!
    (driver `k8temp')
AMD K10 thermal sensors...                                  No
Intel Core family thermal sensor...                         No
Intel AMB FB-DIMM thermal sensor...                         No

Now follows a summary of the probes I have just done.
Just press ENTER to continue: 
Driver `dme1737' (should be inserted):
  Detects correctly:
  * Bus `SMBus nForce2 adapter at 1c00'
    Busdriver `i2c-nforce2', I2C address 0x2e
    Chip `dme1737' (confidence: 6)
  * Bus `SMBus nForce2 adapter at 1c40'
    Busdriver `i2c-nforce2', I2C address 0x2e
    Chip `dme1737' (confidence: 6)

Driver `k8temp' (should be inserted):
  Detects correctly:
  * Chip `AMD K8 thermal sensors' (confidence: 9)

I will now generate the commands needed to load the required modules.
Just press ENTER to continue: 
To load everything that is needed, add this to /etc/modules:

#----cut here----
# I2C adapter drivers
i2c-nforce2
# Chip drivers
dme1737
k8temp
#----cut here----

Do you want to add these lines automatically? (yes/NO)

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors