Hello
I have problem with lm_sensors (Ver: 2.8.7 Release: 4mdk) in my new Mandrake 10.1 (kernel 2.6.8.1-24mdk).
HW: QDI KinetiZ 7EA (via kt133a/686b), Duron 866, DIMM 128 + DIMM 64
On my Mandrake 9.2 (kernel 2.4.22) was everything OK. DIMM modules were identified, via686 sensors too and all was accesable via /proc/sys/dev/sensors too.
Now:
1. there is no interface in /proc ?! (module i2c-proc (like in lm_sensors for 2.4 kernel ?))
2. eeprom module gives no information
---- /etc/sysconfig/lm_sensors (generated by sensors-detect):
MODULE_0=i2c-viapro
MODULE_1=i2c-isa
MODULE_2=eeprom
MODULE_3=via686a
----
With this sequence was everything wrong :
---- log by starting service lm_sensors:
Apr 23 13:10:21 zly-hugo sensord: sensord started
Apr 23 13:10:21 zly-hugo sensord: Chip: eeprom-i2c-0-51
Apr 23 13:10:21 zly-hugo sensord: Adapter: SMBus Via Pro adapter at 5000
Apr 23 13:10:21 zly-hugo sensord: Algorithm: Unavailable from sysfs
Apr 23 13:10:21 zly-hugo lm_sensors: sensord startuje succeeded
Apr 23 13:10:21 zly-hugo sensord: Memory type: SDRAM DIMM SPD
Apr 23 13:10:21 zly-hugo sensord: Memory size (MB): Invalid 12 9 1 4
Apr 23 13:10:21 zly-hugo sensord: Chip: eeprom-i2c-0-50
Apr 23 13:10:21 zly-hugo sensord: Adapter: SMBus Via Pro adapter at 5000
Apr 23 13:10:21 zly-hugo sensord: Algorithm: Unavailable from sysfs
Apr 23 13:10:21 zly-hugo sensord: Memory type: SDRAM DIMM SPD
Apr 23 13:10:21 zly-hugo sensord: Memory size (MB): Invalid 12 9 2 4
Apr 23 13:12:47 zly-hugo sensord: sensord stopped
Apr 23 13:12:47 zly-hugo lm_sensors: ukon?en? sensord succeeded
----
After changing it to:
----
MODULE_0=i2c-isa
MODULE_1=eeprom
MODULE_2=via686a
MODULE_3=i2c-viapro
----
---- new log:
Apr 23 13:13:27 zly-hugo sensord: sensord started
Apr 23 13:13:27 zly-hugo sensord: Chip: via686a-isa-6000
Apr 23 13:13:27 zly-hugo sensord: Adapter: ISA adapter
Apr 23 13:13:27 zly-hugo sensord: Algorithm: ISA algorithm
Apr 23 13:13:27 zly-hugo sensord: CPU core: +1.67 V (min = +1.50 V, max = +1.80 V)
Apr 23 13:13:27 zly-hugo sensord: +3.3V: +3.47 V (min = +3.20 V, max = +3.60 V)
Apr 23 13:13:27 zly-hugo sensord: +5V: +4.98 V (min = +4.73 V, max = +5.20 V)
Apr 23 13:13:27 zly-hugo sensord: +12V: +12.79 V (min = +11.53 V, max = +13.02 V)
Apr 23 13:13:27 zly-hugo sensord: CPU Fan: 5973 RPM (min = 0 RPM, div = 2)
Apr 23 13:13:27 zly-hugo sensord: P/S Fan: 0 RPM (min = 0 RPM, div = 1)
Apr 23 13:13:27 zly-hugo sensord: CPU Temp: 48.5 C (limit = 56 C, hysteresis = 53 C)
Apr 23 13:13:27 zly-hugo sensord: SYS Temp: 34.7 C (limit = 40 C, hysteresis = 35 C)
Apr 23 13:13:27 zly-hugo lm_sensors: sensord startuje succeeded
----
Also: there is nothing about eeprom to see :-( , but important sensors now YES :-)
But in /proc nothing to find ?! From where "sensors" or "ksysgurad", ... are taking sensor values, when not from /proc fs ?
Directly from /dev/i2c* devices ??
---- lsmod | egrep "i2c|eeprom":
i2c-viapro 5900 0
eeprom 6248 0
i2c-sensor 2240 2 via686a,eeprom
i2c-isa 1600 0
i2c-core 19060 5 i2c-viapro,via686a,eeprom,i2c-sensor,i2c-isa
----
---- /etc/modules.conf:
alias autofs autofs4
# I2C module options - did not help
alias char-major-89 i2c-dev
----
Attached are also: - outputs from sensors-detect
- /etc/sensors.conf
- outputs and configs from Mandrake 9.2
Cann You help me, please ?
Thank You Karel Petranek
-------------- next part --------------
-----------------------------------------------------------------
Mandrake 9.2 (2.4.22-10mdk)
lm_sensors Version : 2.8.0 Release : 4mdk
-- lsmod | egrep "i2c|eeprom"
eeprom 4628 0 (unused)
i2c-proc 8116 0 [via686a eeprom]
i2c-isa 1292 0 (unused)
i2c-viapro 4300 0 (unused)
i2c-core 20484 0 [via686a eeprom i2c-proc i2c-isa i2c-viapro]
--
-- sensors
eeprom-i2c-0-50
Adapter: SMBus Via Pro adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type: SDRAM DIMM SPD
Memory size (MB): 128
eeprom-i2c-0-51
Adapter: SMBus Via Pro adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type: SDRAM DIMM SPD
Memory size (MB): 64
via686a-isa-6000
Adapter: ISA adapter
Algorithm: ISA algorithm
CPU core: +1.60 V (min = +1.48 V, max = +1.79 V)
+3.3V: +3.38 V (min = +2.95 V, max = +3.62 V)
+5V: +4.87 V (min = +4.47 V, max = +5.49 V)
+12V: +12.46 V (min = +10.79 V, max = +13.18 V)
CPU Fan: 6081 RPM (min = 3000 RPM, div = 2)
P/S Fan: 0 RPM (min = 3000 RPM, div = 2)
CPU Temp: +42.3?C (limit = +56?C, hysteresis = +53?C)
SYS Temp: +30.1?C (limit = +40?C, hysteresis = +35?C)
--
-- /etc/sysconfig/lm_sensors
MODULE_0=i2c-viapro
MODULE_1=i2c-isa
MODULE_2=eeprom
MODULE_3=via686a
--
-------------- next part --------------
# Sensors configuration file used by 'libsensors'
#------------------------------------------------
#
##########################################################################
# #
# PLEASE READ THIS HELPFUL HINT!!! #
# #
# The 'set' lines (generally for min and max values) #
# do not take effect until you run 'sensors -s' as root !!! #
# We suggest you put 'sensors -s' in a /etc/rc.d/... file #
# to be run at boot time after the modules are inserted !!! #
# #
##########################################################################
#
#
# OVERVIEW
# --------
# This configuration file will be used by all userspace applications
# linked to libsensors. It is NOT used by the lm_sensors drivers directly.
#
# This config file consists of two parts: the heavily commented LM78
# example, and the real parts. Search for '####' if you want to skip
# to the real stuff.
#
# Hash marks introduce comments, which continue until the end of a line
#
# Identifiers consisting of only digits and letters can be used
# unquoted; other identifiers must be quoted. Escape characters within
# quotes operate like those in C.
#
#
# CHIP LINES
# ----------
# A 'chip' line specifies what the following 'label', 'compute', 'set' and
# 'ignore' lines refer to. In this case, until the
# next 'chip' line, everything refers to all lm78, lm78-j and lm79
# chips. Other examples are *-isa-* for everything on the ISA bus, and
# lm78-j-i2c-*-4e for all lm78-j chips on address 0x4e of any I2C bus.
#
# If more chip statements match a specific chip, they are all considered.
# Later lines overrule earlier lines, so if you set the in0 label for
# lm78-* to "This", and later on the in0 label for lm78-isa-* to "That",
# "That" is used for LM78 chips on the ISA bus, and "This" for LM78
# chips on a non-ISA bus.
#
# chip "lm78-*" "lm78-j-*" "lm79-*"
#
#
# FEATURE NAMES
# -------------
# Feature names are used in 'label', 'compute', 'set', and 'ignore' lines.
# Example feature names are 'in0', 'temp2', 'in3_min', and 'temp3_over'.
# These features are defined for each chip in lib/chips.c.
#
# Undefined features will be silently ignored in 'label' and 'compute' lines.
# Undefined features in 'set' lines will result in 'Unknonw feature name'
# when running 'sensors -s'.
#
# Unfortunately, feature names starting with a number must be in
# double quotes or you get 'parse error, expecting 'NAME''.
#
# If you have trouble, verify the features in lib/chips.c!!!
#
#
# LABEL LINES
# -----------
# A label line describes what a certain feature stands for on your
# mainboard. Programs can retrieve these names and display them.
# If no label is specified for a certain feature, the default name
# (ie. 'fan1' for fan1) is used.
#
# If you specify a label for in1, this label is also used for in1_min and
# in1_max, unless they have their own labels declared. There are several
# of these logical groups.
#
# These are as advised in the LM78 and LM79 data sheets, and used on most
# boards we have seen.
#
# label in0 "VCore 1"
# label in1 "VCore 2"
# label in2 "+3.3V"
# label in3 "+5V"
# label in4 "+12V"
# label in5 "-12V"
# label in6 "-5V"
#
#
# COMPUTE LINES
# -------------
# A compute line describes how to scale a certain feature. There are
# two expressions in it: the first describes how the /proc value must
# be translated to a user value, the second how a user value must be
# translated to a /proc value. '@' is the value to operate on. You may
# refer to other readable features (like '2 * vid').
#
# The following operators are valid: + - * / ( ) ^ `
# ^ is e**x and ` is ln(x) (valid in library version 1.4.0 /
# lm_sensors 2.7.1 or higher)
#
# Like for the label statement, there are logical groups here. They are
# sometimes a bit different, though. For example, fan1_div is in the
# logical label group of fan1 (it gets the same label if none is declared
# for it), but it is not in the compute group of fan1 (as it uses a
# completely different system of values).
#
#
# VOLTAGE COMPUTATION DETAILS
# ---------------------------
# Most voltage sensors in sensor chips have a range of 0 to 4.096 Volts.
# This is generally sufficient for the 3.3 and CPU (2.5V, for example)
# supply voltages, so the sensor chip reading is the actual voltage.
#
# Other supply voltages must be scaled with an external resistor network.
# The chip driver generally reports the 'raw' value 0 - 4.09 V, and the
# userspace application must convert this raw value to an actual voltage.
# The 'compute' lines provide this facility.
#
# Unfortunately the resistor values vary among motherboard types.
# Therefore you may have to adjust the computations in this file
# to match your motherboard.
#
# For positive voltages (in3, in4), two resistors are used, with the following
# formula (R1,R2: resistor values, Vs: read voltage, Vin: pin voltage)
# R1 = R2 * (Vs/Vin - 1)
# For negative voltages (in5, in6) two resistors are used, with the following
# formula (Rin,Rf: resistor values, Vs: read voltage, Vin: pin voltage)
# Rin = (Vs * Rf) / Vin
#
# Note: Some chips use a different formula, see it87 section for example.
#
# Here are the official LM78 and LM79 data sheet values.
# Vs R1,Rin R2,Rf Vin
# in3 +5.0 6.8 10 +2.98
# in4 +12.0 30 10 +3.00
# in5 -12.0 240 60 +3.00
# in6 -5.0 100 60 +3.00
#
# These would lead to these declarations:
# compute in3 ((6.8/10)+1)*@ , @/((6.8/10)+1)
# compute in4 ((30/10)+1)*@ , @/((30/10)+1)
# compute in5 -(240/60)*@ , -@/(240/60)
# compute in6 -(100/60)*@ , -@/(100/60)
#
# On almost any mainboard we have seen, the Winbond compute values lead to
# much better results, though.
#
# Vs R1,Rin R2,Rf Vin
# in4 +12.0 28 10 +3.00
# in5 -12.0 210 60.4 +3.00
# in6 -5.0 90.9 60.4 +3.00
#
# These leads to these declarations:
# compute in3 ((6.8/10)+1)*@ , @/((6.8/10)+1)
# compute in4 ((28/10)+1)*@ , @/((28/10)+1)
# compute in5 -(210/60.4)*@ , -@/(210/60.4)
# compute in6 -(90.9/60.4)*@ , -@/(90.9/60.4)
#
#
# SET LINES
# ---------
# Set statements set things like limits. Complete expressions can be
# used. Not everything can sensibly be set: setting 'in0', for example,
# is impossible! These settings are put through the compute translations;
# so if we specify '12.8' for in6, '3.2' will actually be written!
#
# Important note: In the 'sensors' program, these only take effect
# after running 'sensors -s'!!!
#
# Here are some examples:
#
# set in0_max vid*1.05
# set in0_min vid*0.95
# set temp1_over 40
# set temp1_hyst 37
#
# Think of tempx_over as 'alarm set' and tempx_hyst as 'alarm clear'
# thresholds. In most cases the 'over' value should be higher than
# the 'hyst' value by several degrees.
#
#
# IGNORE LINES
# ------------
# Ignore statements tell certain features are not wanted. User programs can
# still read them if they really want, though; this is just an advisory
# marking. 'in0' would also invalidate 'in0_max' and 'in0_min'.
# 'ignore' does not disable anything in the actual sensor chip; it
# simply advises the user program to not access that data.
#
# ignore in0
#
#
# STATEMENT ORDER
# ---------------
# Statements can go in any order, EXCEPT that some statements depend
# on others. Dependencies could be either in the library or the driver.
# A 'compute' statement must go before a 'set' statement
# for the same feature or else the 'set' won't be computed correctly.
# This is a library dependency.
# A 'set fan1_div' statement must go before a 'set fan1_min' statement,
# because the driver uses the divisor in calculating the minimum.
#
#
# BUS LINES
# ---------
# There is one other feature: the 'bus' statement. An example is below.
#
# bus "i2c-0" "SMBus PIIX4 adapter at e800" "Non-I2C SMBus adapter"
#
# If we refer from now on to 'i2c-0' in 'chip' lines, this will run-time
# be matched to this bus. So even if the PIIX4 is called 'i2c-5' at that
# moment, because five other adapters were detected first, 'i2c-0' in
# the config file would always only match this physical bus. In the above
# config file, this feature is not needed; but the next lines would
# only affect the LM75 chips on the PIIX4 adapter:
#
# chip "lm75-i2c-0-*"
#
# You should really use the output of /proc/bus/chips to generate bus lines,
# because one mistyped characted will inhibit the match. Wildcards are not
# yet supported; spaces at the end are ignored, though.
#
#
##########################################################################
#### Here begins the real configuration file
#==============================================================================
chip "lm80-*"
# The values below should be correct if you own a qdi BX (brilliant1)
# mainboard. If not, please contact us, so we can figure out better readings.
# Many thanks go to Peter T. Breuer <ptb at it.uc3m.es> for helping us figure
# out how to handle the LM80.
# For positive voltages (in0..in4), two resistors are used, with the following
# formula (R1,R2: resistor values, Vs: read voltage, Vin: pin voltage)
# R1 = R2 * (Vs/Vin - 1)
# For negative voltages (in5, in6) two resistors are used, with the following
# formula (R3,R4: resistor values, Vs: read voltage, Vin: pin voltage,
# V5: +5V)
# R3 = R4 * (Vs - Vin) / (Vin - V5)
# Here are the official LM78 and LM79 data sheet values.
# Vs R1,R3 R2,R4 Vin
# +2.5V 23.7 75 +1.9
# +3.3V 22.1 30 +1.9
# +5.0 24 14.7 +1.9
# +12.0 160 30.1 +1.9
# -12.0 160 35.7 +1.9
# -5.0 36 16.2 +1.9
# Now curiously enough, VCore is connected with (unknown) resistors, which
# translate a +2.8V to +1.9V. So we use that in the computations below.
label in0 "+5V"
label in1 "VTT"
label in2 "+3.3V"
label in3 "+Vcore"
label in4 "+12V"
label in5 "-12V"
label in6 "-5V"
compute in0 (24/14.7 + 1) * @ , @ / (24/14.7 + 1)
compute in2 (22.1/30 + 1) * @ , @ / (22.1/30 + 1)
compute in3 (2.8/1.9) * @, @ * 1.9/2.8
compute in4 (160/30.1 + 1) * @, @ / (160/30.1 + 1)
compute in5 (160/35.7)*(@ - in0) + @, (@ + in0 * 160/35.7)/ (1 + 160/35.7)
compute in6 (36/16.2)*(@ - in0) + @, (@ + in0 * 36/16.2) / (1 + 36/16.2)
set in0_min 5 * 0.95
set in0_max 5 * 0.95
# What is your VTT? It is probably not this value...
set in1_min 2*0.95
set in1_max 2*1.05
set in2_min 3.3 * 0.95
set in2_max 3.3 * 1.05
# What is your VCore? It is probably not this value...
set in3_min 1.9 * 0.95
set in3_max 1.9 * 1.05
set in4_min 12 * 0.95
set in4_max 12 * 1.05
set in5_min -12 * 1.05
set in5_max -12 * 0.95
set in6_min -5 * 1.05
set in6_max -5 * 0.95
# examples for lm80 temperature limits
# WARNING - nonstandard names and functions for the lm80!!!
# All 4 of these limits apply to the single temperature sensor.
# "hot" is like the standard alarm for most chips.
# "os" is the threshold for the overtemperature shutdown output.
# "os" may or may not do anything on your motherboard but it should
# be set higher than the "hot" thresholds.
# Note that the /proc file 'temp" also has five entries instead of
# the usual three.
# set temp_hot_hyst 45
# set temp_hot_max 52
# set temp_os_hyst 57
# set temp_os_max 62
#==============================================================================
chip "via686a-*"
# VIA is very specific about the voltage sensor inputs, and our labels
# reflect what they say. Unfortunately, they are not at all specific about
# how to convert any of the register values to real units. Fortunately,
# Jonathan Yew <j.teh at iname.com> and Alex van Kaam <darkside at chello.nl>
# came through with some data for temp conversion and formulae for voltage
# conversion. However, the conversions should be regarded as our best guess-
# YMMV.
# On the Tyan S1598, the 2.5V sensor reads 0 and is not displayed in the BIOS.
# Linas Vepstas <linas at linas.org> reports that this sensor shows nothing of
# interest on the Abit KA7 (Athlon), and is also not displayed in the BIOS.
# Likewise, Johannes Drechsel-Burkhard <jdb at chello.at> reports that this
# sensor is unavailable in the BIOS of his MSI K7T Pro (Thunderbird). So,
# if you have one of these boards you may want to uncomment the 'ignore 2.5V'
# line below.
#------------------------------------------------------------------------------
# B?h v? !!!! pro? zrovna u thoto ?ipu nejsou n?zvy tepl. f??ur in0, ...
# P?itom v [/proc/sys/dev/sensors/via686a-isa-6000] ANO ?!!!
# p?vodn? / pozn?mka
label "2.0V" "CPU core"
label "2.5V" "+2.5V"
ignore "2.5V" # p?vodn? zakomentov?no
label "3.3V" "+3.3V" # label "3.3V" "I/O"
label "5.0V" "+5V"
label "12V" "+12V"
label fan1 "CPU Fan"
label fan2 "P/S Fan"
# VIA suggests that temp3 is an internal temp sensor for the 686a. However,
# on the Tyan S1598 as well as the Abit KA7 (Athalon), the absolute values
# of the readings from that sensor are not valid. The readings do seem to
# correlate with temp changes, but the conversion factor may be quite
# different from temp1 & temp2 (as noted above, VIA has not provided
# conversion info). So, you may wish to 'ignore temp3'.
# Johannes Drechsel-Burkhard <jdb at chello.at> notes that on his MSI K7T Pro,
# temp1 is the CPU temp and temp2 is the SYS temp.
# Dle hodnot jde o procesor,a ne "krabici". Proto i upraveny limity n??e.
label temp1 "CPU Temp" # label temp1 "SYS Temp"
# Dle hodnot jde o "krabici", a ne procesor. Proto i upraveny limity n??e.
label temp2 "SYS Temp" # label temp2 "CPU Temp"
label temp3 "SBr Temp"
ignore temp3 # p?vodne zakomentov?no
# Set your CPU core limits here. For the other voltage sensors, the
# built-in defaults should be fine.
# Nev?m, jak? limity jsou p??pustn? -> d?v?m od oka
set in0_min 1.5 # set in0_min 2.0
set in0_max 1.8 # set in0_max 2.5
# MD101 - n?jak mi stoupla nap?t? : 3.3 -> 3.5 a 12 -> 12.9 ??!!
set in2_min 3.2
set in2_max 3.6
set in4_min 11.5
set in4_max 13
# Set your temp limits here. Remember, 'tempX_over' is the temp at which an
# alarm is triggered, and 'tempX_hyst' is the temp at which an alarm turns off.
# Setting tempX_hyst to a few degrees below the corresponding tempX_over
# prevents an oscillation between alarm on and off states. This kind of
# oscillation is known as hyteresis, thus the name. (You typically get the
# most serious and troublesome hysteresis when a sensor triggers something to
# reduce the temp, thus creating a negative feedback loop. Even without that,
# we would still get some oscillation when the temp hovers around the limit
# due to noise.)
# set temp1_hyst 45
# set temp1_over 50
# Po zm?n? FSB z 100 na 133 je procesor teplej?? (z obvykl?ch 41-43 na +- 48) => zvy?uji o +5 stC
# no, ..., asi stoup? v?ce. Po p?ekladu j?dra na 53.1, ale pak u? nechce vychladnout pod 50.4 a i p?i nulov? z?t??i stoup? a? k 51 stC
# po dal??m p?ekladu vystoupila na 54.9 a nevychladla po 51.5
# tedy n?r?st a? o 10 stC
set temp1_hyst 53
set temp1_over 56
# Plat? to v??e, ale pro otestov?n?, zda sensord varuje - i kdy? neloguje ?! pro otestov?n? (po startu ze studena) d?v?m:
# set temp1_hyst 40
# set temp1_over 42
# Ale nejd??ve pro otestov?n? n???? teploty:
# set temp1_hyst 49
# set temp1_over 51
set temp2_hyst 35 # set temp2_hyst 55
set temp2_over 40 # set temp2_over 60
set temp3_hyst 60
set temp3_over 65
# You could set your fan limits too, but the defaults should be fine.
# Ale ne v MD101
set fan1_min 5000
#set fan2_min 5000
# Zde - v MD101 - je d?litel FAN? defaultn? 8 !? Proto:
set fan1_div 2
# For at least one Tyan S1598, the following corrections make the sensors
# readings more in-line with the BIOS readings on boot. Try these, and
# adjust as necessary.
#compute "2.0V" 1.02*@ , @/1.02
#compute "3.3V" 1.02*@ , @/1.02
#compute "5.0V" 1.009*@ , @/1.009
#compute "12V" 1.04*@ , @/1.04
#==============================================================================
-------------- next part --------------
[root at zly-hugo root]# sensors-detect
This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.
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.
You do not need any special privileges for this.
Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-matroxfb' for device 00:0b.0: MGA 1064SG [Mystique]
Use driver `i2c-viapro' for device 00:07.4: VIA Technologies VT82C686 Apollo ACPI
Probe succesfully concluded.
We will now try to load each adapter module in turn.
Load `i2c-matroxfb' (say NO if built into your kernel)? (YES/no):
Module loaded succesfully.
Load `i2c-viapro' (say NO if built into your kernel)? (YES/no):
Module loaded succesfully.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.
To continue, we need module `i2c-dev' to be loaded.
If it is built-in into your kernel, you can safely skip this.
i2c-dev is already loaded.
We are now going to do the adapter probings. Some adapters may hang halfway
through; we can't really help that. Also, some chips will 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. That often
includes address 0x69 (clock chip).
Next adapter: SMBus Via Pro adapter at 5000 (Algorithm unavailable)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x2d
Probing for `Myson MTP008'... Failed!
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `National Semiconductor LM80'... Failed!
Probing for `National Semiconductor LM85'... Failed!
Probing for `Analog Devices ADM1027, ADT7460 or ADT7463'... Failed!
Probing for `SMSC EMC6D100 or EMC6D101'... Failed!
Probing for `National Semiconductor LM87'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83783S'... Failed!
Probing for `Winbond W83791D'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Asus AS99127F (rev.1)'... Failed!
Probing for `Asus AS99127F (rev.2)'... Failed!
Probing for `Asus ASB100 Bach'... Failed!
Probing for `Winbond W83L784R/AR'... Failed!
Probing for `Winbond W83L785R'... Failed!
Probing for `Genesys Logic GL518SM Revision 0x00'... Failed!
Probing for `Genesys Logic GL518SM Revision 0x80'... Failed!
Probing for `Genesys Logic GL520SM'... Failed!
Probing for `Genesys Logic GL525SM'... Failed!
Probing for `Analog Devices ADM9240'... Failed!
Probing for `Dallas Semiconductor DS1780'... Failed!
Probing for `National Semiconductor LM81'... Failed!
Probing for `Analog Devices ADM1026'... Failed!
Probing for `Analog Devices ADM1025'... Failed!
Probing for `Philips NE1619'... Failed!
Probing for `Analog Devices ADM1024'... Failed!
Probing for `Analog Devices ADM1029'... Failed!
Probing for `Analog Devices ADM1030'... Failed!
Probing for `Analog Devices ADM1031'... Failed!
Probing for `Analog Devices ADM1022'... Failed!
Probing for `Texas Instruments THMC50'... Failed!
Probing for `ITE IT8705F / IT8712F / SiS 950'... Failed!
Probing for `ALi M5879'... Failed!
Client found at address 0x50
Probing for `SPD EEPROM'... Success!
(confidence 8, driver `eeprom')
Probing for `DDC monitor'... Failed!
Probing for `Maxim MAX6900'... Failed!
Client found at address 0x51
Probing for `SPD EEPROM'... Success!
(confidence 8, driver `eeprom')
Client found at address 0x69
Some chips are also accessible through the ISA bus. ISA probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.
Do you want to scan the ISA bus? (YES/no):
Probing for `National Semiconductor LM78'
Trying address 0x0290... Failed!
Probing for `National Semiconductor LM78-J'
Trying address 0x0290... Failed!
Probing for `National Semiconductor LM79'
Trying address 0x0290... Failed!
Probing for `Winbond W83781D'
Trying address 0x0290... Failed!
Probing for `Winbond W83782D'
Trying address 0x0290... Failed!
Probing for `Winbond W83627HF'
Trying address 0x0290... Failed!
Probing for `Winbond W83697HF'
Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
Trying general detect... Success!
(confidence 9, driver `via686a')
Probing for `VIA Technologies VT8231 Integrated Sensors'
Trying general detect... Failed!
Probing for `ITE IT8705F / IT8712F / SiS 950'
Trying address 0x0290... Failed!
Probing for `IPMI BMC KCS'
Trying address 0x0ca0... Failed!
Probing for `IPMI BMC SMIC'
Trying address 0x0ca8... Failed!
Some Super I/O chips may also contain sensors. Super I/O probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.
Do you want to scan for Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
Failed! (skipping family)
o you want to scan for secondary Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
Failed! (skipping family)
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `eeprom' (should be inserted):
Detects correctly:
* Bus `SMBus Via Pro adapter at 5000' (Algorithm unavailable)
Busdriver `i2c-viapro', I2C address 0x50
Chip `SPD EEPROM' (confidence: 8)
* Bus `SMBus Via Pro adapter at 5000' (Algorithm unavailable)
Busdriver `i2c-viapro', I2C address 0x51
Chip `SPD EEPROM' (confidence: 8)
Driver `via686a' (should be inserted):
Detects correctly:
* ISA bus, undetermined address (Busdriver `i2c-isa')
Chip `VIA Technologies VT82C686 Integrated Sensors' (confidence: 9)
I will now generate the commands needed to load the I2C modules.
Sometimes, a chip is available both through the ISA bus and an I2C bus.
ISA bus access is faster, but you need to load an additional driver module
for it. If you have the choice, do you want to use the ISA bus or the
I2C/SMBus (ISA/smbus)?
To make the sensors modules behave correctly, add these lines to
/etc/modules.conf:
#----cut here----
# I2C module options
alias char-major-89 i2c-dev
#----cut here----
To load everything that is needed, add this to some /etc/rc*
#----cut here----
# I2C adapter drivers
modprobe i2c-viapro
modprobe i2c-isa
# I2C chip drivers
modprobe eeprom
modprobe via686a
# sleep 2 # optional
/usr/local/bin/sensors -s # recommended
#----cut here----
WARNING! If you have some things built into your kernel, the list above
will contain too many modules. Skip the appropriate ones! You really should
try these commands right now to make sure everything is working properly.
Monitoring programs won't work until it's done.
Do you want to generate /etc/sysconfig/lm_sensors? (YES/no):
Copy prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors
for initialization at boot time.
[root at zly-hugo root]#
