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@xxxxxxxx> 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@xxxxxxxxx>
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@xxxxxxxxxxxx
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
--------------------------------------------------------------------------------
# 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)_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
