Re: [opensuse] sensors.conf -Help !
On Sunday 15 July 2007 10:21:32 Rajko M. wrote:
On Sunday 15 July 2007 00:26, Bob S wrote:
Hello SuSE people,
Been trying to get my sensors.conf file to report accurately on my system.
.....<snipped many non-pertinent parts>....
It would be good to read http://www.lm-sensors.org/wiki/FAQ section 3. Problems. http://www.lm-sensors.org/wiki/FAQ/Chapter3
Hi Rajko, thanks for trying to help. Sorry for the delay in responding. For some unknown reason this mail has been rejected by the list twice so far. I had to create a new message which will break the threading. Grrrr !!! Anyway, Nothing in the above URL's about these problems. I really hate posting these really long mails for fear of the other members being upset, Maybe we should take this off list.
Short: Sensors will show what you set in sensors.conf, and that can be correct or out of way.
Welllll. not exactly, I made some changes today in sensors.conf and one of the changes is not being honored. To bring you up to date. Today, I just commented out the -12V parameter because the bios doesn't report it and that worked OK. But,,,,,I created a new problem when I removed the comment lines for in0, the Vcore. See that in my latest sensors printout just below: Still have the alarm problem for the 3.3V parameter. EasyStreet:/ # sensors w83627thf-isa-0290 Adapter: ISA adapter VCore: +1.54 V (min = +1.94 V, max = +1.94 V) 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 +5V: +5.09 V (min = +4.75 V, max = +5.25 V) V5SB: +5.16 V (min = +4.76 V, max = +5.24 V) VBat: +3.62 V (min = +2.40 V, max = +4.08 V) Sys Fan: 3183 RPM (min = 2800 RPM, div = 2) CPU Fan: 5672 RPM (min = 5487 RPM, div = 2) M/B Temp: +46°C (high = +86°C, hyst = +2°C) sensor = thermistor CPU Temp: +33.5°C (high = +80°C, hyst = +75°C) sensor = diode alarms: beep_enable: Sound alarm enabled EasyStreet:/ #
Write down BIOS reports and post it here.
OK,,Here is what is reported in the bios" CPU 55 degrees C Sys Tmp 45 degrees C CPU Fan 5720 rpm Sys Fan 3185 rpm Vcore =1.54V +5 =5.25V +12 =11.8V +3.3 =3.4V
Also the section of /etc/sensors.conf that is used with your sensor: chip w83627thf-*
OK, Here is sensors.conf: (Mind you I have made changes to this conf file) I uncommented and commented in0 several times and still come up with the crazy min/max levels for Vcore as shown above. chip "w83627thf-*" "w83637hf-*" # Rather than an internal inverting op amp, the 627thf uses standard positive # inputs and the negative voltages are level shifted by a 3.6V reference # (same as 82d/83s). # The math is convoluted, so we hope that your motherboard # uses the recommended resistor values. # Note that in1 (+12V) is the usual in4, and in4 (-12V) is the usual in5. # Data sheet is obviously wrong for in4, the usual formula should work. # No in5 nor in6. # sensors doesn't need the ignore lines but sensord does... ignore in4 (this removed the -12V parameter) ignore in5 ignore in6 label in0 "VCore" label in1 "+12V" label in2 "+3.3V" label in3 "+5V" # label in4 "-12V" label in7 "V5SB" label in8 "VBat" # Mori Hiroyuki reported to need this (P4P800) # compute in0 @/2, @*2 compute in1 ((28/10)+1)*@, @/((28/10)+1) compute in3 ((34/51)+1)*@, @/((34/51)+1) compute in4 (5.14*@)-14.91, (@+14.91)/5.14 compute in7 ((6.8/10)+1)*@ , @/((6.8/10)+1) # adjust this if your vid is wrong; see doc/vid # set vrm 9.0 # set limits to 5% for the critical voltages # set limits to 10% for the non-critical voltages # set limits to 20% for the battery voltage # if your vid is wrong, you'll need to adjust in0_min and in0_max # set in0_min vid * 0.95 (these two lines were uncommented which caused the new alarm problem. They were commented again and the problem remains) # set in0_max vid * 1.05 # set in1_min 12 * 0.90 # set in1_max 12 * 1.10 # set in2_min 3.3 * 0.95 # set in2_max 3.3 * 1.05 # set in3_min 5.0 * 0.95 # set in3_max 5.0 * 1.05 # set in4_min -12 * 1.10 # set in4_max -12 * 0.90 # set in7_min 5 * 0.95 # set in7_max 5 * 1.05 # set in8_min 3.0 * 0.80 # set in8_max 3.0 * 1.20 # set up sensor types (thermistor is default) # 1 = PII/Celeron Diode; 2 = 3904 transistor; # 3435 = thermistor with Beta = 3435 # If temperature changes very little, try 1 or 2. # set sensor1 1 # set sensor2 2 # set sensor3 3435 label temp1 "M/B Temp" label temp2 "CPU Temp" ignore temp3 # examples for temperature limits # set temp1_over 40 # set temp1_hyst 37 # set temp2_over 52 # set temp2_hyst 47 # set temp3_over 52 # set temp3_hyst 47 label fan1 "Sys Fan" label fan2 "CPU Fan" ignore fan3
What is your motherboard and chipset? What tells lspci -v
EasyStreet:/ # lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge Subsystem: VIA Technologies, Inc. Unknown device 3282 Flags: bus master, 66MHz, medium devsel, latency 8 Memory at d0000000 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.0 Capabilities: [50] Power Management version 2 Capabilities: [60] HyperTransport: Slave or Primary Interface Capabilities: [58] HyperTransport: Interrupt Discovery and Configuration 00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: cde00000-cfefffff Prefetchable memory behind bridge: add00000-cdcfffff Capabilities: [80] Power Management version 2 00:08.0 Ethernet controller: D-Link System Inc DGE-530T Gigabit Ethernet Adapter (rev 11) (rev 11) Subsystem: D-Link System Inc DGE-530T Gigabit Ethernet Adapter (rev 11) Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 185 Memory at cfff8000 (32-bit, non-prefetchable) [size=16K] I/O ports at d400 [size=256] Expansion ROM at cffc0000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) Subsystem: Micro-Star International Co., Ltd. K8T Neo 2 Motherboard Flags: bus master, medium devsel, latency 64, IRQ 169 I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=8] I/O ports at e000 [size=4] I/O ports at dc00 [size=16] I/O ports at d800 [size=256] Capabilities: [c0] Power Management version 2 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: Micro-Star International Co., Ltd. K8T NEO 2 motherboard Flags: bus master, medium devsel, latency 32, IRQ 169 I/O ports at fc00 [size=16] Capabilities: [c0] Power Management version 2 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd. K8T NEO 2 motherboard Flags: bus master, medium devsel, latency 64, IRQ 177 I/O ports at c400 [size=32] Capabilities: [80] Power Management version 2 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd. K8T NEO 2 motherboard Flags: bus master, medium devsel, latency 64, IRQ 177 I/O ports at c800 [size=32] Capabilities: [80] Power Management version 2 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd. K8T NEO 2 motherboard Flags: bus master, medium devsel, latency 64, IRQ 177 I/O ports at cc00 [size=32] Capabilities: [80] Power Management version 2 00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd. K8T NEO 2 motherboard Flags: bus master, medium devsel, latency 64, IRQ 177 I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd. K8T NEO 2 motherboard Flags: bus master, medium devsel, latency 64, IRQ 177 Memory at cfff7e00 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] Subsystem: VIA Technologies, Inc. DFI KT600-AL Motherboard Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) Subsystem: Micro-Star International Co., Ltd. Unknown device 7023 Flags: medium devsel, IRQ 193 I/O ports at c000 [size=256] Capabilities: [c0] Power Management version 2 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Flags: fast devsel Capabilities: [80] HyperTransport: Host or Secondary Interface 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control Flags: fast devsel 01:00.0 VGA compatible controller: nVidia Corporation NV36.2 [GeForce FX 5700] (rev a1) (prog-if 00 [VGA]) Subsystem: ASUSTeK Computer Inc. Unknown device 814f Flags: bus master, 66MHz, medium devsel, latency 248, IRQ 201 Memory at ce000000 (32-bit, non-prefetchable) [size=16M] Memory at b0000000 (32-bit, prefetchable) [size=256M] [virtual] Expansion ROM at cfee0000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 3.0 EasyStreet:/ # Thanks, Bob S. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 17 July 2007 17:01, Bob S wrote:
On Sunday 15 July 2007 10:21:32 Rajko M. wrote:
Hello SuSE people,
Been trying to get my sensors.conf file to report accurately on my system. ..... It would be good to read http://www.lm-sensors.org/wiki/FAQ
On Sunday 15 July 2007 00:26, Bob S wrote: section 3. Problems. http://www.lm-sensors.org/wiki/FAQ/Chapter3 .... Nothing in the above URL's about these problems.
.... Maybe we should take this off list.
If you want to. We can post result in this thread.
Short: Sensors will show what you set in sensors.conf, and that can be correct or out of way.
Welllll. not exactly,
What I meant is that you can do whatever math you want on raw values. You get those values if /etc/sensors.conf has only one line: chip "w83627thf-*" and than run sensors -s and than sensors Make backup copy of original. Make one copy that has only your chip section, it will be easier to edit. To create one line sensors.conf run: echo chip \"w83627thf-*\" > /etc/sensors.conf
I made some changes today in sensors.conf and one of the changes is not being honored. To bring you up to date. Today, I just commented out the -12V parameter because the bios doesn't report it and that worked OK.
BIOS might not use all values even if they are present. The previous oneliner sensors.conf will give you all values that are reported by chip.
But,,,,,I created a new problem when I removed the comment lines for in0, the Vcore. See that in my latest sensors printout just below: Still have the alarm problem for the 3.3V parameter.
EasyStreet:/ # sensors w83627thf-isa-0290 Adapter: ISA adapter VCore: +1.54 V (min = +1.94 V, max = +1.94 V) ALARM
This is Vcore, but min and max values are wrong. See /usr/share/doc/packages/sensors/vid to understand what is going on with this, and your chip driver should be able to recognize command set vrm 2.4 according to above file put that right below section title: chip "w83627thf-*" "w83637hf-*" set vrm 2.4
+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
Simply wrong input is taken as 3.3 V. From raw values listing and more reading it should be possible to find input line.
+5V: +5.09 V (min = +4.75 V, max = +5.25 V) V5SB: +5.16 V (min = +4.76 V, max = +5.24 V) VBat: +3.62 V (min = +2.40 V, max = +4.08 V) Sys Fan: 3183 RPM (min = 2800 RPM, div = 2) CPU Fan: 5672 RPM (min = 5487 RPM, div = 2) M/B Temp: +46°C (high = +86°C, hyst = +2°C) sensor = thermistor CPU Temp: +33.5°C (high = +80°C, hyst = +75°C) sensor = diode
For CPU temperature you should try other options for sensor until you get what BIOS reports. I doubt it is diode, as above report tells. ***************************************************************************** # set up sensor types (thermistor is default) # 1 = PII/Celeron Diode; 2 = 3904 transistor; # 3435 = thermistor with Beta = 3435 # If temperature changes very little, try 1 or 2. # set sensor1 1 # set sensor2 2 # set sensor3 3435 ****************************************************************************** ...
OK,,Here is what is reported in the bios"
CPU 55 degrees C Sys Tmp 45 degrees C CPU Fan 5720 rpm Sys Fan 3185 rpm Vcore =1.54V +5 =5.25V +12 =11.8V +3.3 =3.4V
Also the section of /etc/sensors.conf that is used with your sensor: chip w83627thf-*
OK, Here is sensors.conf: (Mind you I have made changes to this conf file) I uncommented and commented in0 several times and still come up with the crazy min/max levels for Vcore as shown above.
This has to wait until you see raw values.
What is your motherboard and chipset? # lspci -v .... K8T800Pro Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Micro-Star International Co., Ltd. K8T NEO 2 motherboard ...
MSI is not very verbose about hardware. Maybe if one asks, and explain details why they are needed, we can get some information. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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
On Saturday 21 July 2007 15:46, Rajko M. wrote:
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.
The command set vrm 2.4 should preceed any other that will use it, that means put it right under the section title. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 21 July 2007 17:10:07 Rajko M. wrote:
On Saturday 21 July 2007 15:46, Rajko M. wrote:
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.
The command set vrm 2.4 should preceed any other that will use it, that means put it right under the section title.
Hi Rajko. That's what I did. Very first line. Still get that message. BTW my kernel is the latest. 2.6.18.8-0.5-default #1 SMP Just sent you a private long email answering /commenting about your last message. Bob S -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (2)
-
Bob S -
Rajko M.