lm_sensors trustworthiness
Hactar
Hi, I recently compiled lm_sensors for my Asus A7V333 (2 GHz Athlon CPU).
The output, once tweaked to remove nonexistent hardware, is this:
asb100-i2c-0-2d
Adapter: SMBus Via Pro adapter at e800
VCore 1: +1.70 V (min = +1.57 V, max = +1.73 V)
+3.3V: +3.10 V (min = +3.14 V, max = +3.46 V)
+5V: +4.84 V (min = +4.74 V, max = +5.24 V)
+12V: +12.35 V (min = +10.83 V, max = +13.19 V)
-12V: -12.90 V (min = -0.00 V, max = -0.00 V)
-5V: -5.41 V (min = -0.00 V, max = -0.00 V)
CPU Fan: 5037 RPM (min = 1997 RPM, div = 4)
Chassis Fan:
2678 RPM (min = 3994 RPM, div = 2)
M/B Temp: +30°C (high = +45°C, hyst = +40°C)
Power Temp:
+14°C (high = +45°C, hyst = +40°C)
CPU Temp: +28°C (high = +60°C, hyst = +50°C)
vid: +1.650 V (VRM Version 9.0)
alarms:
The thermostat says 74F (about 23C), although it's likely a bit warmer
where the computer is. In particular, the "CPU Temp" seems a bit
unbelievable, considering the dinky heat sink on the CPU. Should I believe
the numbers shown here, and if not, how do I find the correct values? Thanks.
--
-eben ebQ...@EtaRmpTabYayU.rIr.OcoPm home.tampabay.rr.com/hactar
SAGITTARIUS: All your friends are laughing behind your back... kill
them. Take down all those naked pictures of Ernest Borgnine you've got
hanging in your den. -- Weird Al, _Your Horoscope for Today_
Grant
>
>Hi, I recently compiled lm_sensors for my Asus A7V333 (2 GHz Athlon CPU).
>The output, once tweaked to remove nonexistent hardware, is this:
>
...
>The thermostat says 74F (about 23C), although it's likely a bit warmer
>where the computer is. In particular, the "CPU Temp" seems a bit
>unbelievable, considering the dinky heat sink on the CPU. Should I believe
>the numbers shown here, and if not, how do I find the correct values? Thanks.
Try reading the values direct from sysfs:
root@sempro:~# sensors
w83697hf-isa-0290
Adapter: ISA adapter
VCore: +1.55 V (min = +1.52 V, max = +1.68 V)
3.3V: +3.28 V (min = +3.14 V, max = +3.47 V)
5V: +5.08 V (min = +4.76 V, max = +5.24 V)
12V: +12.04 V (min = +11.37 V, max = +12.59 V)
-12V: -11.86 V (min = -12.60 V, max = -11.36 V)
-5V: -5.10 V (min = -5.25 V, max = -4.75 V)
V5SB: +4.95 V (min = +4.75 V, max = +5.26 V)
VBatt: +3.38 V (min = +2.90 V, max = +3.41 V)
CPU Fan: 3125 RPM (min = 1500 RPM, div = 4)
CaseFan: 1360 RPM (min = 1196 RPM, div = 8)
Ambient: +26°C (high = +50°C, hyst = +45°C) sensor = thermistor
CPU: +51.5°C (high = +66°C, hyst = +61°C) sensor = diode (beep)
alarms:
beep_enable:
Sound alarm enabled
root@sempro:~# cat /sys/bus/i2c/devices/9191-0290/temp1_input
26000
root@sempro:~# cat /sys/bus/i2c/devices/9191-0290/temp2_input
50500
Temperatures are reported in milliCelsius.
Grant.
Hactar
Grant <g_r_a...@dodo.com.au> wrote:
> On Wed, 28 Dec 2005 20:23:28 GMT, ebe...@tampabay.ARE-ARE.com.unmunge (Hactar) wrote:
>
> >Hi, I recently compiled lm_sensors for my Asus A7V333 (2 GHz Athlon CPU).
> >The output, once tweaked to remove nonexistent hardware, is this:
> ...
> >The thermostat says 74F (about 23C), although it's likely a bit warmer
> >where the computer is. In particular, the "CPU Temp" seems a bit
> >unbelievable, considering the dinky heat sink on the CPU. Should I believe
> >the numbers shown here, and if not, how do I find the correct values? Thanks.
>
> Try reading the values direct from sysfs:
What is sysfs? Is that a 2.6 feature? I'm running 2.4.29:
[eben@pc eben]$ mount | grep sys
[eben@pc eben]$
> root@sempro:~# cat /sys/bus/i2c/devices/9191-0290/temp1_input
> 26000
> root@sempro:~# cat /sys/bus/i2c/devices/9191-0290/temp2_input
> 50500
I also don't have a /sys. There's a file /proc/bus/i2c, but that's not the
same.
--
ebe...@tampabay.ARE-ARE.com / A well-loved and correctly trained domestic
canine is generally slobbery, excitable, noisy, scatalogically obsessed,
xenophobic, pathetically unjudgmental, embarrassingly uninhibited, unreasoningly
devoted, heartbreakingly dependent and wretchedly craven. -- P. B. in AFCA
General Schvantzkoph
>
> Hi, I recently compiled lm_sensors for my Asus A7V333 (2 GHz Athlon CPU).
> The output, once tweaked to remove nonexistent hardware, is this:
>
> asb100-i2c-0-2d
> Adapter: SMBus Via Pro adapter at e800
> VCore 1: +1.70 V (min = +1.57 V, max = +1.73 V)
> +3.3V: +3.10 V (min = +3.14 V, max = +3.46 V)
> +5V: +4.84 V (min = +4.74 V, max = +5.24 V)
> +12V: +12.35 V (min = +10.83 V, max = +13.19 V)
> -12V: -12.90 V (min = -0.00 V, max = -0.00 V)
> -5V: -5.41 V (min = -0.00 V, max = -0.00 V)
> CPU Fan: 5037 RPM (min = 1997 RPM, div = 4)
> Chassis Fan:
> 2678 RPM (min = 3994 RPM, div = 2)
> M/B Temp: +30°C (high = +45°C, hyst = +40°C)
> Power Temp:
> +14°C (high = +45°C, hyst = +40°C)
> CPU Temp: +28°C (high = +60°C, hyst = +50°C)
> vid: +1.650 V (VRM Version 9.0)
> alarms:
>
> The thermostat says 74F (about 23C), although it's likely a bit warmer
> where the computer is. In particular, the "CPU Temp" seems a bit
> unbelievable, considering the dinky heat sink on the CPU. Should I believe
> the numbers shown here, and if not, how do I find the correct values? Thanks.
The quickest check is to reboot and look at the temperatures in the BIOS,
they should be reasonably close to the lm_sensors numbers.
One thing to keep in mind is that the old Athlon motherboards used an
external thermistor instead of an on die thermal diode like the Athlon 64s
so you shouldn't expect the temperature reading to be particularly
accurate.
Grant
>In article <m206r19pcj7dd6e3h...@4ax.com>,
>Grant <g_r_a...@dodo.com.au> wrote:
...
>> Try reading the values direct from sysfs:
>
>What is sysfs? Is that a 2.6 feature? I'm running 2.4.29:
>
>[eben@pc eben]$ mount | grep sys
>[eben@pc eben]$
>
>> root@sempro:~# cat /sys/bus/i2c/devices/9191-0290/temp1_input
>> 26000
...
>I also don't have a /sys. There's a file /proc/bus/i2c, but that's not the
>same.
I'm sorry, sysfs is a 2.6 series feature. Just the other day I tried
my firewall / web server on 2.6.15-rc7 and 2.6.14.5 and it works with
one small change: cat /etc/modules.conf > /etc/modprobe.conf, this is
on a slackware-10.2 system. So 2.6 is ready for you to try?
The alternatives are bleak, the main problem with lm_sensors is the
poor examples of scaling for some chips. Make sure you have the
latest lm_sensors (2.9.2, I think) and take care with the sensors.conf.
I've not used lm_sensors on 2.4 enough to remember the details :(
Grant.
Hactar
Grant <g_r_a...@dodo.com.au> wrote:
> On Thu, 29 Dec 2005 01:34:20 GMT, ebe...@tampabay.ARE-ARE.com.unmunge (Hactar) wrote:
>
> >In article <m206r19pcj7dd6e3h...@4ax.com>,
> >Grant <g_r_a...@dodo.com.au> wrote:
> ...
> >> Try reading the values direct from sysfs:
> >
> >What is sysfs? Is that a 2.6 feature? I'm running 2.4.29:
> >
> >[eben@pc eben]$ mount | grep sys
> >[eben@pc eben]$
> >
> >> root@sempro:~# cat /sys/bus/i2c/devices/9191-0290/temp1_input
> >> 26000
> ...
> >I also don't have a /sys. There's a file /proc/bus/i2c, but that's not the
> >same.
>
> I'm sorry, sysfs is a 2.6 series feature. Just the other day I tried
> my firewall / web server on 2.6.15-rc7 and 2.6.14.5 and it works with
> one small change: cat /etc/modules.conf > /etc/modprobe.conf, this is
> on a slackware-10.2 system. So 2.6 is ready for you to try?
I've gotta make sure VMware works (the version I have, not one that I have to
pay another $100 for) on 2.6. What'll probably happen is that when I get a
USB drive, I'll install a modern distro on it, and use it as a staging area.
> The alternatives are bleak, the main problem with lm_sensors is the
> poor examples of scaling for some chips. Make sure you have the
> latest lm_sensors (2.9.2, I think) and take care with the sensors.conf.
Yeah, I have that. The last time I tried the lm_sensors people hadn't
reverse-engineered the (undocumented) i2c controller chip, so I didn't think
there was any way of reading it other than the BIOS. Wonder of wonders...
> I've not used lm_sensors on 2.4 enough to remember the details :(
Thanks though.
--
-eben ebQ...@EtaRmpTabYayU.rIr.OcoPm home.tampabay.rr.com/hactar
Logic is a systematic method of coming to
the wrong conclusion with confidence.
Grant
>
>Yeah, I have that. The last time I tried the lm_sensors people hadn't
>reverse-engineered the (undocumented) i2c controller chip, so I didn't think
>there was any way of reading it other than the BIOS. Wonder of wonders...
If it is a newish machine, you may have temperature readings
from ACPI, even under 2.4, and nought to do with lm_sensors:
grant@sempro:~$ uname -r
2.4.32-final
grant@sempro:~$ ls /proc/acpi/thermal_zone/THRM/
cooling_mode polling_frequency state temperature trip_points
grant@sempro:~$ cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 55 C
Cheers,
Grant.
Floyd L. Davidson
>Hi, I recently compiled lm_sensors for my Asus A7V333 (2 GHz Athlon CPU).
>The output, once tweaked to remove nonexistent hardware, is this:
The configuration of lm_sensors allows you to adjust readings
in just about any way you want. Which also means that if whatever
is in the config file is not an exact match for the hardware,
the readings will not be "correct">
>asb100-i2c-0-2d
>Adapter: SMBus Via Pro adapter at e800
>VCore 1: +1.70 V (min = +1.57 V, max = +1.73 V)
>+3.3V: +3.10 V (min = +3.14 V, max = +3.46 V)
This one is almost certainly not right.
>+5V: +4.84 V (min = +4.74 V, max = +5.24 V)
>+12V: +12.35 V (min = +10.83 V, max = +13.19 V)
>-12V: -12.90 V (min = -0.00 V, max = -0.00 V)
>-5V: -5.41 V (min = -0.00 V, max = -0.00 V)
Those are all within range., though the min/mx for the two
negative voltages are clearly not set up correctly.
>CPU Fan: 5037 RPM (min = 1997 RPM, div = 4)
>Chassis Fan:
> 2678 RPM (min = 3994 RPM, div = 2)
It's hard to say with the fans, but those are reasonable numbers.
>M/B Temp: +30°C (high = +45°C, hyst = +40°C)
>Power Temp:
> +14°C (high = +45°C, hyst = +40°C)
>CPU Temp: +28°C (high = +60°C, hyst = +50°C)
None of these temperatures are likely to be right.
>vid: +1.650 V (VRM Version 9.0)
This suggests your VCore 1 voltage is not right.
>alarms:
>
>The thermostat says 74F (about 23C), although it's likely a bit warmer
>where the computer is. In particular, the "CPU Temp" seems a bit
>unbelievable, considering the dinky heat sink on the CPU. Should I believe
>the numbers shown here, and if not, how do I find the correct values? Thanks.
Motherboard models may not have the exact same hardware in all
versions, hence someone gets the specifications for one
particular version, sets up a configuration and distributes the
config file as something useful... and on a different
motherboard the results are odd.
And manufacturers don't necessarily provide (any/accurate) details
about the hardware.
Another problem is noise on the inputs to the system monitor
chip. Apparently it isn't common to waste money on bypass
capacitors; the result being a noise spike gets measured now and
then, and it trips the chip alarm circuit. That means chip
alarm indications cannot be trusted unless the measured voltage
indicates an out of bounds voltage too.
That's the bad news. The good news is that in fact you don't
necessarily need "accurate" measurements! What you really
really want... is an indication of a *change*. The trick is
figuring out how big a change should be indicated! That may not
be easy either.
You'll probably want to take the easy route, which can be to
just leave it as it is and remember what it reads so that you
can compare that to whatever it says tomorrow. (At my age,
remembering something tomorrow appears to be impossible, so that
doesn't work.) What I've done in the past was adjust the config
file for each voltage to make it read right on the target. That
way I can take one look, and I may not know what the voltage is,
but it sure gives an instant indication if it changes.
But the problem with that is trying to figure out how much it
changed, and knowing what is "normal". If you actually do have
the hardware specs it is possible to get fairly good voltage
measurements. But if they change the resistor values on the
motherboard, you might well have a reading of 5.00 volts on the
5 volt line when it is in fact 5 volts, but if it reads 5.25
volts that might actually be a voltage of 5.01 or 5.99! That
far off makes it useless...
What I did was download the "tellerstats" package, and then
vastly modify it. I run a cron job that generates a rolling
graph of voltages and temperatures. That provided a useful
baseline to see what kinds of data it produced over time. Things
like "normal" voltage variations.
http://www.apaflo.com/floyd_davidson/sensors/
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) fl...@apaflo.com
ray
>
> Hi, I recently compiled lm_sensors for my Asus A7V333 (2 GHz Athlon CPU).
> The output, once tweaked to remove nonexistent hardware, is this:
>
> asb100-i2c-0-2d
> Adapter: SMBus Via Pro adapter at e800
> VCore 1: +1.70 V (min = +1.57 V, max = +1.73 V)
> +3.3V: +3.10 V (min = +3.14 V, max = +3.46 V)
> +5V: +4.84 V (min = +4.74 V, max = +5.24 V)
> +12V: +12.35 V (min = +10.83 V, max = +13.19 V)
> -12V: -12.90 V (min = -0.00 V, max = -0.00 V)
> -5V: -5.41 V (min = -0.00 V, max = -0.00 V)
> CPU Fan: 5037 RPM (min = 1997 RPM, div = 4)
> Chassis Fan:
> 2678 RPM (min = 3994 RPM, div = 2)
> M/B Temp: +30°C (high = +45°C, hyst = +40°C)
> Power Temp:
> +14°C (high = +45°C, hyst = +40°C)
> CPU Temp: +28°C (high = +60°C, hyst = +50°C)
> vid: +1.650 V (VRM Version 9.0)
> alarms:
>
> The thermostat says 74F (about 23C), although it's likely a bit warmer
> where the computer is. In particular, the "CPU Temp" seems a bit
> unbelievable, considering the dinky heat sink on the CPU. Should I believe
> the numbers shown here, and if not, how do I find the correct values? Thanks.
I would assume that your BIOS has a 'health/monitoring' page - the results
should be in the same ball park.
ANT...@zimage.com
Ditto for this. But I noticed both temperatures are high. I don't think my
temperatures are accurate. Example:
$ sensors -f
w83697hf-isa-0290
Adapter: ISA adapter
VCore: +1.63 V (min = +1.71 V, max = +1.89 V)
+3.3V: +3.23 V (min = +3.14 V, max = +3.47 V)
+5V: +5.11 V (min = +4.76 V, max = +5.24 V)
+12V: +11.61 V (min = +10.82 V, max = +13.19 V)
-12V: -11.87 V (min = -13.18 V, max = -10.80 V)
-5V: -5.00 V (min = -5.25 V, max = -4.75 V)
V5SB: +5.54 V (min = +4.76 V, max = +5.24 V)
VBat: +3.63 V (min = +2.40 V, max = +3.60 V)
fan1: 0 RPM (min = 10546 RPM, div = 2)
fan2: 0 RPM (min = 3325 RPM, div = 2)
temp1: +117 (high = +97?F, hyst = -198?F) sensor = thermistor
temp2: +141.8 (high = +176?F, hyst = +167?F) sensor = thermistor
alarms: Chassis intrusion detection ALARM
beep_enable:
Sound alarm enabled
There is no way it can be 142F already. I haven't had crashes, problems, etc. so I am not
worried. This is with an AMD Athlon XP 2200+ (Actual Clock Speed = 1800 Mhz) CPU (Socket A;
Thoroughbred-A) with a Thermaltake Volcano 9 (heatsink and CPU fan), refurbished MSI KT4AV-L
(Socket A/Socket 462; VIA KT400A; disabled onboard network) motherboard, etc. You can see
the rest of specifications on http://alpha.zimage.com/~ant/antfarm/about/computers.txt
(secondary/backup computer).
> One thing to keep in mind is that the old Athlon motherboards used an
> external thermistor instead of an on die thermal diode like the Athlon 64s
> so you shouldn't expect the temperature reading to be particularly
> accurate.
Interesting.
--
"An ant is a wise creature for itself, but it is a shrewd thing in an orchard or garden." --Francis Bacon
/\___/\
/ /\ /\ \ Phillip (Ant) @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links (AQFL): http://aqfl.net
\ _ / Please remove ANT if replying by e-mail.
( )
Grant
>Ditto for this. But I noticed both temperatures are high. I don't think my
>temperatures are accurate. Example:
>
>$ sensors -f
>w83697hf-isa-0290
>Adapter: ISA adapter
>VCore: +1.63 V (min = +1.71 V, max = +1.89 V)
>+3.3V: +3.23 V (min = +3.14 V, max = +3.47 V)
>+5V: +5.11 V (min = +4.76 V, max = +5.24 V)
>+12V: +11.61 V (min = +10.82 V, max = +13.19 V)
>-12V: -11.87 V (min = -13.18 V, max = -10.80 V)
>-5V: -5.00 V (min = -5.25 V, max = -4.75 V)
>V5SB: +5.54 V (min = +4.76 V, max = +5.24 V)
There's an error in the w83697hf driver causing 5VSB to read ~10% high:
try: "compute in7 (1+(17/33))*@, @/(1+(17/33))" in your /etc/sensors.conf
to correct the scaling.
>VBat: +3.63 V (min = +2.40 V, max = +3.60 V)
>fan1: 0 RPM (min = 10546 RPM, div = 2)
>fan2: 0 RPM (min = 3325 RPM, div = 2)
>temp1: +117 (high = +97?F, hyst = -198?F) sensor = thermistor
>temp2: +141.8 (high = +176?F, hyst = +167?F) sensor = thermistor
These temps are insane, I have the same chip, see other my post about
reading ACPI CPU temperature, though you may no like it in 'C.
I have:
# temperatures
# 1 is onboard
set temp1_over 50
set temp1_hyst 45
# 2 is CPU diode, BIOS set okay
# set temp2_over 66
# set temp2_hyst 61
See that I don't touch CPU temperature as the BIOS set it up for
ACPI access on my mobo:
$ cat /proc/acpi/thermal_zone/THRM/temperature
temperature: 53 C
Cheers,
Grant.
ANT...@zimage.com
> >temperatures are accurate. Example:
> >
> >$ sensors -f
> >w83697hf-isa-0290
> >Adapter: ISA adapter
> >VCore: +1.63 V (min = +1.71 V, max = +1.89 V)
> >+3.3V: +3.23 V (min = +3.14 V, max = +3.47 V)
> >+5V: +5.11 V (min = +4.76 V, max = +5.24 V)
> >+12V: +11.61 V (min = +10.82 V, max = +13.19 V)
> >-12V: -11.87 V (min = -13.18 V, max = -10.80 V)
> >-5V: -5.00 V (min = -5.25 V, max = -4.75 V)
> >V5SB: +5.54 V (min = +4.76 V, max = +5.24 V)
> There's an error in the w83697hf driver causing 5VSB to read ~10% high:
> try: "compute in7 (1+(17/33))*@, @/(1+(17/33))" in your /etc/sensors.conf
> to correct the scaling.
How long has this been there? If it is old, then how come no one fixed it?
> >VBat: +3.63 V (min = +2.40 V, max = +3.60 V)
> >fan1: 0 RPM (min = 10546 RPM, div = 2)
> >fan2: 0 RPM (min = 3325 RPM, div = 2)
> >temp1: +117 (high = +97?F, hyst = -198?F) sensor = thermistor
> >temp2: +141.8 (high = +176?F, hyst = +167?F) sensor = thermistor
> These temps are insane, I have the same chip, see other my post about
> reading ACPI CPU temperature, though you may no like it in 'C.
It is a possibility that this is defective since it is a refurbished
motherboard. Also, BIOS report the similar values. :(
> I have:
> # temperatures
> # 1 is onboard
> set temp1_over 50
> set temp1_hyst 45
> # 2 is CPU diode, BIOS set okay
> # set temp2_over 66
> # set temp2_hyst 61
> See that I don't touch CPU temperature as the BIOS set it up for
> ACPI access on my mobo:
> $ cat /proc/acpi/thermal_zone/THRM/temperature
> temperature: 53 C
Hmm, I don't get that:
$ cat /proc/acpi/thermal_zone/THRM/temperature
cat: /proc/acpi/thermal_zone/THRM/temperature: No such file or directory
Grant
>> There's an error in the w83697hf driver causing 5VSB to read ~10% high:
>> try: "compute in7 (1+(17/33))*@, @/(1+(17/33))" in your /etc/sensors.conf
>> to correct the scaling.
>
>How long has this been there? If it is old, then how come no one fixed it?
I was told it would break userspace :( Been there at least since
March'05, as somebody misread datasheet. Stuff happens. They have
a stupid mix of kernel space and userspace scaling for hwmon values.
>> >temp1: +117 (high = +97?F, hyst = -198?F) sensor = thermistor
>> >temp2: +141.8 (high = +176?F, hyst = +167?F) sensor = thermistor
>
>> These temps are insane, I have the same chip, see other my post about
>> reading ACPI CPU temperature, though you may no like it in 'C.
CPU is a diode on my K7:
Ambient: +39°C (high = +50°C, hyst = +45°C) sensor = thermistor
CPU: +60.5°C (high = +66°C, hyst = +61°C) sensor = diode (beep)
>
>It is a possibility that this is defective since it is a refurbished
>motherboard. Also, BIOS report the similar values. :(
...
>> $ cat /proc/acpi/thermal_zone/THRM/temperature
>> temperature: 53 C
>
>Hmm, I don't get that:
>$ cat /proc/acpi/thermal_zone/THRM/temperature
>cat: /proc/acpi/thermal_zone/THRM/temperature: No such file or directory
See what `ls /proc/acpi` says, no ACPI or not supported? a
`grep = .config` dmesg, etc from:
http://bugsplatter.mine.nu/test/boxen/sempro/
Grant.
Grant
>> >temp1: +117 (high = +97?F, hyst = -198?F) sensor = thermistor
>> >temp2: +141.8 (high = +176?F, hyst = +167?F) sensor = thermistor
>
>> These temps are insane, I have the same chip, see other my post about
>> reading ACPI CPU temperature, though you may no like it in 'C.
>
>It is a possibility that this is defective since it is a refurbished
>motherboard. Also, BIOS report the similar values. :(
I retract that: for 'F reading those temps look okay as 140'F ~ 60'C
which is fine for an athlon :) I just had to visit BIOS to up CPU
temp here as we expect 39'C today and 41'C tomorrow, no airco :(
Grant.
ANT...@zimage.com
> >> There's an error in the w83697hf driver causing 5VSB to read ~10% high:
> >> try: "compute in7 (1+(17/33))*@, @/(1+(17/33))" in your /etc/sensors.conf
> >> to correct the scaling.
> >
> >How long has this been there? If it is old, then how come no one fixed it?
> I was told it would break userspace :( Been there at least since
You mean your fix would break userspace? If so, then I ain't touching. ;) It's
fine even if the numbers are inaccurate. :P
> March'05, as somebody misread datasheet. Stuff happens. They have
> a stupid mix of kernel space and userspace scaling for hwmon values.
:( I hope someone fixes it soon (not me).
> >> >temp1: +117 (high = +97?F, hyst = -198?F) sensor = thermistor
> >> >temp2: +141.8 (high = +176?F, hyst = +167?F) sensor = thermistor
> >
> >> These temps are insane, I have the same chip, see other my post about
> >> reading ACPI CPU temperature, though you may no like it in 'C.
> CPU is a diode on my K7:
> Ambient: +39°C (high = +50°C, hyst = +45°C) sensor = thermistor
> CPU: +60.5°C (high = +66°C, hyst = +61°C) sensor = diode (beep)
Ah, mine is thermistors. Hmm.
> >It is a possibility that this is defective since it is a refurbished
> >motherboard. Also, BIOS report the similar values. :(
> ...
> >> $ cat /proc/acpi/thermal_zone/THRM/temperature
> >> temperature: 53 C
> >
> >Hmm, I don't get that:
> >$ cat /proc/acpi/thermal_zone/THRM/temperature
> >cat: /proc/acpi/thermal_zone/THRM/temperature: No such file or directory
> See what `ls /proc/acpi` says, no ACPI or not supported? a
> `grep = .config` dmesg, etc from:
> http://bugsplatter.mine.nu/test/boxen/sempro/
$ ls -all /proc/acpi
total 0
dr-xr-xr-x 4 root root 0 2005-12-30 07:55 .
dr-xr-xr-x 126 root root 0 2005-12-29 20:13 ..
-rw-r--r-- 1 root root 0 2005-12-30 07:55 alarm
-r-------- 1 root root 0 2005-12-30 07:55 dsdt
dr-xr-xr-x 2 root root 0 2005-12-30 07:55 embedded_controller
-r-------- 1 root root 0 2005-12-30 07:55 event
-r-------- 1 root root 0 2005-12-30 07:55 fadt
-r--r--r-- 1 root root 0 2005-12-30 07:55 info
dr-xr-xr-x 6 root root 0 2005-12-30 07:55 power_resource
-rw-r--r-- 1 root root 0 2005-12-30 07:55 wakeup
$ `grep = .config` dmesg
grep: .config: No such file or directory
sh table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 8
NET: Registered protocol family 20
Using IPI Shortcut mode
ACPI wakeup devices:
PCI0 USB1 USB2 USB3 USB4 EHCI USBD UAR1 AC9 MC9 ILAN SLPB
ACPI: (supports S0 S1 S4 S5)
Freeing unused kernel memory: 180k freed
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:0f.0
ACPI: PCI Interrupt 0000:00:0f.0[A] -> GSI 20 (level, low) -> IRQ 169
PCI: Via IRQ fixup for 0000:00:0f.0, from 255 to 9
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.0
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: ST380011A, ATA DISK drive
hdb: QUANTUM FIREBALL EX6.4A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: TOSHIBA DVD-ROM SD-M1912, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 1024KiB
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 >
hdb: max request size: 128KiB
hdb: 12594960 sectors (6448 MB) w/418KiB Cache, CHS=13328/15/63, UDMA(33)
hdb: cache flushes not supported
hdb: hdb1 hdb2 < hdb5 >
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
input: PC Speaker
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Real Time Clock Driver v1.12
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Linux agpgart interface v0.101 (c) Dave Jones
e100: Intel(R) PRO/100 Network Driver, 3.4.14-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 17 (level, low) -> IRQ 177
e100: eth0: e100_probe: addr 0xdffff000, irq 177, MAC addr 00:D0:B7:85:0A:3F
agpgart: Detected VIA KT400/KT400A/KT600 chipset
agpgart: AGP aperture is 128M @ 0xe0000000
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:10.0[A] -> GSI 21 (level, low) -> IRQ 185
PCI: Via IRQ fixup for 0000:00:10.0, from 11 to 9
uhci_hcd 0000:00:10.0: UHCI Host Controller
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:10.0: irq 185, io base 0x0000dc00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
hdc: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ACPI: PCI Interrupt 0000:00:10.1[A] -> GSI 21 (level, low) -> IRQ 185
PCI: Via IRQ fixup for 0000:00:10.1, from 11 to 9
uhci_hcd 0000:00:10.1: UHCI Host Controller
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:10.1: irq 185, io base 0x0000e000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.2[B] -> GSI 21 (level, low) -> IRQ 185
PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 9
uhci_hcd 0000:00:10.2: UHCI Host Controller
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:10.2: irq 185, io base 0x0000e400
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.3[B] -> GSI 21 (level, low) -> IRQ 185
PCI: Via IRQ fixup for 0000:00:10.3, from 10 to 9
uhci_hcd 0000:00:10.3: UHCI Host Controller
uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:10.3: irq 185, io base 0x0000e800
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-2: new low speed USB device using uhci_hcd and address 2
ACPI: PCI Interrupt 0000:00:10.4[C] -> GSI 21 (level, low) -> IRQ 185
PCI: Via IRQ fixup for 0000:00:10.4, from 3 to 9
ehci_hcd 0000:00:10.4: EHCI Host Controller
ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:10.4: irq 185, io mem 0xdfffee00
ehci_hcd 0000:00:10.4: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
ACPI: PCI Interrupt 0000:00:11.5[C] -> GSI 22 (level, low) -> IRQ 193
PCI: Via IRQ fixup for 0000:00:11.5, from 3 to 1
PCI: Setting latency timer of device 0000:00:11.5 to 64
input: PS/2 Generic Mouse on isa0060/serio1
usb 1-2: new low speed USB device using uhci_hcd and address 3
EXT3 FS on hda1, internal journal
usbcore: registered new driver yealink
drivers/usb/input/yealink.c: Yealink phone driver:yld-20050816
usbcore: registered new driver hiddev
hiddev96: USB HID v1.10 Device [American Power Conversion Back-UPS RS 1500 FW:8.g8 .D USB FW:g8] on
usb-0000:00:10.0-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda9, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda10, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda11, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda12, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdb1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdb5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ip_tables: (C) 2000-2002 Netfilter core team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.3 (8191 buckets, 65528 max) - 236 bytes per conntrack
e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex
NET: Registered protocol family 10
Disabled Privacy Extensions on device c0326b40(lo)
IPv6 over IPv4 tunneling driver
vmmon: module license 'unspecified' taints kernel.
/dev/vmmon[4560]: Module vmmon: registered with major=10 minor=165
/dev/vmmon[4560]: Module vmmon: initialized
/dev/vmnet: open called by PID 4589 (vmnet-bridge)
/dev/vmnet: hub 0 does not exist, allocating memory.
/dev/vmnet: port on hub 0 successfully opened
bridge-eth0: enabling the bridge
bridge-eth0: up
bridge-eth0: already up
bridge-eth0: attached
/dev/vmnet: open called by PID 4603 (vmnet-natd)
/dev/vmnet: hub 8 does not exist, allocating memory.
/dev/vmnet: port on hub 8 successfully opened
eth0: no IPv6 routers present
/dev/vmnet: open called by PID 4652 (vmnet-netifup)
/dev/vmnet: port on hub 8 successfully opened
/dev/vmnet: open called by PID 4653 (vmnet-netifup)
/dev/vmnet: hub 1 does not exist, allocating memory.
/dev/vmnet: port on hub 1 successfully opened
/dev/vmnet: open called by PID 4685 (vmnet-dhcpd)
/dev/vmnet: port on hub 8 successfully opened
/dev/vmnet: open called by PID 4681 (vmnet-dhcpd)
/dev/vmnet: port on hub 1 successfully opened
vmnet8: no IPv6 routers present
vmnet1: no IPv6 routers present
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 201
NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module 1.0-8178 Wed Dec 14 16:22:51 PST 2005
agpgart: Found an AGP 3.5 compliant device at 0000:00:00.0.
agpgart: Device is in legacy mode, falling back to 2.x
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
agpgart: Found an AGP 3.5 compliant device at 0000:00:00.0.
agpgart: Device is in legacy mode, falling back to 2.x
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
I hope that helps. ;)
Grant
>Grant <g_r_a...@dodo.com.au> wrote:
>> On Thu, 29 Dec 2005 17:52:50 -0600, ANT...@zimage.com wrote:
>
>> >> There's an error in the w83697hf driver causing 5VSB to read ~10% high:
>> >> try: "compute in7 (1+(17/33))*@, @/(1+(17/33))" in your /etc/sensors.conf
>> >> to correct the scaling.
>> >
>> >How long has this been there? If it is old, then how come no one fixed it?
>
>> I was told it would break userspace :( Been there at least since
>
>You mean your fix would break userspace? If so, then I ain't touching. ;) It's
>fine even if the numbers are inaccurate. :P
That fix above _is_ the userspace scaling for the sensors program
to get correct voltage reading.
If the kernel driver had that scaling, then you'd not need to do the
scaling for sensors program to read 5VSB correctly. Got it?
[el snippo]
>I hope that helps. ;)
Shows you do not have temperature stuff in ACPI, older mobo/BIOS.
Your temps are okay for 'F, though the alarm limits are way off.
Grant.
Hactar
Should I think that ACPI's readings would be more accurate than those
lm_sensors providesP
--
-eben ebQ...@EtaRmpTabYayU.rIr.OcoPm home.tampabay.rr.com/hactar
Every normal man must be tempted at times to spit upon his hands,
hoist the black flag, and begin slitting throats. -- H.L. Mencken
Grant
>In article <0k17r1po0p1n6blv3...@4ax.com>,
>Grant <g_r_a...@dodo.com.au> wrote:
>> On Thu, 29 Dec 2005 04:57:29 GMT, ebe...@tampabay.ARE-ARE.com.unmunge (Hactar) wrote:
>>
>> >
>> >Yeah, I have that. The last time I tried the lm_sensors people hadn't
>> >reverse-engineered the (undocumented) i2c controller chip, so I didn't think
>> >there was any way of reading it other than the BIOS. Wonder of wonders...
>>
>> If it is a newish machine, you may have temperature readings
>> from ACPI, even under 2.4, and nought to do with lm_sensors:
>>
>> grant@sempro:~$ uname -r
>> 2.4.32-final
>> grant@sempro:~$ ls /proc/acpi/thermal_zone/THRM/
>> cooling_mode polling_frequency state temperature trip_points
>> grant@sempro:~$ cat /proc/acpi/thermal_zone/THRM/temperature
>> temperature: 55 C
>
>Should I think that ACPI's readings would be more accurate than those
>lm_sensors providesP
Accuracy? The same measurement device is being used, but lm_sensors
is subject to user calibration (scaling), which might not be accurate,
then again, lm_sensors can convert 'C to 'F, if that be your preference.
Temperature and fan speed[1] can be trusted, voltage monitoring is
more difficult: how many computer users have access to a voltmeter
and know how to calculate scaling factors? Another problem here is
that voltage measurement may depend on components selected by the
mobo maker.
[1]Fan speed reading zero is corrected by increasing the fan divider
value, a couple drivers do this automatically.
Grant.
Hactar
Floyd L. Davidson <fl...@apaflo.com> wrote:
> ebe...@tampabay.ARE-ARE.com.unmunge (Hactar) wrote:
>
> >asb100-i2c-0-2d
> >Adapter: SMBus Via Pro adapter at e800
> >VCore 1: +1.70 V (min = +1.57 V, max = +1.73 V)
> >+3.3V: +3.10 V (min = +3.14 V, max = +3.46 V)
>
> This one is almost certainly not right.
Could the power supply just produce a low voltage, or is that highly
unlikely?
> >+5V: +4.84 V (min = +4.74 V, max = +5.24 V)
> >+12V: +12.35 V (min = +10.83 V, max = +13.19 V)
> >-12V: -12.90 V (min = -0.00 V, max = -0.00 V)
> >-5V: -5.41 V (min = -0.00 V, max = -0.00 V)
>
> Those are all within range., though the min/mx for the two
> negative voltages are clearly not set up correctly.
Yeah, I'll look at that.
> >CPU Fan: 5037 RPM (min = 1997 RPM, div = 4)
> >Chassis Fan:
> > 2678 RPM (min = 3994 RPM, div = 2)
>
> It's hard to say with the fans, but those are reasonable numbers.
The chassis fan (actually there are four of them, but I ran out of sensors
after one) alternates with 0 RPM. Flaky sensor or pulser, I guess.
> >M/B Temp: +30°C (high = +45°C, hyst = +40°C)
> >Power Temp:
> > +14°C (high = +45°C, hyst = +40°C)
> >CPU Temp: +28°C (high = +60°C, hyst = +50°C)
>
> None of these temperatures are likely to be right.
The Power Temp is meaningless; it isn't hooked up to anything (it's fixed
so it doesn't show). The rest, do you think they're too low or what?
> >vid: +1.650 V (VRM Version 9.0)
>
> This suggests your VCore 1 voltage is not right.
Because they should be the same?
> That's the bad news. The good news is that in fact you don't
> necessarily need "accurate" measurements! What you really
> really want... is an indication of a *change*.
Sure, that'll tell me when something goes bad. But how do I know if
something's bad already (I just compiled lm_sensors)?
> What I did was download the "tellerstats" package, and then
> vastly modify it. I run a cron job that generates a rolling
> graph of voltages and temperatures. That provided a useful
> baseline to see what kinds of data it produced over time. Things
> like "normal" voltage variations.
>
> http://www.apaflo.com/floyd_davidson/sensors/
Nice. What grapher did you use? "tellerstats" seems to be a frontend for
something. How did you get whatever to parse dates? I can't see how to
get plotutils to do so.
--
-eben ebQ...@EtaRmpTabYayU.rIr.OcoPm home.tampabay.rr.com/hactar
CANCER: The position of Jupiter says that you should spend the
rest of the week face down in the mud. Try not to shove a roll of
duct tape up your nose when taking your driver's test. -- Weird Al
Floyd L. Davidson
>Floyd L. Davidson <fl...@apaflo.com> wrote:
>> ebe...@tampabay.ARE-ARE.com.unmunge (Hactar) wrote:
>>
>> >asb100-i2c-0-2d
>> >Adapter: SMBus Via Pro adapter at e800
>> >VCore 1: +1.70 V (min = +1.57 V, max = +1.73 V)
>> >+3.3V: +3.10 V (min = +3.14 V, max = +3.46 V)
>>
>> This one is almost certainly not right.
>
>Could the power supply just produce a low voltage, or is that highly
>unlikely?
It could... but the chances that it is are 1% and the changes
that it isn't are about 99.9%. :-)
>> >M/B Temp: +30°C (high = +45°C, hyst = +40°C)
>> >Power Temp:
>> > +14°C (high = +45°C, hyst = +40°C)
>> >CPU Temp: +28°C (high = +60°C, hyst = +50°C)
>>
>> None of these temperatures are likely to be right.
>
>The Power Temp is meaningless; it isn't hooked up to anything (it's fixed
>so it doesn't show). The rest, do you think they're too low or what?
Well, your CPU is not likely to be cooler than you
motherboard... :-) It's hard to say what they actually should be
though, because it depends on the ambient temperature, the
circulation in the case, what kind of fan you have on it, and
how long the system has been running.
But your BIOS should have a way to monitor voltages and
temperatures. The best way to configure temperatures (maybe
voltages too) is to see what the built in monitor program says,
and try to get lm_sensors to read about the same.
>> >vid: +1.650 V (VRM Version 9.0)
>>
>> This suggests your VCore 1 voltage is not right.
>
>Because they should be the same?
I'm not sure, but that seems right to me. I may be wrong
though... it's been a long time since I messed with this stuff!
Somebody will tell us...
>> That's the bad news. The good news is that in fact you don't
>> necessarily need "accurate" measurements! What you really
>> really want... is an indication of a *change*.
>
>Sure, that'll tell me when something goes bad. But how do I know if
>something's bad already (I just compiled lm_sensors)?
Your computer is still working, right??? That's a fair
indication that it isn't bad. If it starts going bad, things
will change. If it is already bad, things will change. Same
difference either way!
>> What I did was download the "tellerstats" package, and then
>> vastly modify it. I run a cron job that generates a rolling
>> graph of voltages and temperatures. That provided a useful
>> baseline to see what kinds of data it produced over time. Things
>> like "normal" voltage variations.
>>
>> http://www.apaflo.com/floyd_davidson/sensors/
>
>Nice. What grapher did you use? "tellerstats" seems to be a frontend for
>something. How did you get whatever to parse dates? I can't see how to
>get plotutils to do so.
It uses gnuplot to generate graphs (I worked for quite awhile
with another program once, and eventually decided that gnuplot
was worth keeping). Dates are parsed with bash, data from the
sensors is parsed with awk and manipulated with bc.
There is a link on the above URL to the source code.
Grant
>ebe...@tampabay.ARE-ARE.com.unmunge (Hactar) wrote:
>>Floyd L. Davidson <fl...@apaflo.com> wrote:
>>> ebe...@tampabay.ARE-ARE.com.unmunge (Hactar) wrote:
>>>
>>> >asb100-i2c-0-2d
>>> >Adapter: SMBus Via Pro adapter at e800
>>> >VCore 1: +1.70 V (min = +1.57 V, max = +1.73 V)
>>> >+3.3V: +3.10 V (min = +3.14 V, max = +3.46 V)
>>>
>>> This one is almost certainly not right.
>>
>>Could the power supply just produce a low voltage, or is that highly
>>unlikely?
>
>It could... but the chances that it is are 1% and the changes
>that it isn't are about 99.9%. :-)
Maybe it's wired to read the battery?
>>> >vid: +1.650 V (VRM Version 9.0)
>>>
>>> This suggests your VCore 1 voltage is not right.
>>
>>Because they should be the same?
>
>I'm not sure, but that seems right to me. I may be wrong
>though... it's been a long time since I messed with this stuff!
>Somebody will tell us...
Seems I'm playing 'somebody' :-) vid is the setpoint, VCore1 is
the measure -- as it is only 3% high, very likely okay. A difficult
one to measure properly due to very high current (many tens of amps),
the mobo maker may be allowing for some IR drop to the CPU power pins.
>
>>> That's the bad news. The good news is that in fact you don't
>>> necessarily need "accurate" measurements! What you really
>>> really want... is an indication of a *change*.
Yes!
...
>It uses gnuplot to generate graphs (I worked for quite awhile
>with another program once, and eventually decided that gnuplot
>was worth keeping). Dates are parsed with bash, data from the
>sensors is parsed with awk and manipulated with bc.
You could put an exponential filter in (from memory):
x = (x_new * a) + (1 - a) * x # a is say .05 to .20, lower is smoother
to smooth those voltages? The spikes don't say much given the
measurement environment ;)
Cheers,
Grant.
Floyd L. Davidson
>On Sat, 31 Dec 2005 12:28:47 -0900, fl...@apaflo.com (Floyd L. Davidson) wrote:
>
>>ebe...@tampabay.ARE-ARE.com.unmunge (Hactar) wrote:
>>>Floyd L. Davidson <fl...@apaflo.com> wrote:
>>>> ebe...@tampabay.ARE-ARE.com.unmunge (Hactar) wrote:
>>>>
>>>> >asb100-i2c-0-2d
>>>> >Adapter: SMBus Via Pro adapter at e800
>>>> >VCore 1: +1.70 V (min = +1.57 V, max = +1.73 V)
>>>> >+3.3V: +3.10 V (min = +3.14 V, max = +3.46 V)
>>>>
>>>> This one is almost certainly not right.
>>>
>>>Could the power supply just produce a low voltage, or is that highly
>>>unlikely?
>>
>>It could... but the chances that it is are 1% and the changes
>>that it isn't are about 99.9%. :-)
>
>Maybe it's wired to read the battery?
Could be! And of course in that case it is labeled wrong in
the sensors config file.
>>>> >vid: +1.650 V (VRM Version 9.0)
>>>>
>>>> This suggests your VCore 1 voltage is not right.
>>>
>>>Because they should be the same?
>>
>>I'm not sure, but that seems right to me. I may be wrong
>>though... it's been a long time since I messed with this stuff!
>>Somebody will tell us...
>
>Seems I'm playing 'somebody' :-) vid is the setpoint, VCore1 is
>the measure -- as it is only 3% high, very likely okay. A difficult
>one to measure properly due to very high current (many tens of amps),
>the mobo maker may be allowing for some IR drop to the CPU power pins.
That's what I thought. My bet is that it should read 1.650,
and that is what I would adjust the config file to make it read,
and is the voltage I'd use to calculate the alarm points.
>>>> That's the bad news. The good news is that in fact you don't
>>>> necessarily need "accurate" measurements! What you really
>>>> really want... is an indication of a *change*.
>
>Yes!
>...
>>It uses gnuplot to generate graphs (I worked for quite awhile
>>with another program once, and eventually decided that gnuplot
>>was worth keeping). Dates are parsed with bash, data from the
>>sensors is parsed with awk and manipulated with bc.
>
>You could put an exponential filter in (from memory):
>
> x = (x_new * a) + (1 - a) * x # a is say .05 to .20, lower is smoother
>
>to smooth those voltages? The spikes don't say much given the
>measurement environment ;)
I've thought about it. I'm not sure if the spikes that get
measured mean anything or not. What I've decided to do is leave
the spikes in, and after watching it for a long time, I've
adjusted the scale on each graph, plus maximum and minimum
targets, to make it easy to see where the spikes normally fall
such that if it changes it will be noticeable (just like the
absolute voltage itself). (The absolute voltage is always close
to a green "normal" line, and the spikes never go above or below
a set of red "max" and "min" lines.)
The basic problem is that the spikes that are graphed are *not*
showing up as the same levels as the noise that causes the chip
to indicate alarms. The chip alarms can be adjusted beyond the
range of graphed spikes, and the alarms will still be triggered.
Hence the noise triggering the alarm is greater than the
spikes. They also don't seem to be time related. Hence it
appears they are not one and the same... and I don't know
precisely whether those spikes that get graphed are real voltage
spikes, or just some anomaly in the measuring hardware (which
certainly does have some other anomalies).
It was really an interesting project, and I haven't messed with
it for months.
ANT...@zimage.com
> >Grant <g_r_a...@dodo.com.au> wrote:
> >> On Thu, 29 Dec 2005 17:52:50 -0600, ANT...@zimage.com wrote:
> >
> >> >> There's an error in the w83697hf driver causing 5VSB to read ~10% high:
> >> >> try: "compute in7 (1+(17/33))*@, @/(1+(17/33))" in your /etc/sensors.conf
> >> >> to correct the scaling.
> >> >
> >> >How long has this been there? If it is old, then how come no one fixed it?
> >
> >> I was told it would break userspace :( Been there at least since
> >
> >You mean your fix would break userspace? If so, then I ain't touching. ;) It's
> >fine even if the numbers are inaccurate. :P
> That fix above _is_ the userspace scaling for the sensors program
> to get correct voltage reading.
Oh OK! I will change it then since I recently upgraded Kernel to 2.6.14
and still see no fixes.
> If the kernel driver had that scaling, then you'd not need to do the
> scaling for sensors program to read 5VSB correctly. Got it?
Gotcha.
> [el snippo]
> >I hope that helps. ;)
> Shows you do not have temperature stuff in ACPI, older mobo/BIOS.
> Your temps are okay for 'F, though the alarm limits are way off.
OK.
--
"Whenever I see an old lady slip and fall on a wet sidewalk, my first instinct is to laugh. But then I think, what if I was an ant, and she fell on me. Then it wouldn't seem quite so funny." --Saturday Night Live FAQ: Deep Thoughts
ANT...@zimage.com
> >temperatures are accurate. Example:
> >
> >$ sensors -f
> >w83697hf-isa-0290
> >Adapter: ISA adapter
> >VCore: +1.63 V (min = +1.71 V, max = +1.89 V)
> >+3.3V: +3.23 V (min = +3.14 V, max = +3.47 V)
> >+5V: +5.11 V (min = +4.76 V, max = +5.24 V)
> >+12V: +11.61 V (min = +10.82 V, max = +13.19 V)
> >-12V: -11.87 V (min = -13.18 V, max = -10.80 V)
> >-5V: -5.00 V (min = -5.25 V, max = -4.75 V)
> >V5SB: +5.54 V (min = +4.76 V, max = +5.24 V)
> There's an error in the w83697hf driver causing 5VSB to read ~10% high:
> try: "compute in7 (1+(17/33))*@, @/(1+(17/33))" in your /etc/sensors.conf
> to correct the scaling.
# sensors -f
w83697hf-isa-0290
Adapter: ISA adapter
VCore: +1.63 V (min = +1.71 V, max = +1.89 V)
+3.3V: +3.23 V (min = +3.14 V, max = +3.47 V)
+5V: +5.08 V (min = +4.76 V, max = +5.24 V)
+12V: +11.61 V (min = +10.82 V, max = +13.19 V)
-12V: -11.87 V (min = -13.18 V, max = -10.80 V)
-5V: -5.05 V (min = -5.25 V, max = -4.75 V)
V5SB: +5.54 V (min = +4.76 V, max = +5.24 V)
VBat: +3.63 V (min = +2.40 V, max = +3.60 V)
temp1: +126F (high = +97F, hyst = -198F) sensor = thermistor
temp2: +151.7F (high = +176F, hyst = +167F) sensor = thermistor
alarms: Chassis intrusion detection ALARM
beep_enable:
Sound alarm enabled
How's that now? I didn't paste the fans' RPMs.
--
"Whenever I see an old lady slip and fall on a wet sidewalk, my first instinct is to laugh. But then I think, what if I was an ant, and she fell on me. Then it wouldn't seem quite so funny." --Saturday Night Live FAQ: Deep Thoughts
Grant
># sensors -f
>w83697hf-isa-0290
>Adapter: ISA adapter
>VCore: +1.63 V (min = +1.71 V, max = +1.89 V)
>+3.3V: +3.23 V (min = +3.14 V, max = +3.47 V)
>+5V: +5.08 V (min = +4.76 V, max = +5.24 V)
>+12V: +11.61 V (min = +10.82 V, max = +13.19 V)
>-12V: -11.87 V (min = -13.18 V, max = -10.80 V)
>-5V: -5.05 V (min = -5.25 V, max = -4.75 V)
>V5SB: +5.54 V (min = +4.76 V, max = +5.24 V)
>VBat: +3.63 V (min = +2.40 V, max = +3.60 V)
>temp1: +126F (high = +97F, hyst = -198F) sensor = thermistor
>temp2: +151.7F (high = +176F, hyst = +167F) sensor = thermistor
>alarms: Chassis intrusion detection ALARM
>beep_enable:
> Sound alarm enabled
>
>How's that now? I didn't paste the fans' RPMs.
Nah, something's off, tell me the readings from sysfs, first
confirm the hwmon directory, on my box it is:
$ ls /sys/bus/i2c/devices/9191-0290/
alarms fan1_min in0_min in4_input in6_max in8_min temp1_max_hyst
beep_enable fan2_div in2_input in4_max in6_min name temp1_type
beep_mask fan2_input in2_max in4_min in7_input power/ temp2_input
bus@ fan2_min in2_min in5_input in7_max pwm1 temp2_max
driver@ hwmon:hwmon0@ in3_input in5_max in7_min pwm2 temp2_max_hyst
fan1_div in0_input in3_max in5_min in8_input temp1_input temp2_type
fan1_input in0_max in3_min in6_input in8_max temp1_max uevent
That last directory name might be different, but it is likely the
only one under devices. cd into there and display the raw voltage
readings like so (assuming bash):
$ cd /sys/bus/i2c/devices/9191-0290/
$ for X in 0 2 3 4 5 6 7 8; do echo -ne "$X\t"; cat in${X}_input; done
0 1552
2 3280
3 3024
4 3152
5 608
6 832
7 3264
8 3376
May as well look at the temps:
$ for X in 1 2; do cat temp${X}_input; done
26000
50000
This way I can see what the chip is telling lm_sensors.
Grant.
ANT...@zimage.com
> >w83697hf-isa-0290
> >Adapter: ISA adapter
> >VCore: +1.63 V (min = +1.71 V, max = +1.89 V)
> >+3.3V: +3.23 V (min = +3.14 V, max = +3.47 V)
> >+5V: +5.08 V (min = +4.76 V, max = +5.24 V)
> >+12V: +11.61 V (min = +10.82 V, max = +13.19 V)
> >-12V: -11.87 V (min = -13.18 V, max = -10.80 V)
> >-5V: -5.05 V (min = -5.25 V, max = -4.75 V)
> >V5SB: +5.54 V (min = +4.76 V, max = +5.24 V)
> >VBat: +3.63 V (min = +2.40 V, max = +3.60 V)
> >temp1: +126F (high = +97F, hyst = -198F) sensor = thermistor
> >temp2: +151.7F (high = +176F, hyst = +167F) sensor = thermistor
> >alarms: Chassis intrusion detection ALARM
> >beep_enable:
> > Sound alarm enabled
> >
> >How's that now? I didn't paste the fans' RPMs.
> Nah, something's off, tell me the readings from sysfs, first
> confirm the hwmon directory, on my box it is:
$ ls /sys/bus/i2c/devices/9191-0290/
alarms fan1_input in0_input in3_input in5_input in7_input name temp1_max_hyst
beep_enable fan1_min in0_max in3_max in5_max in7_max power temp1_type
beep_mask fan2_div in0_min in3_min in5_min in7_min pwm1 temp2_input
bus fan2_input in2_input in4_input in6_input in8_input pwm2 temp2_max
driver fan2_min in2_max in4_max in6_max in8_max temp1_input temp2_max_hyst
fan1_div hwmon:hwmon0 in2_min in4_min in6_min in8_min temp1_max temp2_type
> $ ls /sys/bus/i2c/devices/9191-0290/
> alarms fan1_min in0_min in4_input in6_max in8_min temp1_max_hyst
> beep_enable fan2_div in2_input in4_max in6_min name temp1_type
> beep_mask fan2_input in2_max in4_min in7_input power/ temp2_input
> bus@ fan2_min in2_min in5_input in7_max pwm1 temp2_max
> driver@ hwmon:hwmon0@ in3_input in5_max in7_min pwm2 temp2_max_hyst
> fan1_div in0_input in3_max in5_min in8_input temp1_input temp2_type
> fan1_input in0_max in3_min in6_input in8_max temp1_max uevent
> That last directory name might be different, but it is likely the
> only one under devices. cd into there and display the raw voltage
> readings like so (assuming bash):
> $ cd /sys/bus/i2c/devices/9191-0290/
$ pwd
/sys/bus/i2c/devices
> $ for X in 0 2 3 4 5 6 7 8; do echo -ne "$X\t"; cat in${X}_input; done
> 0 1552
> 2 3280
> 3 3024
> 4 3152
> 5 608
> 6 832
> 7 3264
> 8 3376
> May as well look at the temps:
> $ for X in 1 2; do cat temp${X}_input; done
> 26000
> 50000
> This way I can see what the chip is telling lm_sensors.
$ pwd
/sys/bus/i2c/devices/9191-0290
$ for X in 0 2 3 4 5 6 7 8; do echo -ne "$X\t"; cat in${X}_input; done
0 1648
2 3280
3 3040
4 3040
5 576
6 848
7 3296
8 3616
Grant
>0 1648
>2 3280
>3 3040
>4 3040
>5 576
>6 848
>7 3296
>8 3616
mV reading scale factor V
VCore 0 1648 * 1 1.648 Okay
3.3 2 3280 * 1 3.280 Okay
5.0 3 3040 * (34 + 50) / 50 5.107 Okay
12.0 4 3040 external scale ?.?
-12.0 5 576 '' '' ?.?
-5.0 6 848 '' '' ?.?
5VSB 7 3296 * (17 + 33) / 33 4.994 Okay
VBatt 8 3616 * 1 3.616 Bit high for lithium?
Reference: Winbond w83697 datasheet Rev 2.0 2005-04-14
External scale inputs depend on mobo component values, and the readings
seem to indicate the datasheet recommended values were not used, so I'll
not guess them ;) Need a voltmeter.
Cheers,
Grant
ANT...@zimage.com
Oh well. No biggie. I will just undo the suggestion you gave me a few
days ago. I have been using this motherboard in Debian since summer
of 2005. :)