This was my direct answer to you, but it that was bounced, so I'll repost this to mail list. On Friday 20 July 2007 01:07, Bob S wrote: ,,,
Then, when I run sensors I get the following: ... in0: +1.53 V (min = +0.70 V, max = +1.87 V) in1: +3.23 V (min = +2.05 V, max = +1.36 V) ALARM3 in2: +0.45 V (min = +1.15 V, max = +0.29 V) ALARM in3: +3.06 V (min = +3.07 V, max = +1.22 V) ALARM in4: +3.06 V (min = +2.34 V, max = +0.00 V) ALARM in7: +3.07 V (min = +1.07 V, max = +1.30 V) ALARM in8: +3.62 V (min = +0.29 V, max = +0.14 V) ALARM fan1: 3183 RPM (min = 27000 RPM, div = 2) ALARM fan2: 5672 RPM (min = -1 RPM, div = 2) ALARM fan3: 0 RPM (min = -1 RPM, div = 2) ALARM temp1: +46°C (high = +70°C, hyst = +0°C) sensor = thermistor temp2: +33.5°C (high = +80°C, hyst = +75°C) sensor = diode temp3: -48.0°C (high = +80°C, hyst = +75°C) sensor = thermistor ... I am guessing that all of those are all raw values before conversion, Can't tell for sure which "in" represents what actual value in that readout though.
Yes, it is sensor chip readout. To tell what is connected to input, ie. to give meaning to numbers one should know motherboard schematic diagram. I don't have one so this has to be guesswork. About 3.3 V: It is nominal 3.3V +/- 5% tolerance. This means it is considered good if it is between: max 3.3V+5%=3.465V min 3.3V-5%=3.135V Here only in1 has good 3.3 value of 3.23V. Some voltage drop is normal. I got the chip datasheet that has an example schematics and VIN1 is used as 3.3V input which is not necessarily the same as applied on motherboard, but I don't think that motherboard designer spent time shuffling the inputs to get the same result. This will be properly presented if you add this to sensors.conf section chip "w83627thf-*" "w83637hf-*" label in1 +3.3V set in1_min 3.3*0.95 set in1_max 3.3*1.05 The multiplier 1.05 is for +5% and 0.95 is -5%. Of course you should remove, or comment out, any other line in that section that is influencing in1. Though I would try first to set vrm to 2.4 first.
In the regular conf file "set" determines what "in" is what. Correct here?
The "set" is used to overide hard coded (default) values of sensors binary. In above example you can see how to overide wrong (min = +2.05 V, max = +1.36 V) that is hard coded in program for vrm 9.0. BTW, vrm 9.0 is also default if you don't overide it with: set vrm 2.4 and run sensors -s as root. It may not work with openSUSE 10.2, but than it should be reported as a bug. The "label" is the one that tell us how to understand the value. It will change nothing, but printout on the screen, instead of "in1", that tells us nothing, it will show "+3,3V". ...
chip "w83627thf-*" "w83637hf-*" set vrm 2.4
OK, I read the doc several times. Actually my vrm is 9.0 In looking at my sensors.conf file I found that line and uncommented it. But when I ran sensors -s I got this: -------------------------------------------- EasyStreet:/ # sensors -s w83627thf-isa-0290: Can't access procfs/sysfs file for writing; Run as root?
It has to be root in order to access /sys directory. I hope it sensors is patched for openSUSE, if not than this will do nothing.
----------------------------------------------------------- So I went back again and re-commented that line and ran sensors-s again. No error this time, but miraculously, the VCore was correct. Go figure ??
As mentioned before: set vrm 2.4 is what you need. Than we should go and correct values if some is not good. According to lm-sensors web page changing default vrm 9.0 to one that you need should be supported in driver for your chip. ...
One step at a time for me. Want to solve that 3.3V problem. Then I will fool with the CPU temp problem. I really only want to monitor trends though, that will produce an alarm
Here is my new output from sensors: Some progress made. ----------------------------------------- EasyStreet:/ # sensors w83627thf-isa-0290 Adapter: ISA adapter VCore: +1.54 V (min = +0.70 V, max = +1.94 V)
Min and max are wrong. You CPU would missbehave and overheat with 1.6V which is much lower than 1.94V, so alarm will not come at all, as computer will freeze or reset before any alarm.
+12V: +12.28 V (min = +10.82 V, max = +13.19 V) +3.3V: +0.45 V (min = +3.14 V, max = +3.47 V) ALARM
+3.3 see above, and comment out this input also.
+5V: +5.09 V (min = +4.75 V, max = +5.25 V) V5SB: +5.13 V (min = +4.76 V, max = +5.24 V) VBat: +3.62 V (min = +2.40 V, max = +4.08 V) Sys Fan: 3169 RPM (min = 2800 RPM, div = 2) CPU Fan: 5625 RPM (min = 5487 RPM, div = 2) M/B Temp: +46°C (high = +70°C, hyst = +0°C) sensor = thermistor CPU Temp: +33.5°C (high = +80°C, hyst = +75°C) sensor = diode
....
Thanks for your patience and assistance Rajko. Bob S.
Bob, I like hardware, that is what I understand the best, and I would like to see this working properly. That means not only 3.3V, but all bits that make sensors report. Than I can go and see what is the difference between your super I/O chip and mine, w83627ehf, and dive in reading to see why vrm can't be set. It seems that hardware is built in, but it is not supported in driver. So it will be searching trough source code to find what makes the difference, and I'm not that comfortable with coding as with hardware. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org