* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
@ 2006-06-18 10:11 ` Jean Delvare
2006-06-18 14:22 ` Brian Beardall
` (18 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Jean Delvare @ 2006-06-18 10:11 UTC (permalink / raw)
To: lm-sensors
Hi Lou,
First of all, I would suggest that you switch to a better e-mail
client. The one you use doesn't handle character encodings properly,
and generate very crappy HTML code.
> I am running CentOS 4 (uname -r 2.6.9-34.0.1.EL) with an ECS NFORCE3-939 MB
> and AMD Athlon64 3000+ processor
>
> I am having problems with the CPU temp and core voltage value using
> lm-sensors.
> Had to adjust voltages computations for in5 and in6 from a post I found
> regarding a TYAN mb that had the same chip:
>
> compute in5 (@ * (1+4.14)) - (4.096*4.14) , (@ + (4.096*4.14)) / (1+4.14)
>
> compute in6 (@ * (1+2.14)) - (4.096*2.14) , (@ + (4.096*2.14)) / (1+2.14)
These are very board-specific. What makes you think these lines are
correct for your board? Do the displayed values (and labels) match what
the BIOS displays? Many recent motherboards do not monitor negative
voltage lines anymore.
> [root at web etc]# sensors
> it87-isa-0290
> Adapter: ISA adapter
> CPU VCore: +1.07 V (min = +1.28 V, max = +1.42 V) ALARM
> +1.5V: +1.47 V (min = +1.42 V, max = +1.57 V)
> +3.3V: +3.31 V (min = +3.14 V, max = +3.47 V)
> +5V: +4.92 V (min = +4.76 V, max = +5.24 V)
> +12V: +11.71 V (min = +11.39 V, max = +12.61 V)
> -12V: -12.11 V (min = -12.60 V, max = -11.37 V)
> -5V: -4.80 V (min = -5.25 V, max = -4.75 V)
> Stdby: +5.03 V (min = +4.76 V, max = +5.24 V)
> VBat: +2.94 V
> CPU Fan: 3245 RPM (min = 3013 RPM, div = 8)
> Case Fan: 981 RPM (min = 664 RPM, div = 8)
> Temp1: +4?C (low = +15?C, high = +40?C) sensor = thermistor
> Temp2: +30?C (low = +15?C, high = +45?C) sensor = thermistor
>
> Everything looks good except the CPU core voltage and CPU temp.
>
> The bios reads 1.37V for coreV but lm_sensors reads 1.07 consistently.
This can be explained easily. Your Athlon64 3000+ must have the
so-called "Cool'n'Quiet" feature, which lets it adjust voltage and
frequency depending on load. I have a similar processor (Athlon64
3200+, socket 939) those voltage ranges from 1.1V (idle) to 1.4V (full
load.) This seems to be roughly the same for you.
You may try commenting out the following line in your configuration file
(in the it87-* section, of course):
# ignore vid
If the VID pins are properly wired on your system, this should report
the nominal voltage for your CPU and you should see it change depending
on the load.
So it's really only a matter of setting the proper limits for that kind
of CPU. Try the following:
set in0_min 1.1 * 0.95
set in0_max 1.4 * 1.05
> The bios for temps: MB = 31 and CPU = 52. Both are pretty consistent in the
> bios.
>
> The CPU temperature in lm_sensors fluctuates between -5 and 50. I have
> tried using the diode for both temp1 and temp2 and ignoring different
> combinations with no success. If the temperature was consistent I would
> feel better like a correction factor was needed but it is all over the
> place.
What about temp3?
Or there could be an additional temperature sensor on the board. Can we
see the full output of sensors-detect?
> Also the chip designation in sensors.conf is
>
> chip "it87-*" "it8712-*"
>
> If I have just "it8712-*" it does not detect the configuration in the
> sensors.conf and uses all defaults.
In kernel 2.6.9 your chip is identified by the driver as "it87" (see
the first line of "sensors"), but in later kernels it is better
identified as "it8712". We put both in the configuration file so that
the same file works with all kernels.
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
2006-06-18 10:11 ` Jean Delvare
@ 2006-06-18 14:22 ` Brian Beardall
2006-06-18 14:51 ` Jean Delvare
` (17 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Brian Beardall @ 2006-06-18 14:22 UTC (permalink / raw)
To: lm-sensors
On Sun, 2006-06-18 at 12:11 +0200, Jean Delvare wrote:
> Hi Lou,
>
> First of all, I would suggest that you switch to a better e-mail
> client. The one you use doesn't handle character encodings properly,
> and generate very crappy HTML code.
>
> > I am running CentOS 4 (uname -r 2.6.9-34.0.1.EL) with an ECS NFORCE3-939 MB
> > and AMD Athlon64 3000+ processor
> >
> > I am having problems with the CPU temp and core voltage value using
> > lm-sensors.
>
> > Had to adjust voltages computations for in5 and in6 from a post I found
> > regarding a TYAN mb that had the same chip:
> >
> > compute in5 (@ * (1+4.14)) - (4.096*4.14) , (@ + (4.096*4.14)) / (1+4.14)
> >
> > compute in6 (@ * (1+2.14)) - (4.096*2.14) , (@ + (4.096*2.14)) / (1+2.14)
>
> These are very board-specific. What makes you think these lines are
> correct for your board? Do the displayed values (and labels) match what
> the BIOS displays? Many recent motherboards do not monitor negative
> voltage lines anymore.
>
> > [root at web etc]# sensors
> > it87-isa-0290
> > Adapter: ISA adapter
> > CPU VCore: +1.07 V (min = +1.28 V, max = +1.42 V) ALARM
> > +1.5V: +1.47 V (min = +1.42 V, max = +1.57 V)
> > +3.3V: +3.31 V (min = +3.14 V, max = +3.47 V)
> > +5V: +4.92 V (min = +4.76 V, max = +5.24 V)
> > +12V: +11.71 V (min = +11.39 V, max = +12.61 V)
> > -12V: -12.11 V (min = -12.60 V, max = -11.37 V)
> > -5V: -4.80 V (min = -5.25 V, max = -4.75 V)
> > Stdby: +5.03 V (min = +4.76 V, max = +5.24 V)
> > VBat: +2.94 V
> > CPU Fan: 3245 RPM (min = 3013 RPM, div = 8)
> > Case Fan: 981 RPM (min = 664 RPM, div = 8)
> > Temp1: +4?C (low = +15?C, high = +40?C) sensor = thermistor
> > Temp2: +30?C (low = +15?C, high = +45?C) sensor = thermistor
> >
> > Everything looks good except the CPU core voltage and CPU temp.
> >
> > The bios reads 1.37V for coreV but lm_sensors reads 1.07 consistently.
>
> This can be explained easily. Your Athlon64 3000+ must have the
> so-called "Cool'n'Quiet" feature, which lets it adjust voltage and
> frequency depending on load. I have a similar processor (Athlon64
> 3200+, socket 939) those voltage ranges from 1.1V (idle) to 1.4V (full
> load.) This seems to be roughly the same for you.
>
> You may try commenting out the following line in your configuration file
> (in the it87-* section, of course):
> # ignore vid
> If the VID pins are properly wired on your system, this should report
> the nominal voltage for your CPU and you should see it change depending
> on the load.
>
> So it's really only a matter of setting the proper limits for that kind
> of CPU. Try the following:
>
> set in0_min 1.1 * 0.95
> set in0_max 1.4 * 1.05
>
> > The bios for temps: MB = 31 and CPU = 52. Both are pretty consistent in the
> > bios.
> >
> > The CPU temperature in lm_sensors fluctuates between -5 and 50. I have
> > tried using the diode for both temp1 and temp2 and ignoring different
> > combinations with no success. If the temperature was consistent I would
> > feel better like a correction factor was needed but it is all over the
> > place.
I have the same problem with my ECS RX-480A motherboard that uses the
IT8712 super I/O chip. The temperature sensor 2 fluctuates. I'm guessing
that sensors_detect will only detect 1 super I/O chip, and only one
sensor chip in the computer. I too would like to know how to get my
email subject is "IT8712F-A and ECS-RX480A mainboard has erradic CPU
temp." How do we get these ECS boards to behave with the CPU temp? temp3
didn't seem correctly because it's temperature didn't change to the work
load on the CPU. That will probably be the same for yours.
>
> What about temp3?
>
> Or there could be an additional temperature sensor on the board. Can we
> see the full output of sensors-detect?
>
> > Also the chip designation in sensors.conf is
> >
> > chip "it87-*" "it8712-*"
> >
> > If I have just "it8712-*" it does not detect the configuration in the
> > sensors.conf and uses all defaults.
>
> In kernel 2.6.9 your chip is identified by the driver as "it87" (see
> the first line of "sensors"), but in later kernels it is better
> identified as "it8712". We put both in the configuration file so that
> the same file works with all kernels.
>
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
2006-06-18 10:11 ` Jean Delvare
2006-06-18 14:22 ` Brian Beardall
@ 2006-06-18 14:51 ` Jean Delvare
2006-06-18 15:10 ` Brian Beardall
` (16 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Jean Delvare @ 2006-06-18 14:51 UTC (permalink / raw)
To: lm-sensors
Hi Brian,
> > > The bios for temps: MB = 31 and CPU = 52. Both are pretty consistent in the
> > > bios.
> > >
> > > The CPU temperature in lm_sensors fluctuates between -5 and 50. I have
> > > tried using the diode for both temp1 and temp2 and ignoring different
> > > combinations with no success. If the temperature was consistent I would
> > > feel better like a correction factor was needed but it is all over the
> > > place.
>
> I have the same problem with my ECS RX-480A motherboard that uses the
> IT8712 super I/O chip. The temperature sensor 2 fluctuates. I'm guessing
> that sensors_detect will only detect 1 super I/O chip, and only one
> sensor chip in the computer.
Wrong guess. Sensors-detect with detect all hardware monitoring chips
in the system, as long as it knows about them, and in the case of
I2C/SMBus chips, that it has drivers for the busses.
That being said, I still have to see a systems with two Super-I/O chips.
> I too would like to know how to get my
> email subject is "IT8712F-A and ECS-RX480A mainboard has erradic CPU
> temp." How do we get these ECS boards to behave with the CPU temp?
Well, maybe you would have received more help if you had been following
my instructions when I tried to help you.
> temp3
> didn't seem correctly because it's temperature didn't change to the work
> load on the CPU. That will probably be the same for yours.
Maybe, maybe not. Motherboards, even by the same manufacturer, can be
very different in that matter.
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (2 preceding siblings ...)
2006-06-18 14:51 ` Jean Delvare
@ 2006-06-18 15:10 ` Brian Beardall
2006-06-18 15:54 ` Lou Parisi
` (15 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Brian Beardall @ 2006-06-18 15:10 UTC (permalink / raw)
To: lm-sensors
On Sun, 2006-06-18 at 16:51 +0200, Jean Delvare wrote:
> Hi Brian,
>
> > > > The bios for temps: MB = 31 and CPU = 52. Both are pretty consistent in the
> > > > bios.
> > > >
> > > > The CPU temperature in lm_sensors fluctuates between -5 and 50. I have
> > > > tried using the diode for both temp1 and temp2 and ignoring different
> > > > combinations with no success. If the temperature was consistent I would
> > > > feel better like a correction factor was needed but it is all over the
> > > > place.
> >
> > I have the same problem with my ECS RX-480A motherboard that uses the
> > IT8712 super I/O chip. The temperature sensor 2 fluctuates. I'm guessing
> > that sensors_detect will only detect 1 super I/O chip, and only one
> > sensor chip in the computer.
>
> Wrong guess. Sensors-detect with detect all hardware monitoring chips
> in the system, as long as it knows about them, and in the case of
> I2C/SMBus chips, that it has drivers for the busses.
>
> That being said, I still have to see a systems with two Super-I/O chips.
>
> > I too would like to know how to get my
> > email subject is "IT8712F-A and ECS-RX480A mainboard has erradic CPU
> > temp." How do we get these ECS boards to behave with the CPU temp?
>
> Well, maybe you would have received more help if you had been following
> my instructions when I tried to help you.
>
Here is my sensors-detect output:
# sensors-detect revision 1.413 (2006/01/19 20:28:00)
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 `to-be-tested' for device 00:14.0: ATI Technologies Inc ATI
SMBus
We are currently looking for testers for this adapter!
Please see http://secure.netroedge.com/~lm78/newdrivers.html
and/or contact us if you want to help.
Continue...
Probe succesfully concluded.
We will now try to load each adapter module in turn.
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 not loaded. Do you want to load it now? (YES/no):
Module loaded succesfully.
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 PIIX4 adapter at 0400
Do you want to scan it? (YES/no/selectively):
Client found at address 0x30
Client found at address 0x31
Client found at address 0x4c
Probing for `National Semiconductor LM75'... Failed!
Probing for `Dallas Semiconductor DS1621'... Failed!
Probing for `Analog Devices ADM1021'... Failed!
Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
Probing for `Maxim MAX1617'... Failed!
Probing for `Maxim MAX1617A'... Failed!
Probing for `TI THMC10'... Failed!
Probing for `National Semiconductor LM84'... Failed!
Probing for `Genesys Logic GL523SM'... Failed!
Probing for `Onsemi MC1066'... Failed!
Probing for `Maxim MAX1619'... Failed!
Probing for `National Semiconductor LM82/LM83'... Failed!
Probing for `National Semiconductor LM90'... Failed!
Probing for `National Semiconductor LM89/LM99'... Failed!
Probing for `National Semiconductor LM86'... Failed!
Probing for `Analog Devices ADM1032'... Failed!
Probing for `Maxim MAX6657/MAX6658/MAX6659'... Failed!
Probing for `National Semiconductor LM63'... Failed!
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Probing for `Analog Devices ADT7461'... 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
Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively):
Client found at address 0x37
Client found at address 0x50
Probing for `SPD EEPROM'... Success!
(confidence 1, driver `eeprom')
Probing for `DDC monitor'... Success!
(confidence 8, driver `eeprom'), other addresses: 0x51 0x52 0x53
0x54 0x55 0x56 0x57
Probing for `Maxim MAX6900'... Failed!
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 W83627EHF'
Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
Trying general detect... Failed!
Probing for `ITE IT8712F'
Trying address 0x0290... Failed!
Probing for `ITE IT8705F / 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! (0x8712)
Probing for `ITE 8705F Super IO Sensors'
Failed! (0x8712)
Probing for `ITE 8712F Super IO Sensors'
Success... found at address 0x0228
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)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Do 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)
Probing for `Winbond W83627EHF/EHG 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 PIIX4 adapter at 0400'
Busdriver `i2c-piix4', I2C address 0x50
Chip `SPD EEPROM' (confidence: 8)
* Bus `SMBus PIIX4 adapter at 0400'
Busdriver `i2c-piix4', I2C address 0x51
Chip `SPD EEPROM' (confidence: 8)
* Bus `NVIDIA I2C Device'
Busdriver `UNKNOWN', I2C address 0x50 (and 0x51 0x52 0x53 0x54 0x55
0x56 0x57)
Chip `DDC monitor' (confidence: 8)
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus address 0x0228 (Busdriver `i2c-isa')
Chip `ITE 8712F Super IO Sensors' (confidence: 9)
I will now generate the commands needed to load the I2C modules.
If you want to load the modules at startup, generate a config file
below and make sure lm_sensors gets started at boot time; e.g
$ rc-update add lm_sensors default
To make the sensors modules behave correctly, add these lines to
/etc/modules.d/lm_sensors and run modules-update:
#----cut here----
# I2C module options
alias char-major-89 i2c-dev
#----end 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.
To load everything that is needed, execute the commands below...
#----cut here----
# I2C adapter drivers
modprobe i2c-piix4
# modprobe unknown adapter NVIDIA I2C Device
# modprobe unknown adapter NVIDIA I2C Device
# modprobe unknown adapter NVIDIA I2C Device
modprobe i2c-isa
# I2C chip drivers
modprobe eeprom
modprobe it87
# sleep 2 # optional
/usr/bin/sensors -s # recommended
#----end cut here----
Do you want to overwrite /etc/conf.d/lm_sensors? Enter s to specify
other file name?
(yes/NO/s): yes
Done.
> > temp3
> > didn't seem correctly because it's temperature didn't change to the work
> > load on the CPU. That will probably be the same for yours.
>
> Maybe, maybe not. Motherboards, even by the same manufacturer, can be
> very different in that matter.
>
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (3 preceding siblings ...)
2006-06-18 15:10 ` Brian Beardall
@ 2006-06-18 15:54 ` Lou Parisi
2006-06-18 16:55 ` Jean Delvare
` (14 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Lou Parisi @ 2006-06-18 15:54 UTC (permalink / raw)
To: lm-sensors
Thank you very much for the quick response and sorry for the html email. I
have responded below to your questions and comments.
Below I have provided:
* The complete output from my bios screen for monitored values
* My attempts to use the vid parameter
* Information on temp3 that was missing before
* Complete output of sensors-detect.
Thanks again for the help, it is very much appreciated.
-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org]
Sent: Sunday, June 18, 2006 5:11 AM
To: Lou Parisi
Cc: LM Sensors
Subject: Re: [lm-sensors] CPU Temp on ECS NFORCE3-A939
Hi Lou,
First of all, I would suggest that you switch to a better e-mail
client. The one you use doesn't handle character encodings properly,
and generate very crappy HTML code.
> I am running CentOS 4 (uname -r 2.6.9-34.0.1.EL) with an ECS NFORCE3-939
MB
> and AMD Athlon64 3000+ processor
>
> I am having problems with the CPU temp and core voltage value using
> lm-sensors.
> Had to adjust voltages computations for in5 and in6 from a post I found
> regarding a TYAN mb that had the same chip:
>
> compute in5 (@ * (1+4.14)) - (4.096*4.14) , (@ + (4.096*4.14)) /
(1+4.14)
>
> compute in6 (@ * (1+2.14)) - (4.096*2.14) , (@ + (4.096*2.14)) /
(1+2.14)
These are very board-specific. What makes you think these lines are
correct for your board? Do the displayed values (and labels) match what
the BIOS displays? Many recent motherboards do not monitor negative
voltage lines anymore.
[Lou 18-JUN-2006] These values were not reasonable using the defaults. I
searched the web for many configurations trying different ones and these
seem to output reasonable values but you are right my bios does not display
the negative voltages.
My bios displays relatively consistent values with the following values and
labels reproduced from the bios screen below:
CPU VCore 1.37V
+1.5V 1.47V
+3.3V 3.31V
+5V 4.91V
+12V 11.71V
5VSB 5.02V
CPU Temp 53 C
System Temp 31 C
CPU Fan 3245
Sys Fan 992
Pwr Fan 0
> [root at web etc]# sensors
> it87-isa-0290
> Adapter: ISA adapter
> CPU VCore: +1.07 V (min = +1.28 V, max = +1.42 V) ALARM
> +1.5V: +1.47 V (min = +1.42 V, max = +1.57 V)
> +3.3V: +3.31 V (min = +3.14 V, max = +3.47 V)
> +5V: +4.92 V (min = +4.76 V, max = +5.24 V)
> +12V: +11.71 V (min = +11.39 V, max = +12.61 V)
> -12V: -12.11 V (min = -12.60 V, max = -11.37 V)
> -5V: -4.80 V (min = -5.25 V, max = -4.75 V)
> Stdby: +5.03 V (min = +4.76 V, max = +5.24 V)
> VBat: +2.94 V
> CPU Fan: 3245 RPM (min = 3013 RPM, div = 8)
> Case Fan: 981 RPM (min = 664 RPM, div = 8)
> Temp1: +4?C (low = +15?C, high = +40?C) sensor = thermistor
> Temp2: +30?C (low = +15?C, high = +45?C) sensor = thermistor
>
> Everything looks good except the CPU core voltage and CPU temp.
>
> The bios reads 1.37V for coreV but lm_sensors reads 1.07 consistently.
This can be explained easily. Your Athlon64 3000+ must have the
so-called "Cool'n'Quiet" feature, which lets it adjust voltage and
frequency depending on load. I have a similar processor (Athlon64
3200+, socket 939) those voltage ranges from 1.1V (idle) to 1.4V (full
load.) This seems to be roughly the same for you.
You may try commenting out the following line in your configuration file
(in the it87-* section, of course):
# ignore vid
If the VID pins are properly wired on your system, this should report
the nominal voltage for your CPU and you should see it change depending
on the load.
So it's really only a matter of setting the proper limits for that kind
of CPU. Try the following:
set in0_min 1.1 * 0.95
set in0_max 1.4 * 1.05
[Lou 18-JUN-2006] I set the alarm values based on the CPU VCore reported in
the bios. Perhaps this is not correct, I'm not sure. I checked and my
processor does have the Cool'n'Quiet technology. I have had the ignore VID
uncommented but did not figure out how to use it in the sensors.conf. Did a
little more checking on the web and tried out a few more things. Tried to
read vid as per the docs:
# cat /sys/bus/i2c/devices/0-0290/in0_ref
cat: /sys/bus/i2c/devices/0-0290/in0_ref: No such file or directory
Listing of /sys/bus/i2c/devices/0-0290:
# ls /sys/bus/i2c/devices/0-0290
alarms fan3_input in2_max in5_max name temp2_type
detach_state fan3_min in2_min in5_min power temp3_input
fan1_div in0_input in3_input in6_input temp1_input temp3_max
fan1_input in0_max in3_max in6_max temp1_max temp3_min
fan1_min in0_min in3_min in6_min temp1_min temp3_type
fan2_div in1_input in4_input in7_input temp1_type
fan2_input in1_max in4_max in7_max temp2_input
fan2_min in1_min in4_min in7_min temp2_max
fan3_div in2_input in5_input in8_input temp2_min
When I try to use vid in alarm setting in sensors.conf as below:
set in0_min vid * 0.95
set in0_max vid * 1.05
# sensors
it87-isa-0290
Adapter: ISA adapter
CPU VCore: +1.07 V (min = +0.00 V, max = +0.00 V) ALARM
> The bios for temps: MB = 31 and CPU = 52. Both are pretty consistent in
the
> bios.
>
> The CPU temperature in lm_sensors fluctuates between -5 and 50. I have
> tried using the diode for both temp1 and temp2 and ignoring different
> combinations with no success. If the temperature was consistent I would
> feel better like a correction factor was needed but it is all over the
> place.
What about temp3?
[Lou 18-JUN-2006]
Temp3 gives consistently -7C when set to thermistor and consistent +94C when
set to diode. Perhaps temp3 is the correct one and just needs a correction
factor. I will try to get cpuburn running in the next few days and check to
see if temp3 changes and send a new reply.
Or there could be an additional temperature sensor on the board. Can we
see the full output of sensors-detect?
[Lou 18-JUN-2006] Full output of sensors-detect:
# sensors-detect
# sensors-detect revision 1.413 (2006/01/19 20:28:00)
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): YES
Probing for PCI bus adapters...
Use driver `i2c-nforce2' for device 00:01.1: nVidia Corporation nForce3
250Gb SMBus (MCP)
Probe succesfully concluded.
We will now try to load each adapter module in turn.
Load `i2c-nforce2' (say NO if built into your kernel)? (YES/no): YES
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 not loaded. Do you want to load it now? (YES/no): YES
Module loaded succesfully.
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).
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): YES
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 W83627EHF'
Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
Trying general detect... Failed!
Probing for `ITE IT8712F'
Trying address 0x0290... Success!
(confidence 8, driver `it87')
Probing for `ITE IT8705F / 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): YES
Probing for `ITE 8702F Super IO Sensors'
Failed! (0x8712)
Probing for `ITE 8705F Super IO Sensors'
Failed! (0x8712)
Probing for `ITE 8712F Super IO Sensors'
Success... found at address 0x0290
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)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Do you want to scan for secondary Super I/O sensors? (YES/no): YES
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)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus address 0x0290 (Busdriver `i2c-isa')
Chip `ITE 8712F Super IO Sensors' (confidence: 9)
I will now generate the commands needed to load the I2C modules.
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* file:
#----cut here----
# I2C adapter drivers
modprobe i2c-isa
# I2C chip drivers
modprobe it87
# 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): YES
Copy prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors
for initialization at boot time.
> Also the chip designation in sensors.conf is
>
> chip "it87-*" "it8712-*"
>
> If I have just "it8712-*" it does not detect the configuration in the
> sensors.conf and uses all defaults.
In kernel 2.6.9 your chip is identified by the driver as "it87" (see
the first line of "sensors"), but in later kernels it is better
identified as "it8712". We put both in the configuration file so that
the same file works with all kernels.
[Lou 18-JUN-2006] Thank you for the explanation on this.
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (4 preceding siblings ...)
2006-06-18 15:54 ` Lou Parisi
@ 2006-06-18 16:55 ` Jean Delvare
2006-06-18 17:16 ` Brian Beardall
` (13 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Jean Delvare @ 2006-06-18 16:55 UTC (permalink / raw)
To: lm-sensors
Hi Brian,
Please stop dropping Lou from the loop, he is certainly interested in
your case and may not be subscribed to the mailing list.
> Next adapter: SMBus PIIX4 adapter at 0400
> Do you want to scan it? (YES/no/selectively):
> Client found at address 0x30
> Client found at address 0x31
> Client found at address 0x4c
> Probing for `National Semiconductor LM75'... Failed!
> Probing for `Dallas Semiconductor DS1621'... Failed!
> Probing for `Analog Devices ADM1021'... Failed!
> Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
> Probing for `Maxim MAX1617'... Failed!
> Probing for `Maxim MAX1617A'... Failed!
> Probing for `TI THMC10'... Failed!
> Probing for `National Semiconductor LM84'... Failed!
> Probing for `Genesys Logic GL523SM'... Failed!
> Probing for `Onsemi MC1066'... Failed!
> Probing for `Maxim MAX1619'... Failed!
> Probing for `National Semiconductor LM82/LM83'... Failed!
> Probing for `National Semiconductor LM90'... Failed!
> Probing for `National Semiconductor LM89/LM99'... Failed!
> Probing for `National Semiconductor LM86'... Failed!
> Probing for `Analog Devices ADM1032'... Failed!
> Probing for `Maxim MAX6657/MAX6658/MAX6659'... Failed!
> Probing for `National Semiconductor LM63'... Failed!
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
> Probing for `Analog Devices ADT7461'... Failed!
0x4c is a typical address for secondary temperature sensors. This
version of sensors-detect failed to identify it. Please try the latest
version:
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (5 preceding siblings ...)
2006-06-18 16:55 ` Jean Delvare
@ 2006-06-18 17:16 ` Brian Beardall
2006-06-18 18:12 ` Jean Delvare
` (12 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Brian Beardall @ 2006-06-18 17:16 UTC (permalink / raw)
To: lm-sensors
On Sun, 2006-06-18 at 18:55 +0200, Jean Delvare wrote:
> Hi Brian,
>
> Please stop dropping Lou from the loop, he is certainly interested in
> your case and may not be subscribed to the mailing list.
>
> > Next adapter: SMBus PIIX4 adapter at 0400
> > Do you want to scan it? (YES/no/selectively):
> > Client found at address 0x30
> > Client found at address 0x31
> > Client found at address 0x4c
> > Probing for `National Semiconductor LM75'... Failed!
> > Probing for `Dallas Semiconductor DS1621'... Failed!
> > Probing for `Analog Devices ADM1021'... Failed!
> > Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
> > Probing for `Maxim MAX1617'... Failed!
> > Probing for `Maxim MAX1617A'... Failed!
> > Probing for `TI THMC10'... Failed!
> > Probing for `National Semiconductor LM84'... Failed!
> > Probing for `Genesys Logic GL523SM'... Failed!
> > Probing for `Onsemi MC1066'... Failed!
> > Probing for `Maxim MAX1619'... Failed!
> > Probing for `National Semiconductor LM82/LM83'... Failed!
> > Probing for `National Semiconductor LM90'... Failed!
> > Probing for `National Semiconductor LM89/LM99'... Failed!
> > Probing for `National Semiconductor LM86'... Failed!
> > Probing for `Analog Devices ADM1032'... Failed!
> > Probing for `Maxim MAX6657/MAX6658/MAX6659'... Failed!
> > Probing for `National Semiconductor LM63'... Failed!
> > Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
> > Probing for `Analog Devices ADT7461'... Failed!
>
> 0x4c is a typical address for secondary temperature sensors. This
> version of sensors-detect failed to identify it. Please try the latest
> version:
> http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt
>
My output from the latest sensors-detect:
# sensors-detect revision $Revision$ ($Date$)
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-piix4' for device 00:14.0: ATI Technologies Inc ATI
SMBus
Probe succesfully concluded.
We will now try to load each adapter module in turn.
Module `i2c-piix4' already loaded.
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 PIIX4 adapter at 0400
Do you want to scan it? (YES/no/selectively):
Client found at address 0x30
Client found at address 0x31
Client found at address 0x4c
Probing for `National Semiconductor LM75'... Failed!
Probing for `Dallas Semiconductor DS1621'... Failed!
Probing for `Analog Devices ADM1021'... Failed!
Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
Probing for `Maxim MAX1617'... Failed!
Probing for `Maxim MAX1617A'... Failed!
Probing for `TI THMC10'... Failed!
Probing for `National Semiconductor LM84'... Failed!
Probing for `Genesys Logic GL523SM'... Failed!
Probing for `Onsemi MC1066'... Failed!
Probing for `Maxim MAX1619'... Failed!
Probing for `National Semiconductor LM82/LM83'... Failed!
Probing for `National Semiconductor LM90'... Failed!
Probing for `National Semiconductor LM89/LM99'... Failed!
Probing for `National Semiconductor LM86'... Failed!
Probing for `Analog Devices ADM1032'... Failed!
Probing for `Maxim MAX6657/MAX6658/MAX6659'... Failed!
Probing for `National Semiconductor LM63'... Failed!
Probing for `Fintek F75363SG'... Failed!
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Probing for `Analog Devices ADT7461'... Failed!
Probing for `Fintek F75383S/M'... Success!
(confidence 7, driver `to-be-written')
Client at address 0x50 can not be probed - unload all client drivers
first!
Client at address 0x51 can not be probed - unload all client drivers
first!
Client found at address 0x69
Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively):
Next adapter: NVIDIA I2C Device
Do you want to scan it? (YES/no/selectively):
Client found at address 0x37
Client found at address 0x50
Probing for `SPD EEPROM'... Success!
(confidence 1, driver `eeprom')
Probing for `DDC monitor'... Success!
(confidence 8, driver `eeprom'), other addresses: 0x51 0x52 0x53
0x54 0x55 0x56 0x57
Probing for `Maxim MAX6900'... Failed!
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 W83627EHF'
Trying address 0x0290... Failed!
Probing for `Winbond W83627DHG'
Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
Trying general detect... Failed!
Probing for `ITE IT8712F'
Trying address 0x0290... Failed!
Probing for `ITE IT8705F / 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! (0x8712)
Probing for `ITE 8705F Super IO Sensors'
Failed! (0x8712)
Probing for `ITE 8712F Super IO Sensors'
Success... found at address 0x0228
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)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Do 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)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `to-be-written' (should be inserted):
Detects correctly:
* Bus `SMBus PIIX4 adapter at 0400'
Busdriver `i2c-piix4', I2C address 0x4c
Chip `Fintek F75383S/M' (confidence: 7)
Driver `eeprom' (should be inserted):
Detects correctly:
* Bus `NVIDIA I2C Device'
Busdriver `UNKNOWN', I2C address 0x50 (and 0x51 0x52 0x53 0x54 0x55
0x56 0x57)
Chip `DDC monitor' (confidence: 8)
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus address 0x0228 (Busdriver `i2c-isa')
Chip `ITE 8712F Super IO Sensors' (confidence: 9)
I will now generate the commands needed to load the I2C modules.
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* file:
#----cut here----
# I2C adapter drivers
modprobe i2c-piix4
# modprobe unknown adapter NVIDIA I2C Device
# modprobe unknown adapter NVIDIA I2C Device
# modprobe unknown adapter NVIDIA I2C Device
modprobe i2c-isa
# I2C chip drivers
# no driver for Fintek F75383S/M yet
modprobe eeprom
modprobe it87
# 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): no
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (6 preceding siblings ...)
2006-06-18 17:16 ` Brian Beardall
@ 2006-06-18 18:12 ` Jean Delvare
2006-06-18 19:58 ` Jean Delvare
` (11 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Jean Delvare @ 2006-06-18 18:12 UTC (permalink / raw)
To: lm-sensors
Hi Lou,
> > > The bios reads 1.37V for coreV but lm_sensors reads 1.07 consistently.
> >
> > This can be explained easily. Your Athlon64 3000+ must have the
> > so-called "Cool'n'Quiet" feature, which lets it adjust voltage and
> > frequency depending on load. I have a similar processor (Athlon64
> > 3200+, socket 939) those voltage ranges from 1.1V (idle) to 1.4V (full
> > load.) This seems to be roughly the same for you.
> >
> > You may try commenting out the following line in your configuration file
> > (in the it87-* section, of course):
> > # ignore vid
> > If the VID pins are properly wired on your system, this should report
> > the nominal voltage for your CPU and you should see it change depending
> > on the load.
> >
> > So it's really only a matter of setting the proper limits for that kind
> > of CPU. Try the following:
> >
> > set in0_min 1.1 * 0.95
> > set in0_max 1.4 * 1.05
>
> I set the alarm values based on the CPU VCore reported in
> the bios. Perhaps this is not correct, I'm not sure. I checked and my
> processor does have the Cool'n'Quiet technology.
I guess that either the Cool'n'Quiet is disabled when in the BIOS
screen, or the BIOS is in a tight loop waiting for a key to be pressed
and this keeps the CPU busy. Either way this means that the highest
voltage is used.
> I have had the ignore VID
> uncommented but did not figure out how to use it in the sensors.conf. Did a
> little more checking on the web and tried out a few more things. Tried to
> read vid as per the docs:
> # cat /sys/bus/i2c/devices/0-0290/in0_ref
> cat: /sys/bus/i2c/devices/0-0290/in0_ref: No such file or directory
The file would in fact be named cpu0_vid (it changed in 2.6.9.)
> Listing of /sys/bus/i2c/devices/0-0290:
> # ls /sys/bus/i2c/devices/0-0290
> alarms fan3_input in2_max in5_max name temp2_type
> detach_state fan3_min in2_min in5_min power temp3_input
> fan1_div in0_input in3_input in6_input temp1_input temp3_max
> fan1_input in0_max in3_max in6_max temp1_max temp3_min
> fan1_min in0_min in3_min in6_min temp1_min temp3_type
> fan2_div in1_input in4_input in7_input temp1_type
> fan2_input in1_max in4_max in7_max temp2_input
> fan2_min in1_min in4_min in7_min temp2_max
> fan3_div in2_input in5_input in8_input temp2_min
So it's not there, as if your chip was detected as an IT8705F instead
of an IT8712F. Are you certain you are running a 2.6.9 kernel? All
these hints suggest an older kernel.
> When I try to use vid in alarm setting in sensors.conf as below:
> set in0_min vid * 0.95
> set in0_max vid * 1.05
>
> # sensors
> it87-isa-0290
> Adapter: ISA adapter
> CPU VCore: +1.07 V (min = +0.00 V, max = +0.00 V) ALARM
Because there is no vid reading, the value of the "vid" symbol is 0.
Anyway you shouldn't use "vid" in compute lines in this case, because
its value changes, and you want to allow the full range your CPU is
allowed to use.
> > What about temp3?
>
> Temp3 gives consistently -7C when set to thermistor and consistent +94C when
> set to diode. Perhaps temp3 is the correct one and just needs a correction
> factor. I will try to get cpuburn running in the next few days and check to
> see if temp3 changes and send a new reply.
No, it's most certainly not correct either.
> Full output of sensors-detect:
> # sensors-detect
> # sensors-detect revision 1.413 (2006/01/19 20:28:00)
> (...)
> 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): YES
> Probing for PCI bus adapters...
> Use driver `i2c-nforce2' for device 00:01.1: nVidia Corporation nForce3
> 250Gb SMBus (MCP)
> Probe succesfully concluded.
Support for this chip was only added in 2.6.11, and although
sensors-detect knows which driver should be used (i2c-nforce2), the
driver doesn't know it should support your chip. As a result, if there
are sensor chips on this bus cannot be accessed.
As I guess you don't really want to upgrade to a more recent kernel,
you should be able to add support for your chip at run time by doing the
following (as root):
$ modprobe i2c-nforce2
$ echo "10de 00e4" > /sys/bus/pci/drivers/nForce2_smbus/new_id
Then run sensors-detect again, and report the results.
> > In kernel 2.6.9 your chip is identified by the driver as "it87" (see
> > the first line of "sensors"), but in later kernels it is better
> > identified as "it8712". We put both in the configuration file so that
> > the same file works with all kernels.
I take that back, 2.6.9 is actually the first kernel which should name
the chip it8712. I'm really surprised it doesn't. Unless you're in fact
using a 2.6.8 kernel.
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (7 preceding siblings ...)
2006-06-18 18:12 ` Jean Delvare
@ 2006-06-18 19:58 ` Jean Delvare
2006-06-18 22:18 ` Brian Beardall
` (10 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Jean Delvare @ 2006-06-18 19:58 UTC (permalink / raw)
To: lm-sensors
Hi Brian,
Quoting myself:
> > Please stop dropping Lou from the loop, he is certainly interested in
> > your case and may not be subscribed to the mailing list.
You did it once again... :(
> My output from the latest sensors-detect:
> # sensors-detect revision $Revision$ ($Date$)
Argh, I hope we can educate trac/subversion to fill these fields on the
fly :(
> Next adapter: SMBus PIIX4 adapter at 0400
> Do you want to scan it? (YES/no/selectively):
> (...)
> Client found at address 0x4c
> (...)
> Probing for `Fintek F75383S/M'... Success!
> (confidence 7, driver `to-be-written')
You have your answer, there is indeed a secondary chip on the
motherboard. Unfortunately no driver exists for this chip yet. I've
updated our NewDrivers page to mention that you would be interested in
a driver.
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (8 preceding siblings ...)
2006-06-18 19:58 ` Jean Delvare
@ 2006-06-18 22:18 ` Brian Beardall
2006-06-19 3:12 ` Lou Parisi
` (9 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Brian Beardall @ 2006-06-18 22:18 UTC (permalink / raw)
To: lm-sensors
On Sun, 2006-06-18 at 21:58 +0200, Jean Delvare wrote:
> Hi Brian,
>
> Quoting myself:
> > > Please stop dropping Lou from the loop, he is certainly interested in
> > > your case and may not be subscribed to the mailing list.
>
> You did it once again... :(
Sorry about that, I'll CC lou now. Hey lou you might need to do the same
as I did, if you didn't get the message about the latest sensors-detect,
then I'll CC it to you.
> > My output from the latest sensors-detect:
> > # sensors-detect revision $Revision$ ($Date$)
>
> Argh, I hope we can educate trac/subversion to fill these fields on the
> fly :(
>
> > Next adapter: SMBus PIIX4 adapter at 0400
> > Do you want to scan it? (YES/no/selectively):
> > (...)
> > Client found at address 0x4c
> > (...)
> > Probing for `Fintek F75383S/M'... Success!
> > (confidence 7, driver `to-be-written')
>
> You have your answer, there is indeed a secondary chip on the
> motherboard. Unfortunately no driver exists for this chip yet. I've
> updated our NewDrivers page to mention that you would be interested in
> a driver.
>
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (9 preceding siblings ...)
2006-06-18 22:18 ` Brian Beardall
@ 2006-06-19 3:12 ` Lou Parisi
2006-06-19 4:49 ` Lou Parisi
` (8 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Lou Parisi @ 2006-06-19 3:12 UTC (permalink / raw)
To: lm-sensors
Jean,
Regarding the kernel version - I have a fresh install of CentOS 4 and have
updated all packages using yum. Lm_sensors is actually the first thing I am
trying to get running on this new box before I put it off into a closet.
The output from uname -r is below:
# uname -r
2.6.9-34.0.1.EL
The only other thing that is possible is I first had lm_sensors 2.8
installed from yum and then when I was having the problem with the cpu temps
removed using yum and then downloaded the source and compiled and installed.
Do you think there could be something left over from this? The version from
sensors shows 2.10
# sensors -v
sensors version 2.10.0 with libsensors version 2.10.0
The only other thing I can think of is I am running amd64 version of linux
which can sometimes cause some strange behaviors in applications.
I will try to load the ic2-nforce2 module and run sensors-detect as per your
instructions and post again.
Thanks again, Lou.
-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org]
Sent: Sunday, June 18, 2006 1:13 PM
To: Lou Parisi
Cc: LM Sensors
Subject: Re: [lm-sensors] CPU Temp on ECS NFORCE3-A939
Hi Lou,
> > > The bios reads 1.37V for coreV but lm_sensors reads 1.07 consistently.
> >
> > This can be explained easily. Your Athlon64 3000+ must have the
> > so-called "Cool'n'Quiet" feature, which lets it adjust voltage and
> > frequency depending on load. I have a similar processor (Athlon64
> > 3200+, socket 939) those voltage ranges from 1.1V (idle) to 1.4V (full
> > load.) This seems to be roughly the same for you.
> >
> > You may try commenting out the following line in your configuration file
> > (in the it87-* section, of course):
> > # ignore vid
> > If the VID pins are properly wired on your system, this should report
> > the nominal voltage for your CPU and you should see it change depending
> > on the load.
> >
> > So it's really only a matter of setting the proper limits for that kind
> > of CPU. Try the following:
> >
> > set in0_min 1.1 * 0.95
> > set in0_max 1.4 * 1.05
>
> I set the alarm values based on the CPU VCore reported in
> the bios. Perhaps this is not correct, I'm not sure. I checked and my
> processor does have the Cool'n'Quiet technology.
I guess that either the Cool'n'Quiet is disabled when in the BIOS
screen, or the BIOS is in a tight loop waiting for a key to be pressed
and this keeps the CPU busy. Either way this means that the highest
voltage is used.
> I have had the ignore
VID
> uncommented but did not figure out how to use it in the sensors.conf. Did
a
> little more checking on the web and tried out a few more things. Tried to
> read vid as per the docs:
> # cat /sys/bus/i2c/devices/0-0290/in0_ref
> cat: /sys/bus/i2c/devices/0-0290/in0_ref: No such file or directory
The file would in fact be named cpu0_vid (it changed in 2.6.9.)
> Listing of /sys/bus/i2c/devices/0-0290:
> # ls /sys/bus/i2c/devices/0-0290
> alarms fan3_input in2_max in5_max name temp2_type
> detach_state fan3_min in2_min in5_min power temp3_input
> fan1_div in0_input in3_input in6_input temp1_input temp3_max
> fan1_input in0_max in3_max in6_max temp1_max temp3_min
> fan1_min in0_min in3_min in6_min temp1_min temp3_type
> fan2_div in1_input in4_input in7_input temp1_type
> fan2_input in1_max in4_max in7_max temp2_input
> fan2_min in1_min in4_min in7_min temp2_max
> fan3_div in2_input in5_input in8_input temp2_min
So it's not there, as if your chip was detected as an IT8705F instead
of an IT8712F. Are you certain you are running a 2.6.9 kernel? All
these hints suggest an older kernel.
> When I try to use vid in alarm setting in sensors.conf as below:
> set in0_min vid * 0.95
> set in0_max vid * 1.05
>
> # sensors
> it87-isa-0290
> Adapter: ISA adapter
> CPU VCore: +1.07 V (min = +0.00 V, max = +0.00 V) ALARM
Because there is no vid reading, the value of the "vid" symbol is 0.
Anyway you shouldn't use "vid" in compute lines in this case, because
its value changes, and you want to allow the full range your CPU is
allowed to use.
> > What about temp3?
>
> Temp3 gives consistently -7C when set to thermistor and consistent +94C
when
> set to diode. Perhaps temp3 is the correct one and just needs a
correction
> factor. I will try to get cpuburn running in the next few days and check
to
> see if temp3 changes and send a new reply.
No, it's most certainly not correct either.
> Full output of sensors-detect:
> # sensors-detect
> # sensors-detect revision 1.413 (2006/01/19 20:28:00)
> (...)
> 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): YES
> Probing for PCI bus adapters...
> Use driver `i2c-nforce2' for device 00:01.1: nVidia Corporation nForce3
> 250Gb SMBus (MCP)
> Probe succesfully concluded.
Support for this chip was only added in 2.6.11, and although
sensors-detect knows which driver should be used (i2c-nforce2), the
driver doesn't know it should support your chip. As a result, if there
are sensor chips on this bus cannot be accessed.
As I guess you don't really want to upgrade to a more recent kernel,
you should be able to add support for your chip at run time by doing the
following (as root):
$ modprobe i2c-nforce2
$ echo "10de 00e4" > /sys/bus/pci/drivers/nForce2_smbus/new_id
Then run sensors-detect again, and report the results.
> > In kernel 2.6.9 your chip is identified by the driver as "it87" (see
> > the first line of "sensors"), but in later kernels it is better
> > identified as "it8712". We put both in the configuration file so that
> > the same file works with all kernels.
I take that back, 2.6.9 is actually the first kernel which should name
the chip it8712. I'm really surprised it doesn't. Unless you're in fact
using a 2.6.8 kernel.
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (10 preceding siblings ...)
2006-06-19 3:12 ` Lou Parisi
@ 2006-06-19 4:49 ` Lou Parisi
2006-06-19 9:54 ` Jean Delvare
` (7 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Lou Parisi @ 2006-06-19 4:49 UTC (permalink / raw)
To: lm-sensors
Hi again Jean,
I ran the commands to load the ic2-nforce2 module as per your instructions
and then ran sensors-detects again.
Several new sensors were detected and the result of sensors-detect was put
into /etc/sysconfig/lm_sensors but no new sensors were found when I ran the
sensors command line. Output was the same as previous and behavior of
temperature values was unchanged.
I tried to look in the docs but is there something more I need to do for
these new sensors to be reported to output?
I copied a new sensors.conf from the source and edited the it87 section only
because I had heavily edited my previous sensors.conf and thought this may
be a reason why the new sensors were not output but this did not change
anything. The output from all that I tried is below:
---------------------------------------------------------------
# modprobe i2c-nforce2
# echo "10de 00e4" > /sys/bus/pci/drivers/nForce2_smbus/new_id
---------------------------------------------------------------
# sensors-detect
# sensors-detect revision 1.413 (2006/01/19 20:28:00)
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): YES
Probing for PCI bus adapters...
Use driver `i2c-nforce2' for device 00:01.1: nVidia Corporation nForce3
250Gb SMBus (MCP)
Probe succesfully concluded.
We will now try to load each adapter module in turn.
Module `i2c-nforce2' already loaded.
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 not loaded. Do you want to load it now? (YES/no): YES
Module loaded succesfully.
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 nForce2 adapter at 4c40
Do you want to scan it? (YES/no/selectively): YES
Client found at address 0x08
Client found at address 0x4c
Probing for `National Semiconductor LM75'... Failed!
Probing for `Dallas Semiconductor DS1621'... Failed!
Probing for `Analog Devices ADM1021'... Failed!
Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
Probing for `Maxim MAX1617'... Failed!
Probing for `Maxim MAX1617A'... Failed!
Probing for `TI THMC10'... Failed!
Probing for `National Semiconductor LM84'... Failed!
Probing for `Genesys Logic GL523SM'... Failed!
Probing for `Onsemi MC1066'... Failed!
Probing for `Maxim MAX1619'... Failed!
Probing for `National Semiconductor LM82/LM83'... Failed!
Probing for `National Semiconductor LM90'... Failed!
Probing for `National Semiconductor LM89/LM99'... Failed!
Probing for `National Semiconductor LM86'... Failed!
Probing for `Analog Devices ADM1032'... Failed!
Probing for `Maxim MAX6657/MAX6658/MAX6659'... Failed!
Probing for `National Semiconductor LM63'... Failed!
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Probing for `Analog Devices ADT7461'... Failed!
Next adapter: SMBus nForce2 adapter at 4c00
Do you want to scan it? (YES/no/selectively): YES
Client found at address 0x08
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')
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): YES
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 W83627EHF'
Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
Trying general detect... Failed!
Probing for `ITE IT8712F'
Trying address 0x0290... Success!
(confidence 8, driver `it87')
Probing for `ITE IT8705F / 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): YES
Probing for `ITE 8702F Super IO Sensors'
Failed! (0x8712)
Probing for `ITE 8705F Super IO Sensors'
Failed! (0x8712)
Probing for `ITE 8712F Super IO Sensors'
Success... found at address 0x0290
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)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Do you want to scan for secondary Super I/O sensors? (YES/no): YES
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)
Probing for `Winbond W83627EHF/EHG 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 nForce2 adapter at 4c00'
Busdriver `i2c-nforce2', I2C address 0x50
Chip `SPD EEPROM' (confidence: 8)
* Bus `SMBus nForce2 adapter at 4c00'
Busdriver `i2c-nforce2', I2C address 0x51
Chip `SPD EEPROM' (confidence: 8)
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus address 0x0290 (Busdriver `i2c-isa')
Chip `ITE 8712F Super IO Sensors' (confidence: 9)
I will now generate the commands needed to load the I2C modules.
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* file:
#----cut here----
# I2C adapter drivers
modprobe i2c-nforce2
modprobe i2c-isa
# I2C chip drivers
modprobe eeprom
modprobe it87
# 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): YES
Copy prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors
for initialization at boot time.
------------------------------------------------------------
cat /etc/sysconfig/lm_sensors
# Generated by sensors-detect on Sun Jun 18 22:23:50 2006
MODULE_0=i2c-nforce2
MODULE_1=i2c-isa
MODULE_2îprom
MODULE_3=it87
------------------------------------------------------------
# cat /etc/modprobe.conf
alias eth0 forcedeth
alias scsi_hostadapter sata_nv
alias snd-card-0 snd-intel8x0
options snd-card-0 index=0
install snd-intel8x0 /sbin/modprobe --ignore-install snd-intel8x0 &&
/usr/sbin/alsactl restore >/dev/null 2>&1 || :
remove snd-intel8x0 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-intel8x0
alias usb-controller ehci-hcd
alias usb-controller1 ohci-hcd
alias char-major-89 i2c-dev
-------------------------------------------------------------
note: copied new sensors.conf from source and adjusted it87 device config as
per previous experience and emails
# service lm_sensors start
Starting lm_sensors: loading module i2c-nforce2 i2c-isa eep[ OK ]
# lsmod
Module Size Used by
it87 28393 0
eeprom 10465 0
i2c_sensor 4161 2 it87,eeprom
i2c_isa 2881 0
i2c_dev 14145 0
i2c_nforce2 7745 0
i2c_core 27841 6
it87,eeprom,i2c_sensor,i2c_isa,i2c_dev,i2c_nforce2
# sensors -s
# sensors
it87-isa-0290
Adapter: ISA adapter
CPU Vcore: +1.07 V (min = +1.04 V, max = +1.47 V)
+1.5V: +1.47 V (min = +1.42 V, max = +1.57 V)
+3.3V: +3.31 V (min = +3.14 V, max = +3.47 V)
+5V: +4.89 V (min = +4.76 V, max = +5.24 V)
+12V: +11.71 V (min = +11.39 V, max = +12.61 V)
-12V: -12.11 V (min = -12.60 V, max = -11.37 V)
-5V: -4.80 V (min = -5.25 V, max = -4.75 V)
Stdby: +5.03 V (min = +4.76 V, max = +5.24 V)
VBat: +2.94 V
CPU Fan: 3183 RPM (min = 2812 RPM, div = 8)
Sys Fan: 981 RPM (min = 664 RPM, div = 8)
M/B Temp: +36??C (low = +15??C, high = +40??C) sensor thermistor
CPU Temp: +30??C (low = +15??C, high = +45??C) sensor thermistor
Temp3: -7??C (low = +15??C, high = +45??C) sensor thermistor
---------------------------------------------------------
# pwd
/sys/bus/pci/drivers/nForce2_smbus
# ls -ltra
total 0
drwxr-xr-x 35 root root 0 Jun 18 22:18 ..
--w------- 1 root root 0 Jun 18 22:18 new_id
lrwxrwxrwx 1 root root 0 Jun 18 22:19 0000:00:01.1 ->
../../../../devices/pci0000:00/0000:00:01.1
drwxr-xr-x 2 root root 0 Jun 18 22:19 .
---------------------------------------------------------
# pwd
/sys/devices/pci0000:00/0000:00:01.1
# ls -R
.:
class detach_state i2c-1 irq resource subsystem_vendor
config device i2c-2 power subsystem_device vendor
./i2c-1:
1-0050 1-0051 detach_state name power
./i2c-1/1-0050:
detach_state eeprom name power
./i2c-1/1-0050/power:
state
./i2c-1/1-0051:
detach_state eeprom name power
./i2c-1/1-0051/power:
state
./i2c-1/power:
state
./i2c-2:
detach_state name power
./i2c-2/power:
state
./power:
state
-----------------------------------------------------------------
# lspci -v
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management (rev
a1)
Subsystem: Elitegroup Computer Systems: Unknown device 1b53
Flags: 66Mhz, fast devsel, IRQ 177
I/O ports at ff00 [size2]
I/O ports at 4c00 [sized]
I/O ports at 4c40 [sized]
Capabilities: [44] Power Management version 2
-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org]
Sent: Sunday, June 18, 2006 1:13 PM
To: Lou Parisi
Cc: LM Sensors
Subject: Re: [lm-sensors] CPU Temp on ECS NFORCE3-A939
Hi Lou,
> > > The bios reads 1.37V for coreV but lm_sensors reads 1.07 consistently.
> >
> > This can be explained easily. Your Athlon64 3000+ must have the
> > so-called "Cool'n'Quiet" feature, which lets it adjust voltage and
> > frequency depending on load. I have a similar processor (Athlon64
> > 3200+, socket 939) those voltage ranges from 1.1V (idle) to 1.4V (full
> > load.) This seems to be roughly the same for you.
> >
> > You may try commenting out the following line in your configuration file
> > (in the it87-* section, of course):
> > # ignore vid
> > If the VID pins are properly wired on your system, this should report
> > the nominal voltage for your CPU and you should see it change depending
> > on the load.
> >
> > So it's really only a matter of setting the proper limits for that kind
> > of CPU. Try the following:
> >
> > set in0_min 1.1 * 0.95
> > set in0_max 1.4 * 1.05
>
> I set the alarm values based on the CPU VCore reported in
> the bios. Perhaps this is not correct, I'm not sure. I checked and my
> processor does have the Cool'n'Quiet technology.
I guess that either the Cool'n'Quiet is disabled when in the BIOS
screen, or the BIOS is in a tight loop waiting for a key to be pressed
and this keeps the CPU busy. Either way this means that the highest
voltage is used.
> I have had the ignore
VID
> uncommented but did not figure out how to use it in the sensors.conf. Did
a
> little more checking on the web and tried out a few more things. Tried to
> read vid as per the docs:
> # cat /sys/bus/i2c/devices/0-0290/in0_ref
> cat: /sys/bus/i2c/devices/0-0290/in0_ref: No such file or directory
The file would in fact be named cpu0_vid (it changed in 2.6.9.)
> Listing of /sys/bus/i2c/devices/0-0290:
> # ls /sys/bus/i2c/devices/0-0290
> alarms fan3_input in2_max in5_max name temp2_type
> detach_state fan3_min in2_min in5_min power temp3_input
> fan1_div in0_input in3_input in6_input temp1_input temp3_max
> fan1_input in0_max in3_max in6_max temp1_max temp3_min
> fan1_min in0_min in3_min in6_min temp1_min temp3_type
> fan2_div in1_input in4_input in7_input temp1_type
> fan2_input in1_max in4_max in7_max temp2_input
> fan2_min in1_min in4_min in7_min temp2_max
> fan3_div in2_input in5_input in8_input temp2_min
So it's not there, as if your chip was detected as an IT8705F instead
of an IT8712F. Are you certain you are running a 2.6.9 kernel? All
these hints suggest an older kernel.
> When I try to use vid in alarm setting in sensors.conf as below:
> set in0_min vid * 0.95
> set in0_max vid * 1.05
>
> # sensors
> it87-isa-0290
> Adapter: ISA adapter
> CPU VCore: +1.07 V (min = +0.00 V, max = +0.00 V) ALARM
Because there is no vid reading, the value of the "vid" symbol is 0.
Anyway you shouldn't use "vid" in compute lines in this case, because
its value changes, and you want to allow the full range your CPU is
allowed to use.
> > What about temp3?
>
> Temp3 gives consistently -7C when set to thermistor and consistent +94C
when
> set to diode. Perhaps temp3 is the correct one and just needs a
correction
> factor. I will try to get cpuburn running in the next few days and check
to
> see if temp3 changes and send a new reply.
No, it's most certainly not correct either.
> Full output of sensors-detect:
> # sensors-detect
> # sensors-detect revision 1.413 (2006/01/19 20:28:00)
> (...)
> 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): YES
> Probing for PCI bus adapters...
> Use driver `i2c-nforce2' for device 00:01.1: nVidia Corporation nForce3
> 250Gb SMBus (MCP)
> Probe succesfully concluded.
Support for this chip was only added in 2.6.11, and although
sensors-detect knows which driver should be used (i2c-nforce2), the
driver doesn't know it should support your chip. As a result, if there
are sensor chips on this bus cannot be accessed.
As I guess you don't really want to upgrade to a more recent kernel,
you should be able to add support for your chip at run time by doing the
following (as root):
$ modprobe i2c-nforce2
$ echo "10de 00e4" > /sys/bus/pci/drivers/nForce2_smbus/new_id
Then run sensors-detect again, and report the results.
> > In kernel 2.6.9 your chip is identified by the driver as "it87" (see
> > the first line of "sensors"), but in later kernels it is better
> > identified as "it8712". We put both in the configuration file so that
> > the same file works with all kernels.
I take that back, 2.6.9 is actually the first kernel which should name
the chip it8712. I'm really surprised it doesn't. Unless you're in fact
using a 2.6.8 kernel.
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (11 preceding siblings ...)
2006-06-19 4:49 ` Lou Parisi
@ 2006-06-19 9:54 ` Jean Delvare
2006-06-19 10:01 ` Jean Delvare
` (6 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Jean Delvare @ 2006-06-19 9:54 UTC (permalink / raw)
To: lm-sensors
Lou,
> Regarding the kernel version - I have a fresh install of CentOS 4 and have
> updated all packages using yum. Lm_sensors is actually the first thing I am
> trying to get running on this new box before I put it off into a closet.
> The output from uname -r is below:
> # uname -r
> 2.6.9-34.0.1.EL
>
> The only other thing that is possible is I first had lm_sensors 2.8
> installed from yum and then when I was having the problem with the cpu temps
> removed using yum and then downloaded the source and compiled and installed.
>
> Do you think there could be something left over from this? The version from
> sensors shows 2.10
> # sensors -v
> sensors version 2.10.0 with libsensors version 2.10.0
No, for Linux 2.6 kernels, the lm_sensors package only brings the user
space support, so it can't explain the observed inconsistencies on the
kernel front. It seems that you have an older version of the it87
driver than your kernel version suggests. I can't explain it, we would
need to know how exactly CentOS built their kernel.
Anyway, it doesn't matter that much, you can live without vid readings
- we aren't even sure if your boards support that.
> The only other thing I can think of is I am running amd64 version of linux
> which can sometimes cause some strange behaviors in applications.
It can't explain the observed inconsistencies either, and I doubt it
will cause any kind of problem on the lm_sensors side in general.
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (12 preceding siblings ...)
2006-06-19 9:54 ` Jean Delvare
@ 2006-06-19 10:01 ` Jean Delvare
2006-06-20 0:13 ` Lou Parisi
` (5 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Jean Delvare @ 2006-06-19 10:01 UTC (permalink / raw)
To: lm-sensors
Lou,
> I ran the commands to load the ic2-nforce2 module as per your instructions
> and then ran sensors-detects again.
>
> Several new sensors were detected and the result of sensors-detect was put
> into /etc/sysconfig/lm_sensors but no new sensors were found when I ran the
> sensors command line. Output was the same as previous and behavior of
> temperature values was unchanged.
> Next adapter: SMBus nForce2 adapter at 4c40
Good news is that the "new_id" trick worked. Note that it needs to be
done every time you load the i2c-nforce2 driver, so in particular it
won't survive a reboot unless you add the commands in a boot script.
> Do you want to scan it? (YES/no/selectively): YES
> Client found at address 0x08
> Client found at address 0x4c
> Probing for `National Semiconductor LM75'... Failed!
> Probing for `Dallas Semiconductor DS1621'... Failed!
> Probing for `Analog Devices ADM1021'... Failed!
> Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
> Probing for `Maxim MAX1617'... Failed!
> Probing for `Maxim MAX1617A'... Failed!
> Probing for `TI THMC10'... Failed!
> Probing for `National Semiconductor LM84'... Failed!
> Probing for `Genesys Logic GL523SM'... Failed!
> Probing for `Onsemi MC1066'... Failed!
> Probing for `Maxim MAX1619'... Failed!
> Probing for `National Semiconductor LM82/LM83'... Failed!
> Probing for `National Semiconductor LM90'... Failed!
> Probing for `National Semiconductor LM89/LM99'... Failed!
> Probing for `National Semiconductor LM86'... Failed!
> Probing for `Analog Devices ADM1032'... Failed!
> Probing for `Maxim MAX6657/MAX6658/MAX6659'... Failed!
> Probing for `National Semiconductor LM63'... Failed!
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
> Probing for `Analog Devices ADT7461'... Failed!
These were probed, but NOT detected. You have a chip here but your
version of sensors-detect doesn't know what it is. Please try the
latest version of sensors-detect, as Brian did:
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt
I wouldn't be surprised if you have the same chip as Brian.
> I tried to look in the docs but is there something more I need to do for
> these new sensors to be reported to output?
The only new chips which were detected here are SPD EEPROMs, you can
get information from them using the decode-dimms.pl script. These are
not sensors so they won't show in "sensors".
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (13 preceding siblings ...)
2006-06-19 10:01 ` Jean Delvare
@ 2006-06-20 0:13 ` Lou Parisi
2006-06-20 12:52 ` Jean Delvare
` (4 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Lou Parisi @ 2006-06-20 0:13 UTC (permalink / raw)
To: lm-sensors
Jean,
>These were probed, but NOT detected. You have a chip here but your
>version of sensors-detect doesn't know what it is. Please try the
>latest version of sensors-detect, as Brian did:
>http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors->det
ect?format=txt
>I wouldn't be surprised if you have the same chip as Brian.
I ran the new sensors-detect and the chip detected was the same as Brian's.
Can you please add my name also to the list of those interested in this
driver. The output from the latest sensors-detect is at the bottom of this
page.
Thank you for all of your help. Lou
By the way, I heard back from ECS. Their response:
----------ECS Response ----------
Dear Valued Customer:
If a monitoring software is being used and is failing to collect data for
the CPU temprature, the software is incompatible and no monitoring software
is available for the board since Hardware Monitor was already integrated in
the BIOS.
Thank you for using ECS products
---------------------------------
----- sensors-detect output -----
# ./sensors-detect
# sensors-detect revision $Revision$ ($Date$)
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): YES
Probing for PCI bus adapters...
Use driver `i2c-nforce2' for device 00:01.1: nVidia Corporation nForce3
250Gb SMBus (MCP)
Probe succesfully concluded.
We will now try to load each adapter module in turn.
Module `i2c-nforce2' already loaded.
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 nForce2 adapter at 4c40
Do you want to scan it? (YES/no/selectively): YES
Client found at address 0x08
Client found at address 0x4c
Probing for `National Semiconductor LM75'... Failed!
Probing for `Dallas Semiconductor DS1621'... Failed!
Probing for `Analog Devices ADM1021'... Failed!
Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
Probing for `Maxim MAX1617'... Failed!
Probing for `Maxim MAX1617A'... Failed!
Probing for `TI THMC10'... Failed!
Probing for `National Semiconductor LM84'... Failed!
Probing for `Genesys Logic GL523SM'... Failed!
Probing for `Onsemi MC1066'... Failed!
Probing for `Maxim MAX1619'... Failed!
Probing for `National Semiconductor LM82/LM83'... Failed!
Probing for `National Semiconductor LM90'... Failed!
Probing for `National Semiconductor LM89/LM99'... Failed!
Probing for `National Semiconductor LM86'... Failed!
Probing for `Analog Devices ADM1032'... Failed!
Probing for `Maxim MAX6657/MAX6658/MAX6659'... Failed!
Probing for `National Semiconductor LM63'... Failed!
Probing for `Fintek F75363SG'... Failed!
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Probing for `Analog Devices ADT7461'... Failed!
Probing for `Fintek F75383S/M'... Success!
(confidence 7, driver `to-be-written')
Next adapter: SMBus nForce2 adapter at 4c00
Do you want to scan it? (YES/no/selectively): YES
Client found at address 0x08
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')
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): YES
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 W83627EHF'
Trying address 0x0290... Failed!
Probing for `Winbond W83627DHG'
Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
Trying general detect... Failed!
Probing for `ITE IT8712F'
Trying address 0x0290... Success!
(confidence 8, driver `it87')
Probing for `ITE IT8705F / 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): YES
Probing for `ITE 8702F Super IO Sensors'
Failed! (0x8712)
Probing for `ITE 8705F Super IO Sensors'
Failed! (0x8712)
Probing for `ITE 8712F Super IO Sensors'
Success... found at address 0x0290
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)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Do you want to scan for secondary Super I/O sensors? (YES/no): YES
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)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
Failed! (skipping family)
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `to-be-written' (should be inserted):
Detects correctly:
* Bus `SMBus nForce2 adapter at 4c40'
Busdriver `i2c-nforce2', I2C address 0x4c
Chip `Fintek F75383S/M' (confidence: 7)
Driver `eeprom' (should be inserted):
Detects correctly:
* Bus `SMBus nForce2 adapter at 4c00'
Busdriver `i2c-nforce2', I2C address 0x50
Chip `SPD EEPROM' (confidence: 8)
* Bus `SMBus nForce2 adapter at 4c00'
Busdriver `i2c-nforce2', I2C address 0x51
Chip `SPD EEPROM' (confidence: 8)
Driver `it87' (should be inserted):
Detects correctly:
* ISA bus address 0x0290 (Busdriver `i2c-isa')
Chip `ITE 8712F Super IO Sensors' (confidence: 9)
I will now generate the commands needed to load the I2C modules.
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* file:
#----cut here----
# I2C adapter drivers
modprobe i2c-nforce2
modprobe i2c-isa
# I2C chip drivers
# no driver for Fintek F75383S/M yet
modprobe eeprom
modprobe it87
# 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): no
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (14 preceding siblings ...)
2006-06-20 0:13 ` Lou Parisi
@ 2006-06-20 12:52 ` Jean Delvare
2006-06-25 2:26 ` Brian Beardall
` (3 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Jean Delvare @ 2006-06-20 12:52 UTC (permalink / raw)
To: lm-sensors
Hi Lou,
> > I wouldn't be surprised if you have the same chip as Brian.
>
> I ran the new sensors-detect and the chip detected was the same as Brian's.
> Can you please add my name also to the list of those interested in this
> driver. The output from the latest sensors-detect is at the bottom of this
> page.
I've done so.
> Thank you for all of your help. Lou
You're welcome :) Now the hard part would be to write, review and test
a driver for that chip - but I just don't have the time to do that,
unfortunately.
> By the way, I heard back from ECS. Their response:
> ----------ECS Response ----------
> Dear Valued Customer:
>
> If a monitoring software is being used and is failing to collect data for
> the CPU temprature, the software is incompatible and no monitoring software
> is available for the board since Hardware Monitor was already integrated in
> the BIOS.
>
> Thank you for using ECS products
> ---------------------------------
Well, at least they answered, but that wasn't really useful. Good thing
that we found the answer by ourselves meanwhile!
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (15 preceding siblings ...)
2006-06-20 12:52 ` Jean Delvare
@ 2006-06-25 2:26 ` Brian Beardall
2006-06-26 20:39 ` Jean Delvare
` (2 subsequent siblings)
19 siblings, 0 replies; 21+ messages in thread
From: Brian Beardall @ 2006-06-25 2:26 UTC (permalink / raw)
To: lm-sensors
On Tue, 2006-06-20 at 14:52 +0200, Jean Delvare wrote:
> Hi Lou,
>
> > > I wouldn't be surprised if you have the same chip as Brian.
> >
> > I ran the new sensors-detect and the chip detected was the same as Brian's.
> > Can you please add my name also to the list of those interested in this
> > driver. The output from the latest sensors-detect is at the bottom of this
> > page.
>
> I've done so.
>
> > Thank you for all of your help. Lou
>
> You're welcome :) Now the hard part would be to write, review and test
> a driver for that chip - but I just don't have the time to do that,
> unfortunately.
I've been working on a driver for the chip, but I can't get it to
interface with sensors. I have it reading from the registers correctly,
and I used a printk statement to make sure that the driver was reading,
and storing the values correctly, but when I run sensors it doesn't
print out anything. I based the code off of your lm63 driver. The driver
does initialize, and detect. Would you like to look at it, and how woule
you like me to send it? I have a couple things to fix with temperature
calculation, hyst, and min, and max, but I first want to get it to talk
to userland software.
>
> > By the way, I heard back from ECS. Their response:
> > ----------ECS Response ----------
> > Dear Valued Customer:
> >
> > If a monitoring software is being used and is failing to collect data for
> > the CPU temprature, the software is incompatible and no monitoring software
> > is available for the board since Hardware Monitor was already integrated in
> > the BIOS.
> >
> > Thank you for using ECS products
> > ---------------------------------
>
> Well, at least they answered, but that wasn't really useful. Good thing
> that we found the answer by ourselves meanwhile!
>
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (16 preceding siblings ...)
2006-06-25 2:26 ` Brian Beardall
@ 2006-06-26 20:39 ` Jean Delvare
2006-06-27 0:08 ` Brian Beardall
2006-07-03 7:07 ` Lou Parisi
19 siblings, 0 replies; 21+ messages in thread
From: Jean Delvare @ 2006-06-26 20:39 UTC (permalink / raw)
To: lm-sensors
Hi Brian,
> I've been working on a driver for the chip, but I can't get it to
> interface with sensors. I have it reading from the registers correctly,
> and I used a printk statement to make sure that the driver was reading,
> and storing the values correctly, but when I run sensors it doesn't
> print out anything. I based the code off of your lm63 driver. The driver
> does initialize, and detect. Would you like to look at it, and how woule
> you like me to send it? I have a couple things to fix with temperature
> calculation, hyst, and min, and max, but I first want to get it to talk
> to userland software.
If you want "sensors" to display anything for your chip, you must add
support for it to libsensors, and to sensors itself. You must also make
sure that you register your driver with the hwmon class.
You are welcome to post your code on this list, as a -p1 patch against
either Linus' or Andrew's tree. You can post the patch either inline
(if your mailer can do this properly) or as an attchement (type
text/plain) so that we can comment on it and help you.
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (17 preceding siblings ...)
2006-06-26 20:39 ` Jean Delvare
@ 2006-06-27 0:08 ` Brian Beardall
2006-07-03 7:07 ` Lou Parisi
19 siblings, 0 replies; 21+ messages in thread
From: Brian Beardall @ 2006-06-27 0:08 UTC (permalink / raw)
To: lm-sensors
On Mon, 2006-06-26 at 22:39 +0200, Jean Delvare wrote:
> Hi Brian,
>
> > I've been working on a driver for the chip, but I can't get it to
> > interface with sensors. I have it reading from the registers correctly,
> > and I used a printk statement to make sure that the driver was reading,
> > and storing the values correctly, but when I run sensors it doesn't
> > print out anything. I based the code off of your lm63 driver. The driver
> > does initialize, and detect. Would you like to look at it, and how woule
> > you like me to send it? I have a couple things to fix with temperature
> > calculation, hyst, and min, and max, but I first want to get it to talk
> > to userland software.
>
> If you want "sensors" to display anything for your chip, you must add
> support for it to libsensors, and to sensors itself. You must also make
> sure that you register your driver with the hwmon class.
>
> You are welcome to post your code on this list, as a -p1 patch against
> either Linus' or Andrew's tree. You can post the patch either inline
> (if your mailer can do this properly) or as an attchement (type
> text/plain) so that we can comment on it and help you.
>
My patch. I've tested the driver on my own mainboard, and everything
seems to work by what I read from the datasheet.
--- /dev/null 2000-10-22 01:01:00.000000000 -0600
+++ linux-2.6.17-gentoo/drivers/hwmon/f75383.c 2006-06-26
17:52:23.000000000 -0600
@@ -0,0 +1,578 @@
+/*
+ * f75383.c - driver for the Fintek F75383/F75384 temperature sensor
+ *
+ * Copyright (C) 2004-2006 Jean Delvare <khali at linux-fr.org>
+ * Brian Beardall <brian at rapsure.net>
+ * Based on the lm90 and lm63 driver.
+ *
+ * The F75383 is a sensor chip made by Fintek. It measures
+ * two temperatures (its own and one external one). Complete datasheet
can be
+ * obtained from Fintek's website at:
+ * http://www.fintek.com.tw/files/productfiles/F75383_384_V030P.pdf
+ *
+ * The F75383 is a temperature sensors with one remote, and one local
sensor.
+ * the sensors behave the same.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/jiffies.h>
+#include <linux/i2c.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/hwmon.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+
+/*
+ * Addresses to scan
+ * Address is fully defined internally and cannot be changed.
+ */
+
+static unsigned short normal_i2c[] = { 0x4c, I2C_CLIENT_END };
+
+/*
+ * Insmod parameters
+ */
+
+I2C_CLIENT_INSMOD_1(f75383);
+
+/*
+ * The F75383 registers
+ */
+
+
+#define F75383_REG_CONFIG_READ 0x03
+#define F75383_REG_CONFIG_WRITE 0x09
+#define F75383_STATUS 0x02
+#define F75383_CONV_RATE 0x08
+#define F75383_ONE_SHOT 0x0F
+#define F75383_ALERT_TIMEOUT 0x22
+#define F75383_STATUS_ARA 0x24
+
+#define F75383_CHIP_ID1 0x5A /* Read to know that the driver is for
it */
+#define F75383_CHIP_ID2 0x5B
+
+#define F75383_VENDOR_ID1_LOC1 0x5D
+#define F75383_VENDOR_ID1_LOC2 0x5E
+#define F75383_VENDOR_ID2 0xFE /* might be different */
+/* #define F75383_VALUE_RAM 0x10 - 0x2F */
+#define F75383_VT1_HIGH 0x00
+#define F75383_VT1_LOW 0x1A
+#define F75383_VT2_HIGH 0x01
+#define F75383_VT2_LOW 0x10
+#define F75383_VT1_HIGH_LIMIT_HIGH_READ 0x05
+#define F75383_VT1_HIGH_LIMIT_LOW_BYTE 0x1B
+#define F75383_VT1_HIGH_LIMIT_HIGH_WRITE 0x0B
+#define F75383_VT1_LOW_LIMIT_HIGH_READ 0x06
+#define F75383_VT1_LOW_LIMIT_LOW_BYTE 0x1C
+#define F75383_VT1_LOW_LIMIT_HIGH_WRITE 0x0C
+#define F75383_VT2_HIGH_LIMIT_HIGH_READ 0x07
+#define F75383_VT2_HIGH_LIMIT_LOW_BYTE 0x13
+#define F75383_VT2_HIGH_LIMIT_HIGH_WRITE 0x0D
+#define F75383_VT2_LOW_LIMIT_HIGH_READ 0x08
+#define F75383_VT2_LOW_LIMIT_LOW_BYTE 0x14
+#define F75383_VT2_LOW_LIMIT_HIGH_WRITE 0x0E
+#define F75383_VT1_THERM_LIMIT 0x20
+#define F75383_VT1_THERM_HYST 0x21
+#define F75383_VT2_THERM_LIMIT 0x19
+#define F75383_VT2_THERM_HYST 0x23
+
+
+/* For the F75383 Both temperature sensors are read the same. VT1 is
local,
+ * and VT2 is external, and on ECS mainboards is
+ * connected to the CPU for the temperature. There is no FAN circutry,
and there
+ * is only one method for calculating the temperatures. The High Byte
is just a value
+ * from 0 - 144 degrees C. For each increase in the number there is a
corresponding change in
+ * the temperature. The Low Byte uses the upper nibble for
+ *temperature changes of .125 degrees C.
+ */
+
+#define TEMP_FROM_REG(reg) ((reg) / 32 * 125)
+#define TEMP_TO_REG(val) ((val) <= 0 ? 0x0000 : \
+ (val) >= 140875 ? 0x8CE0 : \
+ (val) / 125 * 32)
+#define HYST_FROM_REG(reg) ((reg) * 1000)
+#define HYST_TO_REG(val) ((val) <= 0 ? 0 : \
+ (val) >= 140000 ? 140 : \
+ (val) / 1000)
+
+/*
+ * Functions declaration
+ */
+
+static int f75383_attach_adapter(struct i2c_adapter *adapter);
+static int f75383_detach_client(struct i2c_client *client);
+
+static struct f75383_data *f75383_update_device(struct device *dev);
+
+static int f75383_detect(struct i2c_adapter *adapter, int address, int
kind);
+static void f75383_init_client(struct i2c_client *client);
+
+/*
+ * Driver data (common to all clients)
+ */
+
+static struct i2c_driver f75383_driver = {
+ .driver = {
+ .name = "F75383",
+ },
+ .attach_adapter = f75383_attach_adapter,
+ .detach_client = f75383_detach_client,
+};
+
+/*
+ * Client data (each client gets its own)
+ */
+
+struct f75383_data {
+ struct i2c_client client;
+ struct class_device *class_dev;
+ struct mutex update_lock;
+ char valid; /* zero until following fields are valid */
+ unsigned long last_updated; /* in jiffies */
+
+ /* registers values */
+ u8 config;
+
+ u16 temp1[3]; /* 0: VT1 input
+ 1: VT1 low limit
+ 2: VT1 high limit */
+ u16 temp2[3]; /*
+ 0: VT2 input
+ 1: VT2 low limit
+ 2: VT2 high limit */
+ u8 temp1_crit_hyst;
+ u8 temp2_crit_hyst;
+ u8 temp1_crit;
+ u8 temp2_crit;
+ u8 alarms;
+};
+
+/*
+ * Sysfs callback functions and files
+ */
+
+
+static ssize_t show_temp1(struct device *dev, struct device_attribute
*devattr,
+ char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct f75383_data *data = f75383_update_device(dev);
+ return sprintf(buf, "%d\n", TEMP_FROM_REG(data->temp1[attr->index]));
+}
+
+static ssize_t show_temp2(struct device *dev, struct device_attribute
*devattr,
+ char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct f75383_data *data = f75383_update_device(dev);
+ return sprintf(buf, "%d\n", TEMP_FROM_REG(data->temp2[attr->index]));
+}
+
+static ssize_t set_temp1(struct device *dev, struct device_attribute
*devattr,
+ const char *buf, size_t count)
+{
+ static const u8 reg[4]= {
+ F75383_VT1_LOW_LIMIT_HIGH_WRITE,
+ F75383_VT1_LOW_LIMIT_LOW_BYTE,
+ F75383_VT1_HIGH_LIMIT_HIGH_WRITE,
+ F75383_VT1_HIGH_LIMIT_LOW_BYTE,
+ };
+
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct f75383_data *data = i2c_get_clientdata(client);
+ long val = simple_strtol(buf, NULL, 10);
+ int nr = attr->index;
+
+ mutex_lock(&data->update_lock);
+ data->temp1[nr] = TEMP_TO_REG(val);
+ i2c_smbus_write_byte_data(client, reg[(nr - 1) * 2],
+ data->temp1[nr] >> 8);
+ i2c_smbus_write_byte_data(client, reg[(nr - 1) * 2 + 1],
+ data->temp1[nr] & 0xff);
+ mutex_unlock(&data->update_lock);
+ return count;
+}
+
+static ssize_t set_temp2(struct device *dev, struct device_attribute
*devattr,
+ const char *buf, size_t count)
+{
+ static const u8 reg[4]= {
+ F75383_VT2_LOW_LIMIT_HIGH_WRITE,
+ F75383_VT2_LOW_LIMIT_LOW_BYTE,
+ F75383_VT2_HIGH_LIMIT_HIGH_WRITE,
+ F75383_VT2_HIGH_LIMIT_LOW_BYTE,
+ };
+
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct i2c_client *client = to_i2c_client(dev);
+ struct f75383_data *data = i2c_get_clientdata(client);
+ long val = simple_strtol(buf, NULL, 10);
+ int nr = attr->index;
+
+ mutex_lock(&data->update_lock);
+ data->temp2[nr] = TEMP_TO_REG(val);
+ i2c_smbus_write_byte_data(client, reg[(nr - 1) * 2],
+ data->temp2[nr] >> 8);
+ i2c_smbus_write_byte_data(client, reg[(nr - 1) * 2 + 1],
+ data->temp2[nr] & 0xff);
+ mutex_unlock(&data->update_lock);
+ return count;
+}
+
+/* Show the THERM limit temperature. This is an eight bit value */
+
+static ssize_t show_temp1_crit(struct device *dev, struct
device_attribute *dummy,
+ char *buf)
+{
+ struct f75383_data *data = f75383_update_device(dev);
+ return sprintf(buf, "%d\n", HYST_FROM_REG(data->temp1_crit));
+}
+
+static ssize_t show_temp2_crit(struct device *dev, struct
device_attribute *dummy,
+ char *buf)
+{
+ struct f75383_data *data = f75383_update_device(dev);
+ return sprintf(buf, "%d\n", HYST_FROM_REG(data->temp2_crit));
+}
+
+
+/* Set the THERM limit, I named the functions with crit because of the
function
+ * in libsensors
+ */
+static ssize_t set_temp1_crit(struct device *dev, struct
device_attribute *dummy,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct f75383_data *data = i2c_get_clientdata(client);
+ long crit = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(&data->update_lock);
+ i2c_smbus_write_byte_data(client, F75383_VT1_THERM_LIMIT,
+ HYST_TO_REG(crit));
+ mutex_unlock(&data->update_lock);
+ return count;
+}
+
+static ssize_t set_temp2_crit(struct device *dev, struct
device_attribute *dummy,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct f75383_data *data = i2c_get_clientdata(client);
+ long crit = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(&data->update_lock);
+ i2c_smbus_write_byte_data(client, F75383_VT2_THERM_LIMIT,
+ HYST_TO_REG(crit));
+ mutex_unlock(&data->update_lock);
+ return count;
+}
+
+/* Hysteresis register holds a relative value, while we want to present
+ an absolute to user-space */
+static ssize_t show_temp1_crit_hyst(struct device *dev, struct
device_attribute *dummy,
+ char *buf)
+{
+ struct f75383_data *data = f75383_update_device(dev);
+ return sprintf(buf, "%d\n", HYST_FROM_REG(data->temp1_crit_hyst));
+}
+
+static ssize_t show_temp2_crit_hyst(struct device *dev, struct
device_attribute *dummy,
+ char *buf)
+{
+ struct f75383_data *data = f75383_update_device(dev);
+ return sprintf(buf, "%d\n", HYST_FROM_REG(data->temp2_crit_hyst));
+}
+
+/* And now the other way around, user-space provides an absolute
+ hysteresis value and we have to store a relative one */
+static ssize_t set_temp1_crit_hyst(struct device *dev, struct
device_attribute *dummy,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct f75383_data *data = i2c_get_clientdata(client);
+ long hyst = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(&data->update_lock);
+ i2c_smbus_write_byte_data(client, F75383_VT1_THERM_HYST,
+ HYST_TO_REG(hyst));
+ mutex_unlock(&data->update_lock);
+ return count;
+}
+
+static ssize_t set_temp2_crit_hyst(struct device *dev, struct
device_attribute *dummy,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct f75383_data *data = i2c_get_clientdata(client);
+ long hyst = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(&data->update_lock);
+ i2c_smbus_write_byte_data(client, F75383_VT2_THERM_HYST,
+ HYST_TO_REG(hyst));
+ mutex_unlock(&data->update_lock);
+ return count;
+}
+
+static ssize_t show_alarms(struct device *dev, struct device_attribute
*dummy,
+ char *buf)
+{
+ struct f75383_data *data = f75383_update_device(dev);
+ return sprintf(buf, "%u\n", data->alarms);
+}
+
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp1, NULL, 0);
+static SENSOR_DEVICE_ATTR(temp1_min, S_IWUSR | S_IRUGO, show_temp1,
+ set_temp1, 1);
+static SENSOR_DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO, show_temp1,
+ set_temp1, 2);
+static DEVICE_ATTR(temp1_crit, S_IWUSR | S_IRUGO, show_temp1_crit,
+ set_temp1_crit);
+static DEVICE_ATTR(temp1_crit_hyst, S_IWUSR | S_IRUGO,
show_temp1_crit_hyst,
+ set_temp1_crit_hyst);
+
+static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp2, NULL, 0);
+static SENSOR_DEVICE_ATTR(temp2_min, S_IWUSR | S_IRUGO, show_temp2,
+ set_temp2, 1);
+static SENSOR_DEVICE_ATTR(temp2_max, S_IWUSR | S_IRUGO, show_temp2,
+ set_temp2, 2);
+static DEVICE_ATTR(temp2_crit, S_IWUSR | S_IRUGO, show_temp2_crit,
+ set_temp2_crit);
+static DEVICE_ATTR(temp2_crit_hyst, S_IWUSR | S_IRUGO,
show_temp2_crit_hyst,
+ set_temp2_crit_hyst);
+
+static DEVICE_ATTR(alarms, S_IRUGO, show_alarms, NULL);
+
+/*
+ * Real code
+ */
+
+static int f75383_attach_adapter(struct i2c_adapter *adapter)
+{
+ if (!(adapter->class & I2C_CLASS_HWMON))
+ return 0;
+ return i2c_probe(adapter, &addr_data, f75383_detect);
+}
+
+/*
+ * The following function does more than just detection. If detection
+ * succeeds, it also registers the new chip.
+ */
+static int f75383_detect(struct i2c_adapter *adapter, int address, int
kind)
+{
+ struct i2c_client *new_client;
+ struct f75383_data *data;
+ int err = 0;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ goto exit;
+
+ if (!(data = kzalloc(sizeof(struct f75383_data), GFP_KERNEL))) {
+ err = -ENOMEM;
+ goto exit;
+ }
+
+ /* The common I2C client data is placed right before the
+ F75383-specific data. */
+ new_client = &data->client;
+ i2c_set_clientdata(new_client, data);
+ new_client->addr = address;
+ new_client->adapter = adapter;
+ new_client->driver = &f75383_driver;
+ new_client->flags = 0;
+
+ /* Default to an F75383 if forced */
+ if (kind = 0)
+ kind = f75383;
+
+ if (kind < 0) { /* must identify */
+ u8 chip_id1, chip_id2, vendor_id1_loc1, vendor_id1_loc2;
+
+ chip_id1 = i2c_smbus_read_byte_data(new_client,
+ F75383_CHIP_ID1);
+ chip_id2 = i2c_smbus_read_byte_data(new_client,
+ F75383_CHIP_ID2);
+ vendor_id1_loc1 = i2c_smbus_read_byte_data(new_client,
+ F75383_VENDOR_ID1_LOC1);
+ vendor_id1_loc2 = i2c_smbus_read_byte_data(new_client,
+ F75383_VENDOR_ID1_LOC2);
+
+ if (chip_id1 = 0x03 /* */
+ && chip_id2 = 0x03 /* */
+ && vendor_id1_loc1 = 0x19
+ && vendor_id1_loc2 = 0x34 ) {
+ kind = f75383;
+ } else { /* failed */
+ dev_dbg(&adapter->dev, "Unsupported chip "
+ "(chip_id1=0x%02X, chip_id2=0x%02X).\n",
+ chip_id1, chip_id2);
+ goto exit_free;
+ }
+ }
+
+ strlcpy(new_client->name, "f75383", I2C_NAME_SIZE);
+ data->valid = 0;
+ mutex_init(&data->update_lock);
+
+ /* Tell the I2C layer a new client has arrived */
+ if ((err = i2c_attach_client(new_client)))
+ goto exit_free;
+
+ /* Initialize the F75383 chip */
+ f75383_init_client(new_client);
+
+ /* Register sysfs hooks */
+ data->class_dev = hwmon_device_register(&new_client->dev);
+ if (IS_ERR(data->class_dev)) {
+ err = PTR_ERR(data->class_dev);
+ goto exit_detach;
+ }
+
+ device_create_file(&new_client->dev,
+ &sensor_dev_attr_temp1_input.dev_attr);
+ device_create_file(&new_client->dev,
+ &sensor_dev_attr_temp2_input.dev_attr);
+ device_create_file(&new_client->dev,
+ &sensor_dev_attr_temp1_min.dev_attr);
+ device_create_file(&new_client->dev,
+ &sensor_dev_attr_temp2_min.dev_attr);
+ device_create_file(&new_client->dev,
+ &sensor_dev_attr_temp1_max.dev_attr);
+ device_create_file(&new_client->dev,
+ &sensor_dev_attr_temp2_max.dev_attr);
+ device_create_file(&new_client->dev, &dev_attr_temp1_crit);
+ device_create_file(&new_client->dev, &dev_attr_temp2_crit);
+ device_create_file(&new_client->dev, &dev_attr_temp1_crit_hyst);
+ device_create_file(&new_client->dev, &dev_attr_temp2_crit_hyst);
+ device_create_file(&new_client->dev, &dev_attr_alarms);
+
+ return 0;
+
+exit_detach:
+ i2c_detach_client(new_client);
+exit_free:
+ kfree(data);
+exit:
+ return err;
+}
+
+/* Idealy we shouldn't have to initialize anything, since the BIOS
+ should have taken care of everything */
+static void f75383_init_client(struct i2c_client *client)
+{
+ struct f75383_data *data = i2c_get_clientdata(client);
+
+ data->config = i2c_smbus_read_byte_data(client,
F75383_REG_CONFIG_READ);
+
+ /* Start converting if needed */
+ if (data->config & 0x40) { /* standby */
+ dev_dbg(&client->dev, "Switching to operational mode");
+ data->config &= 0xBF;
+ i2c_smbus_write_byte_data(client, F75383_REG_CONFIG_WRITE,
+ data->config);
+ }
+
+}
+
+static int f75383_detach_client(struct i2c_client *client)
+{
+ struct f75383_data *data = i2c_get_clientdata(client);
+ int err;
+
+ hwmon_device_unregister(data->class_dev);
+
+ if ((err = i2c_detach_client(client)))
+ return err;
+
+ kfree(data);
+ return 0;
+}
+
+static struct f75383_data *f75383_update_device(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct f75383_data *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->update_lock);
+
+ if (time_after(jiffies, data->last_updated + HZ) || !data->valid) {
+
+ /* order matters for temp2_input */ // Modify this
+ data->temp1[0] = i2c_smbus_read_byte_data(client,
+ F75383_VT1_HIGH) << 8;
+ data->temp1[0] |= i2c_smbus_read_byte_data(client,
+ F75383_VT1_LOW);
+ data->temp1[1] = (i2c_smbus_read_byte_data(client,
+ F75383_VT1_LOW_LIMIT_HIGH_READ) << 8)
+ | i2c_smbus_read_byte_data(client,
+ F75383_VT1_LOW_LIMIT_LOW_BYTE);
+ data->temp1[2] = (i2c_smbus_read_byte_data(client,
+ F75383_VT1_HIGH_LIMIT_HIGH_READ) << 8)
+ | i2c_smbus_read_byte_data(client,
+ F75383_VT1_HIGH_LIMIT_LOW_BYTE);
+ data->temp1_crit_hyst = i2c_smbus_read_byte_data(client,
+ F75383_VT1_THERM_HYST);
+ data->temp1_crit = i2c_smbus_read_byte_data(client,
+ F75383_VT1_THERM_LIMIT);
+
+ data->temp2[0] = i2c_smbus_read_byte_data(client,
+ F75383_VT2_HIGH) << 8;
+ data->temp2[0] |= i2c_smbus_read_byte_data(client,
+ F75383_VT2_LOW);
+ data->temp2[1] = (i2c_smbus_read_byte_data(client,
+ F75383_VT2_LOW_LIMIT_HIGH_READ) << 8)
+ | i2c_smbus_read_byte_data(client,
+ F75383_VT2_LOW_LIMIT_LOW_BYTE);
+ data->temp2[2] = (i2c_smbus_read_byte_data(client,
+ F75383_VT2_HIGH_LIMIT_HIGH_READ) << 8)
+ | i2c_smbus_read_byte_data(client,
+ F75383_VT2_HIGH_LIMIT_LOW_BYTE);
+ data->temp2_crit_hyst = i2c_smbus_read_byte_data(client,
+ F75383_VT2_THERM_HYST);
+ data->temp2_crit = i2c_smbus_read_byte_data(client,
+ F75383_VT2_THERM_LIMIT);
+
+ data->alarms = i2c_smbus_read_byte_data(client,
+ F75383_STATUS) & 0x7F;
+
+ data->last_updated = jiffies;
+ data->valid = 1;
+ }
+
+ mutex_unlock(&data->update_lock);
+
+ return data;
+}
+
+static int __init sensors_f75383_init(void)
+{
+ return i2c_add_driver(&f75383_driver);
+}
+
+static void __exit sensors_f75383_exit(void)
+{
+ i2c_del_driver(&f75383_driver);
+}
+
+MODULE_AUTHOR("Jean Delvare <khali at linux-fr.org> Brian Beardall
<brian at rapsure.net>");
+MODULE_DESCRIPTION("F75383 driver");
+MODULE_LICENSE("GPL");
+
+module_init(sensors_f75383_init);
+module_exit(sensors_f75383_exit);
--- linux-2.6.17/drivers/hwmon/Kconfig 2006-06-17 19:49:35.000000000
-0600
+++ linux-2.6.17-gentoo/drivers/hwmon/Kconfig 2006-06-26
17:57:20.000000000 -0600
@@ -450,6 +450,17 @@ config SENSORS_HDAPS
Say Y here if you have an applicable laptop and want to experience
the awesome power of hdaps.
+config SENSORS_F75383
+ tristate "F75383"
+ depends on HWMON && I2C && EXPERIMENTAL
+ help
+ If you say yes here you get support for the Fintek F75383
+ digital temperature sensor control. Such chips are found
+ on the ECS RX480-A, and ECS NFORCE3-A939 motherboard, among others.
+
+ This driver can also be built as a module. If so, the module
+ will be called f75383.
+
config HWMON_DEBUG_CHIP
bool "Hardware Monitoring Chip debugging messages"
depends on HWMON
--- linux-2.6.17/drivers/hwmon/Makefile 2006-06-17 19:49:35.000000000
-0600
+++ linux-2.6.17-gentoo/drivers/hwmon/Makefile 2006-06-24
18:57:04.000000000 -0600
@@ -44,6 +44,7 @@ obj-$(CONFIG_SENSORS_VIA686A) += via686a
obj-$(CONFIG_SENSORS_VT8231) += vt8231.o
obj-$(CONFIG_SENSORS_W83627EHF) += w83627ehf.o
obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
+obj-$(CONFIG_SENSORS_F75383) += f75383.o
ifeq ($(CONFIG_HWMON_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
^ permalink raw reply [flat|nested] 21+ messages in thread* [lm-sensors] CPU Temp on ECS NFORCE3-A939
2006-06-18 5:13 [lm-sensors] CPU Temp on ECS NFORCE3-A939 Lou Parisi
` (18 preceding siblings ...)
2006-06-27 0:08 ` Brian Beardall
@ 2006-07-03 7:07 ` Lou Parisi
19 siblings, 0 replies; 21+ messages in thread
From: Lou Parisi @ 2006-07-03 7:07 UTC (permalink / raw)
To: lm-sensors
Thanks for your help on this issue from a few weeks ago. I have an update
that may be of interest. I have attached the previous thread for your
reference. This was for an ECS NFORCE3-A939 with an Athlon 64 3000+.
I was not able to monitor my CPU temp using lm sensors because the chip for
my cpu temperature is not supported. Since then I noticed in my boot log
that there was a readout of the cpu temp from acpi. I found the cpu
temperature is being logged to /proc/acpi/thermal_zone/THRM/temperature. I
had already setup tellerstats to create html output for the sensors I was
able to monitor with lm sensors and I was easily able to modify that script
to get the cpu temperature from this location and add it in.
Still would be interested to hear if you add support for my chip in the
future but this seems to accomplish the same thing. Everything else is
working great.
Thanks again, Lou
-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org]
Sent: Tuesday, June 20, 2006 7:53 AM
To: Lou Parisi
Cc: LM Sensors
Subject: Re: [lm-sensors] CPU Temp on ECS NFORCE3-A939
Hi Lou,
> > I wouldn't be surprised if you have the same chip as Brian.
>
> I ran the new sensors-detect and the chip detected was the same as
Brian's.
> Can you please add my name also to the list of those interested in this
> driver. The output from the latest sensors-detect is at the bottom of
this
> page.
I've done so.
> Thank you for all of your help. Lou
You're welcome :) Now the hard part would be to write, review and test
a driver for that chip - but I just don't have the time to do that,
unfortunately.
> By the way, I heard back from ECS. Their response:
> ----------ECS Response ----------
> Dear Valued Customer:
>
> If a monitoring software is being used and is failing to collect data for
> the CPU temprature, the software is incompatible and no monitoring
software
> is available for the board since Hardware Monitor was already integrated
in
> the BIOS.
>
> Thank you for using ECS products
> ---------------------------------
Well, at least they answered, but that wasn't really useful. Good thing
that we found the answer by ourselves meanwhile!
--
Jean Delvare
^ permalink raw reply [flat|nested] 21+ messages in thread