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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
