* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
@ 2009-09-02 13:16 ` Jean Delvare
2009-09-02 16:41 ` Karl Schmidt
` (20 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-02 13:16 UTC (permalink / raw)
To: lm-sensors
Hi Karl,
On Fri, 28 Aug 2009 13:36:18 -0500, Karl Schmidt wrote:
> I hope this isn't a stupid question -but google didn't get me there..
>
> Please cc -- I'm off list..
>
> I used to be able to get an alarm for fans - but now I don't.
>
>
> chip "lm85c-*" "adm1027-*" "adt7463-*" "lm85-*" "lm85b-*"
>
> # Voltage inputs
> # Depending on the hardware setup, the ADT7463 may not have in4.
> label in0 "V1.5" # AGP on Intel S845WD1-E
> label in1 "VCore"
> label in2 "V3.3"
> label in3 "V5"
> label in4 "V12"
>
> # Temperature inputs
> label temp1 "CPU Temp"
> label temp2 "Board Temp"
> label temp3 "Remote Temp"
>
> # Fan inputs
> label fan1 "CPU_Fan"
> label fan2 "Fan2"
> label fan3 "Fan3"
> label fan4 "Fan4"
> set fan1_min 8000
>
>
>
>
> lm85b-i2c-0-2e
> Adapter: SMBus nForce2 adapter at 1c00
> V1.5: +1.30 V (min = +0.00 V, max = +3.32 V)
> VCore: +1.42 V (min = +0.00 V, max = +2.99 V)
> V3.3: +3.35 V (min = +0.00 V, max = +4.38 V)
> V5: +5.08 V (min = +0.00 V, max = +6.64 V)
> V12: +12.06 V (min = +0.00 V, max = +15.94 V)
> CPU_Fan: 7837 RPM (min = 8000 RPM)
> Fan2: 8169 RPM (min = 0 RPM)
> Fan3: 7964 RPM (min = 0 RPM)
> Fan4: 7917 RPM (min = 0 RPM)
> CPU Temp: +37.0°C (low = -127.0°C, high = +127.0°C)
> Board Temp: +26.0°C (low = -127.0°C, high = +127.0°C)
> Remote Temp: +23.0°C (low = -127.0°C, high = +127.0°C)
>
>
> 2.6.26-2-amd64 #1 SMP
This is strange. The lack of alarms for Fan2, Fan3 and Fan4 can be
easily explained by the min being set to 0. But for CPU_Fan you should
get one.
Are you able to get _any_ other alarm flag to raise?
Which version of lm-sensors are you running?
Can you please locate your chip under /sys/class/hwmon and list the
name and contents of all the "*alarm*" files there? This will tell us
whether this is a hardware/driver issue or an lm-sensors (user-space)
issue.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
2009-09-02 13:16 ` Jean Delvare
@ 2009-09-02 16:41 ` Karl Schmidt
2009-09-02 16:49 ` Jean Delvare
` (19 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-02 16:41 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> Hi Karl,
>
> On Fri, 28 Aug 2009 13:36:18 -0500, Karl Schmidt wrote:
>> I hope this isn't a stupid question -but google didn't get me there..
>>
>> Please cc -- I'm off list..
>>
>> I used to be able to get an alarm for fans - but now I don't.
>>
>>
>> chip "lm85c-*" "adm1027-*" "adt7463-*" "lm85-*" "lm85b-*"
>>
>> # Voltage inputs
>> # Depending on the hardware setup, the ADT7463 may not have in4.
>> label in0 "V1.5" # AGP on Intel S845WD1-E
>> label in1 "VCore"
>> label in2 "V3.3"
>> label in3 "V5"
>> label in4 "V12"
>>
>> # Temperature inputs
>> label temp1 "CPU Temp"
>> label temp2 "Board Temp"
>> label temp3 "Remote Temp"
>>
>> # Fan inputs
>> label fan1 "CPU_Fan"
>> label fan2 "Fan2"
>> label fan3 "Fan3"
>> label fan4 "Fan4"
>> set fan1_min 8000
>>
>>
>>
>>
>> lm85b-i2c-0-2e
>> Adapter: SMBus nForce2 adapter at 1c00
>> V1.5: +1.30 V (min = +0.00 V, max = +3.32 V)
>> VCore: +1.42 V (min = +0.00 V, max = +2.99 V)
>> V3.3: +3.35 V (min = +0.00 V, max = +4.38 V)
>> V5: +5.08 V (min = +0.00 V, max = +6.64 V)
>> V12: +12.06 V (min = +0.00 V, max = +15.94 V)
>> CPU_Fan: 7837 RPM (min = 8000 RPM)
>> Fan2: 8169 RPM (min = 0 RPM)
>> Fan3: 7964 RPM (min = 0 RPM)
>> Fan4: 7917 RPM (min = 0 RPM)
>> CPU Temp: +37.0°C (low = -127.0°C, high = +127.0°C)
>> Board Temp: +26.0°C (low = -127.0°C, high = +127.0°C)
>> Remote Temp: +23.0°C (low = -127.0°C, high = +127.0°C)
>>
>>
>> 2.6.26-2-amd64 #1 SMP
>
> This is strange. The lack of alarms for Fan2, Fan3 and Fan4 can be
> easily explained by the min being set to 0. But for CPU_Fan you should
> get one.
>
> Are you able to get _any_ other alarm flag to raise?
>
> Which version of lm-sensors are you running?
lm-sensors Debian release 1:3.0.2-1+b2
#sensors -v
sensors version 3.0.2 with libsensors version 3.0.2)
>
> Can you please locate your chip under /sys/class/hwmon and list the
> name and contents of all the "*alarm*" files there? This will tell us
> whether this is a hardware/driver issue or an lm-sensors (user-space)
> issue.
/sys/class/hwmon - has two directories: hwmon0 and hwmon1 - no alarm files under hwmon0
/sys/class/hwmon/hwmon1/device# ls *alarm*
alarms fan2_alarm fan4_alarm in1_alarm in3_alarm temp1_alarm temp3_alarm
fan1_alarm fan3_alarm in0_alarm in2_alarm in4_alarm temp2_alarm
All return 0
/sys/class/hwmon/hwmon1# cat device/fan1_alarm
0
/sys/class/hwmon/hwmon1# cat device/fan3_alarm
0
/sys/class/hwmon/hwmon1# cat device/in0_alarm
0
etc..
/sys/class/hwmon/hwmon0# cat uevent
PHYSDEVPATH=/devices/pci0000:00/0000:00:18.3
PHYSDEVBUS=pci
/sys/class/hwmon/hwmon1# cat uevent
PHYSDEVPATH=/class/i2c-adapter/i2c-0/0-002e
PHYSDEVBUS=i2c
PHYSDEVDRIVER=lm85
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
Don't go around saying the world owes you a living.
The world owes you nothing. It was here first. -- Mark Twain
--------------------------------------------------------------------------------
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
2009-09-02 13:16 ` Jean Delvare
2009-09-02 16:41 ` Karl Schmidt
@ 2009-09-02 16:49 ` Jean Delvare
2009-09-02 17:02 ` Karl Schmidt
` (18 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-02 16:49 UTC (permalink / raw)
To: lm-sensors
On Wed, 02 Sep 2009 11:41:31 -0500, Karl Schmidt wrote:
> Jean Delvare wrote:
> > Hi Karl,
> >
> > On Fri, 28 Aug 2009 13:36:18 -0500, Karl Schmidt wrote:
> >> I hope this isn't a stupid question -but google didn't get me there..
> >>
> >> Please cc -- I'm off list..
> >>
> >> I used to be able to get an alarm for fans - but now I don't.
> >>
> >>
> >> chip "lm85c-*" "adm1027-*" "adt7463-*" "lm85-*" "lm85b-*"
> >>
> >> # Voltage inputs
> >> # Depending on the hardware setup, the ADT7463 may not have in4.
> >> label in0 "V1.5" # AGP on Intel S845WD1-E
> >> label in1 "VCore"
> >> label in2 "V3.3"
> >> label in3 "V5"
> >> label in4 "V12"
> >>
> >> # Temperature inputs
> >> label temp1 "CPU Temp"
> >> label temp2 "Board Temp"
> >> label temp3 "Remote Temp"
> >>
> >> # Fan inputs
> >> label fan1 "CPU_Fan"
> >> label fan2 "Fan2"
> >> label fan3 "Fan3"
> >> label fan4 "Fan4"
> >> set fan1_min 8000
> >>
> >>
> >>
> >>
> >> lm85b-i2c-0-2e
> >> Adapter: SMBus nForce2 adapter at 1c00
> >> V1.5: +1.30 V (min = +0.00 V, max = +3.32 V)
> >> VCore: +1.42 V (min = +0.00 V, max = +2.99 V)
> >> V3.3: +3.35 V (min = +0.00 V, max = +4.38 V)
> >> V5: +5.08 V (min = +0.00 V, max = +6.64 V)
> >> V12: +12.06 V (min = +0.00 V, max = +15.94 V)
> >> CPU_Fan: 7837 RPM (min = 8000 RPM)
> >> Fan2: 8169 RPM (min = 0 RPM)
> >> Fan3: 7964 RPM (min = 0 RPM)
> >> Fan4: 7917 RPM (min = 0 RPM)
> >> CPU Temp: +37.0°C (low = -127.0°C, high = +127.0°C)
> >> Board Temp: +26.0°C (low = -127.0°C, high = +127.0°C)
> >> Remote Temp: +23.0°C (low = -127.0°C, high = +127.0°C)
> >>
> >>
> >> 2.6.26-2-amd64 #1 SMP
> >
> > This is strange. The lack of alarms for Fan2, Fan3 and Fan4 can be
> > easily explained by the min being set to 0. But for CPU_Fan you should
> > get one.
> >
> > Are you able to get _any_ other alarm flag to raise?
Please try this too, for example set in0_max to 1.0V and see if
in0_alarm gets raised.
> >
> > Which version of lm-sensors are you running?
>
> lm-sensors Debian release 1:3.0.2-1+b2
> #sensors -v
> sensors version 3.0.2 with libsensors version 3.0.2)
> >
> > Can you please locate your chip under /sys/class/hwmon and list the
> > name and contents of all the "*alarm*" files there? This will tell us
> > whether this is a hardware/driver issue or an lm-sensors (user-space)
> > issue.
> /sys/class/hwmon - has two directories: hwmon0 and hwmon1 - no alarm files under hwmon0
>
>
> /sys/class/hwmon/hwmon1/device# ls *alarm*
> alarms fan2_alarm fan4_alarm in1_alarm in3_alarm temp1_alarm temp3_alarm
> fan1_alarm fan3_alarm in0_alarm in2_alarm in4_alarm temp2_alarm
>
> All return 0
>
> /sys/class/hwmon/hwmon1# cat device/fan1_alarm
> 0
> /sys/class/hwmon/hwmon1# cat device/fan3_alarm
> 0
> /sys/class/hwmon/hwmon1# cat device/in0_alarm
> 0
> etc..
Does "alarms" read 0 as well?
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (2 preceding siblings ...)
2009-09-02 16:49 ` Jean Delvare
@ 2009-09-02 17:02 ` Karl Schmidt
2009-09-02 17:12 ` Mark E. Hansen
` (17 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-02 17:02 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> On Wed, 02 Sep 2009 11:41:31 -0500, Karl Schmidt wrote:
>> Jean Delvare wrote:
>>> Hi Karl,
>>>
>>> On Fri, 28 Aug 2009 13:36:18 -0500, Karl Schmidt wrote:
>>>> I hope this isn't a stupid question -but google didn't get me there..
>>>>
>>>> Please cc -- I'm off list..
>>>>
>>>> I used to be able to get an alarm for fans - but now I don't.
>>>>
>>>>
>>>> chip "lm85c-*" "adm1027-*" "adt7463-*" "lm85-*" "lm85b-*"
>>>>
>>>> # Voltage inputs
>>>> # Depending on the hardware setup, the ADT7463 may not have in4.
>>>> label in0 "V1.5" # AGP on Intel S845WD1-E
>>>> label in1 "VCore"
>>>> label in2 "V3.3"
>>>> label in3 "V5"
>>>> label in4 "V12"
>>>>
>>>> # Temperature inputs
>>>> label temp1 "CPU Temp"
>>>> label temp2 "Board Temp"
>>>> label temp3 "Remote Temp"
>>>>
>>>> # Fan inputs
>>>> label fan1 "CPU_Fan"
>>>> label fan2 "Fan2"
>>>> label fan3 "Fan3"
>>>> label fan4 "Fan4"
>>>> set fan1_min 8000
>>>>
>>>>
>>>>
>>>>
>>>> lm85b-i2c-0-2e
>>>> Adapter: SMBus nForce2 adapter at 1c00
>>>> V1.5: +1.30 V (min = +0.00 V, max = +3.32 V)
>>>> VCore: +1.42 V (min = +0.00 V, max = +2.99 V)
>>>> V3.3: +3.35 V (min = +0.00 V, max = +4.38 V)
>>>> V5: +5.08 V (min = +0.00 V, max = +6.64 V)
>>>> V12: +12.06 V (min = +0.00 V, max = +15.94 V)
>>>> CPU_Fan: 7837 RPM (min = 8000 RPM)
>>>> Fan2: 8169 RPM (min = 0 RPM)
>>>> Fan3: 7964 RPM (min = 0 RPM)
>>>> Fan4: 7917 RPM (min = 0 RPM)
>>>> CPU Temp: +37.0°C (low = -127.0°C, high = +127.0°C)
>>>> Board Temp: +26.0°C (low = -127.0°C, high = +127.0°C)
>>>> Remote Temp: +23.0°C (low = -127.0°C, high = +127.0°C)
>>>>
>>>>
>>>> 2.6.26-2-amd64 #1 SMP
>>> This is strange. The lack of alarms for Fan2, Fan3 and Fan4 can be
>>> easily explained by the min being set to 0. But for CPU_Fan you should
>>> get one.
>>>
>>> Are you able to get _any_ other alarm flag to raise?
>
> Please try this too, for example set in0_max to 1.0V and see if
> in0_alarm gets raised.
no joy..
#sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp: +24.0°C
lm85b-i2c-0-2e
Adapter: SMBus nForce2 adapter at 1c00
V1.5: +1.30 V (min = +0.00 V, max = +1.00 V)
VCore: +1.42 V (min = +0.00 V, max = +2.99 V)
V3.3: +3.33 V (min = +0.00 V, max = +4.38 V)
V5: +5.08 V (min = +0.00 V, max = +6.64 V)
V12: +12.06 V (min = +0.00 V, max = +15.94 V)
CPU_Fan: 7826 RPM (min = 8000 RPM)
Fan2: 8181 RPM (min = 0 RPM)
Fan3: 7917 RPM (min = 0 RPM)
Fan4: 7929 RPM (min = 0 RPM)
CPU Temp: +39.0°C (low = -127.0°C, high = +127.0°C)
Board Temp: +28.0°C (low = -127.0°C, high = +127.0°C)
Remote Temp: +24.0°C (low = -127.0°C, high = +127.0°C)
cpu0_vid: +1.550 V
>
>>> Which version of lm-sensors are you running?
>> lm-sensors Debian release 1:3.0.2-1+b2
>> #sensors -v
>> sensors version 3.0.2 with libsensors version 3.0.2)
>> >
>> > Can you please locate your chip under /sys/class/hwmon and list the
>> > name and contents of all the "*alarm*" files there? This will tell us
>> > whether this is a hardware/driver issue or an lm-sensors (user-space)
>> > issue.
>> /sys/class/hwmon - has two directories: hwmon0 and hwmon1 - no alarm files under hwmon0
>>
>>
>> /sys/class/hwmon/hwmon1/device# ls *alarm*
>> alarms fan2_alarm fan4_alarm in1_alarm in3_alarm temp1_alarm temp3_alarm
>> fan1_alarm fan3_alarm in0_alarm in2_alarm in4_alarm temp2_alarm
>>
>> All return 0
>>
>> /sys/class/hwmon/hwmon1# cat device/fan1_alarm
>> 0
>> /sys/class/hwmon/hwmon1# cat device/fan3_alarm
>> 0
>> /sys/class/hwmon/hwmon1# cat device/in0_alarm
>> 0
>> etc..
>
> Does "alarms" read 0 as well?
yes - all alarms files read zero
/sys/class/hwmon/hwmon1/device# cat alarms
0
>
--
!!!>> INCLUDE ALL TEXT IN TECHNICAL SUPPORT EMAIL REPLIES!!!!!!!
Please reply in plain-text mode
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
Misdirection is the key to being a good magician. Magicians tell
you they are doing something while they do something quite
different; much like politicians -- except we can afford magicians.
-KPS
--------------------------------------------------------------------------------
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (3 preceding siblings ...)
2009-09-02 17:02 ` Karl Schmidt
@ 2009-09-02 17:12 ` Mark E. Hansen
2009-09-02 19:06 ` Jean Delvare
` (16 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Mark E. Hansen @ 2009-09-02 17:12 UTC (permalink / raw)
To: lm-sensors
Just in case it's of any help, when I tried to upgrade to this
version of lm-sensors on my CentOS 5.4 Linux machine, I had the
same problem - the sensors appeared to report good values, but
no alarms at all.
I did ask here, but never got any response :-(, so I'm interested
in the final solution as well.
Thanks,
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (4 preceding siblings ...)
2009-09-02 17:12 ` Mark E. Hansen
@ 2009-09-02 19:06 ` Jean Delvare
2009-09-04 15:17 ` Jean Delvare
` (15 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-02 19:06 UTC (permalink / raw)
To: lm-sensors
Hi Karl,
On Wed, 02 Sep 2009 12:02:47 -0500, Karl Schmidt wrote:
> Jean Delvare wrote:
> > Please try this too, for example set in0_max to 1.0V and see if
> > in0_alarm gets raised.
>
> no joy..
> #sensors
> k8temp-pci-00c3
> Adapter: PCI adapter
> Core0 Temp: +24.0°C
>
> lm85b-i2c-0-2e
> Adapter: SMBus nForce2 adapter at 1c00
> V1.5: +1.30 V (min = +0.00 V, max = +1.00 V)
> VCore: +1.42 V (min = +0.00 V, max = +2.99 V)
> V3.3: +3.33 V (min = +0.00 V, max = +4.38 V)
> V5: +5.08 V (min = +0.00 V, max = +6.64 V)
> V12: +12.06 V (min = +0.00 V, max = +15.94 V)
> CPU_Fan: 7826 RPM (min = 8000 RPM)
> Fan2: 8181 RPM (min = 0 RPM)
> Fan3: 7917 RPM (min = 0 RPM)
> Fan4: 7929 RPM (min = 0 RPM)
> CPU Temp: +39.0°C (low = -127.0°C, high = +127.0°C)
> Board Temp: +28.0°C (low = -127.0°C, high = +127.0°C)
> Remote Temp: +24.0°C (low = -127.0°C, high = +127.0°C)
> cpu0_vid: +1.550 V
> > (...)
> > Does "alarms" read 0 as well?
>
> yes - all alarms files read zero
> /sys/class/hwmon/hwmon1/device# cat alarms
> 0
OK, this rules out a user-space issue. The problem must be either at
the hardware level or in the lm85 driver.
Please unload the lm85 driver temporarily, load the i2c-dev driver, and
provide the output of the following command:
i2cdump 0 0x2e
This will dump all the device registers. I will then check against the
datasheet and see if I spot anything.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (5 preceding siblings ...)
2009-09-02 19:06 ` Jean Delvare
@ 2009-09-04 15:17 ` Jean Delvare
2009-09-04 21:40 ` Karl Schmidt
` (14 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-04 15:17 UTC (permalink / raw)
To: lm-sensors
Hi Karl,
Please keep the list Cc'd.
On Thu, 03 Sep 2009 23:05:38 -0500, Karl Schmidt wrote:
> Jean Delvare wrote:
>
> >
> > This will dump all the device registers. I will then check against the
> > datasheet and see if I spot anything.
>
> I don't think this is a hardware problem - the readings make sense - where is it that the levels are
> compared to the set statements? This used to work on this computer until there was an upgrade to --
> I think version 3... Unless they are ignoring the set statements - thinking the chip will generate
> all alarms?
Alarms are computed by the chips in hardware. "sensors" merely reports
what the driver tells it to, and the driver in turn merely reports the
hardware state.
>
> I have a different machine - different sensors - same version of software and it works.
>
> I was trying things and listed out the working modules - if that might help:
>
> lsmod |grep dme
> dme1737 43168 0
> hwmon_vid 7296 2 dme1737,lm85
> i2c_core 27936 4 dme1737,eeprom,lm85,i2c_nforce2
>
> I tired loading different permutations of the modules - nothing seems to work.
>
>
> I tried purging the lm-sensors package and reinstalling... no joy?????
It is interesting that you have two full-featured hardware monitoring
chips in your system. I'm rather surprised, I admit.
I'll look at the dump you sent when I have a moment, but I have a lot
of work these days, so please be patient.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (6 preceding siblings ...)
2009-09-04 15:17 ` Jean Delvare
@ 2009-09-04 21:40 ` Karl Schmidt
2009-09-05 12:23 ` Jean Delvare
` (13 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-04 21:40 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> Hi Karl,
>
>
> Alarms are computed by the chips in hardware. "sensors" merely reports
> what the driver tells it to, and the driver in turn merely reports the
> hardware state.
Let me make sure I have this correct - lm-sensor would then have to put a value
into a register in the hardware-sensor-chip and then the chip creates the alarm?
> It is interesting that you have two full-featured hardware monitoring
> chips in your system. I'm rather surprised, I admit.
I'm wondering if it is really just one chip - I tried commenting out one at a time to see if somehow
appearing twice was the problem. I think it may be a host image due to incomplete hard ware encoding.
This is a Tyan S2865
In case there is something being misidentified I have the spec sheet link here:
ftp://ftp.tyan.com/datasheets/d_s2865_100.pdf
The lm-config from tyan has:
#To your etc/modules.conf file, add the lines:
# alias char-major-89 i2c-dev
#
# To your /etc/rc.xxx files, add the lines:
# modprobe i2c-nforce2
# modprobe lm85 force_emc6d100=0,0x2e
# sensors -s #
# Edited by: Raphael Deng <raphaeld@tyan.com> 03.28.05
#
# As LM-Sensors not support the SMSC DME1737 Chip, I use the SMSC
# EMC6D100 chip to instead of it and the sensor 3.3V StandBy and
# Battery Volt cannot be monitored.
They then use
chip "emc6d100-*"
But this was from 2005.. I don't think it is right for todays version??
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
I can live for two months on a good compliment. -- Mark Twain
--------------------------------------------------------------------------------
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (7 preceding siblings ...)
2009-09-04 21:40 ` Karl Schmidt
@ 2009-09-05 12:23 ` Jean Delvare
2009-09-05 19:07 ` Karl Schmidt
` (12 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-05 12:23 UTC (permalink / raw)
To: lm-sensors
Hi Karl,
On Fri, 04 Sep 2009 16:40:13 -0500, Karl Schmidt wrote:
> Jean Delvare wrote:
> > Hi Karl,
> >
> >
> > Alarms are computed by the chips in hardware. "sensors" merely reports
> > what the driver tells it to, and the driver in turn merely reports the
> > hardware state.
>
> Let me make sure I have this correct - lm-sensor would then have to put a value
> into a register in the hardware-sensor-chip and then the chip creates the alarm?
Yes, this is the idea. The chip's limits are programmed using "set"
statements in /etc/sensors3.conf, which are written to the chip using
"sensors -s". After that, the comparisons and alarm raising is done by
the chip itself.
> > It is interesting that you have two full-featured hardware monitoring
> > chips in your system. I'm rather surprised, I admit.
>
> I'm wondering if it is really just one chip - I tried commenting out one at a time to see if somehow
> appearing twice was the problem. I think it may be a host image due to incomplete hard ware encoding.
>
>
> This is a Tyan S2865
>
> In case there is something being misidentified I have the spec sheet link here:
>
> ftp://ftp.tyan.com/datasheets/d_s2865_100.pdf
>
>
> The lm-config from tyan has:
>
> #To your etc/modules.conf file, add the lines:
> # alias char-major-89 i2c-dev
> #
> # To your /etc/rc.xxx files, add the lines:
> # modprobe i2c-nforce2
> # modprobe lm85 force_emc6d100=0,0x2e
> # sensors -s #
> # Edited by: Raphael Deng <raphaeld@tyan.com> 03.28.05
> #
> # As LM-Sensors not support the SMSC DME1737 Chip, I use the SMSC
> # EMC6D100 chip to instead of it and the sensor 3.3V StandBy and
> # Battery Volt cannot be monitored.
>
> They then use
> chip "emc6d100-*"
>
> But this was from 2005.. I don't think it is right for todays version??
Correct, we now do have support for the DME1737, which is definitely
present on that board.
I pretty much doubt, OTOH, that the board also has an LM85 chip. The
configuration file provided by Tyan themselves doesn't mention it, nor
does the datasheet. And the almost identical readings between both
chips make me believe this is actually the same chip. So apparently
Tyan wired the same chip on the 2 SMBus channels, which isn't exactly
smart.
Now, one thing I would like to understand is how the lm85 driver was
loaded in the first place. In the dump you sent, the chip is clearly
identified as an SMSC chip, with the device ID of the DME1737. So, if
the lm85 driver identifies this chip as a different device, it must
have been told to, by the means of a module parameter.
Please provide the output of:
modprobe -c | grep lm85
I bet you have a force_lm85b module parameter there. If so, please
remove it.
I would also be curious to see the full output sensors-detect after
unloading both the lm85 and the dme1737 drivers.
If I am correct then you should add "options dme1737 ignore=1,0x2e"
to /etc/modprobe.conf or some such. Then do not load the lm85 driver,
only the dme1737 driver, and then you should have a single chip showing
up in the output of "sensors" (except for k8temp of course) and things
should be somewhat clearer. Only then we can go on with the missing
alarms problem, if it is still present.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (8 preceding siblings ...)
2009-09-05 12:23 ` Jean Delvare
@ 2009-09-05 19:07 ` Karl Schmidt
2009-09-05 19:16 ` Karl Schmidt
` (11 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-05 19:07 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 7453 bytes --]
Jean Delvare wrote:
> Hi Karl,
>
> On Fri, 04 Sep 2009 16:40:13 -0500, Karl Schmidt wrote:
>> Jean Delvare wrote:
>>> Hi Karl,
>>>
>>>
>>> Alarms are computed by the chips in hardware. "sensors" merely reports
>>> what the driver tells it to, and the driver in turn merely reports the
>>> hardware state.
>> Let me make sure I have this correct - lm-sensor would then have to put a value
>> into a register in the hardware-sensor-chip and then the chip creates the alarm?
>
> Yes, this is the idea. The chip's limits are programmed using "set"
> statements in /etc/sensors3.conf, which are written to the chip using
> "sensors -s". After that, the comparisons and alarm raising is done by
> the chip itself.
>
>>> It is interesting that you have two full-featured hardware monitoring
>>> chips in your system. I'm rather surprised, I admit.
>> I'm wondering if it is really just one chip - I tried commenting out one at a time to see if somehow
>> appearing twice was the problem. I think it may be a host image due to incomplete hard ware encoding.
>>
>>
>> This is a Tyan S2865
>>
>> In case there is something being misidentified I have the spec sheet link here:
>>
>> ftp://ftp.tyan.com/datasheets/d_s2865_100.pdf
>>
>>
>> The lm-config from tyan has:
>>
>> #To your etc/modules.conf file, add the lines:
>> # alias char-major-89 i2c-dev
>> #
>> # To your /etc/rc.xxx files, add the lines:
>> # modprobe i2c-nforce2
>> # modprobe lm85 force_emc6d100=0,0x2e
>> # sensors -s #
>> # Edited by: Raphael Deng <raphaeld@tyan.com> 03.28.05
>> #
>> # As LM-Sensors not support the SMSC DME1737 Chip, I use the SMSC
>> # EMC6D100 chip to instead of it and the sensor 3.3V StandBy and
>> # Battery Volt cannot be monitored.
>>
>> They then use
>> chip "emc6d100-*"
>>
>> But this was from 2005.. I don't think it is right for todays version??
>
> Correct, we now do have support for the DME1737, which is definitely
> present on that board.
>
> I pretty much doubt, OTOH, that the board also has an LM85 chip. The
> configuration file provided by Tyan themselves doesn't mention it, nor
> does the datasheet. And the almost identical readings between both
> chips make me believe this is actually the same chip. So apparently
> Tyan wired the same chip on the 2 SMBus channels, which isn't exactly
> smart.
>
> Now, one thing I would like to understand is how the lm85 driver was
> loaded in the first place. In the dump you sent, the chip is clearly
> identified as an SMSC chip, with the device ID of the DME1737. So, if
> the lm85 driver identifies this chip as a different device, it must
> have been told to, by the means of a module parameter.
>
> Please provide the output of:
>
> modprobe -c | grep lm85
# modprobe -c|grep lm85
[returns nothing ]
#lsmod |grep lm85
lm85 35492 0
hwmon_vid 7296 2 lm85,dme1737
i2c_core 27936 4 i2c_nforce2,lm85,dme1737,i2c_dev
- ah but looking at /et/modules I have:
---------------------------------
# Generated by sensors-detect on Tue Mar 13 22:13:10 2007
# I2C adapter drivers
i2c-nforce2
# Chip drivers
#make it look like lm85b
lm85 force_lm85b=0,0x2e
#lm85
eeprom
k8temp
# Warning: the required module k8temp is not currently installed
# on your system. For status of 2.6 kernel ports check
# http://www.lm-sensors.org/wiki/Devices. If driver is built
# into the kernel, or unavailable, comment out the following line.
#k8temp
# Generated by sensors-detect on Fri Aug 28 12:15:00 2009
# I2C adapter drivers
i2c-nforce2
------------------
>
> I bet you have a force_lm85b module parameter there. If so, please
> remove it.
You are correct! Removed it - /etc/modules (modules to load at boot time) now reads:
options dme1737 ignore=1,0x2e
# Generated by sensors-detect on Sat Sep 5 12:51:21 2009
# I2C adapter drivers
i2c-nforce2
# Chip drivers
dme1737
k8temp
?? It is still seeing that chip both times.
dme1737-i2c-0-2e
Adapter: SMBus nForce2 adapter at 1c00
<sinp>
dme1737-i2c-0-2e
Adapter: SMBus nForce2 adapter at 1c00
I rmmod dme1737 - and then
modprobe dme1737 option ignore=1,0x2e
failed to work -
but
modprobe dme1737 ignore=1,0x2e
OK - it now sees just one chip - but alarms still won't work - I think the keyword 'option'
shouldn't be used in /etc/modules - confirmed with a reboot.
> #sensors
> k8temp-pci-00c3
> Adapter: PCI adapter
> temp1: +20.0°C
>
> dme1737-i2c-0-2e
> Adapter: SMBus nForce2 adapter at 1c00
> in0: +2.61 V (min = +0.00 V, max = +2.00 V)
> in1: +1.43 V (min = +0.00 V, max = +2.99 V)
> in2: +3.35 V (min = +0.00 V, max = +4.38 V)
> in3: +5.10 V (min = +0.00 V, max = +6.64 V)
> in4: +12.09 V (min = +0.00 V, max = +15.94 V)
> in5: +3.30 V (min = +0.00 V, max = +4.38 V)
> in6: +3.00 V (min = +0.00 V, max = +4.38 V)
> fan1: 7826 RPM (min = 8000 RPM)
> fan2: 8157 RPM (min = 9000 RPM)
> fan3: 7917 RPM (min = 0 RPM)
> fan4: 7929 RPM (min = 0 RPM)
> temp1: +37.1°C (low = -127.0°C, high = +127.0°C)
> temp2: +26.8°C (low = -127.0°C, high = +127.0°C)
> temp3: +23.4°C (low = -127.0°C, high = +127.0°C)
> cpu0_vid: +1.550 V
Is it ignoring the wrong one??
More digging <time passes >
There is this ,.,.
# modinfo dme1737
filename: /lib/modules/2.6.26-2-amd64/kernel/drivers/hwmon/dme1737.ko
license: GPL
description: DME1737 sensors
author: Juerg Haefliger <juergh@gmail.com>
depends: i2c-core,hwmon-vid
vermagic: 2.6.26-2-amd64 SMP mod_unload modversions
parm: force_start:Force the chip to start monitoring inputs (bool)
parm: force_id:Override the detected device ID (ushort)
parm: force:List of adapter,address pairs to boldly assume to be present (array of short)
parm: force_dme1737:List of adapter,address pairs which are unquestionably assumed to
contain a `dme1737' chip (array of short)
parm: probe:List of adapter,address pairs to scan additionally (array of short)
parm: ignore:List of adapter,address pairs not to scan (array of short)
>
> I would also be curious to see the full output sensors-detect after
> unloading both the lm85 and the dme1737 drivers.
See attached
>
> If I am correct then you should add "options dme1737 ignore=1,0x2e"
> to /etc/modprobe.conf or some such. Then do not load the lm85 driver,
> only the dme1737 driver, and then you should have a single chip showing
> up in the output of "sensors" (except for k8temp of course) and things
> should be somewhat clearer. Only then we can go on with the missing
> alarms problem, if it is still present.'
I figure you will need a new listing of this:
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
Man is the only animal that blushes - or needs to. -- Mark Twain
--------------------------------------------------------------------------------
[-- Attachment #2: sensors-detect.txt --]
[-- Type: text/plain, Size: 5603 bytes --]
# sensors-detect revision 5249 (2008-05-11 22:56:25 +0200)
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. 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.
Do you want to probe now? (YES/no): Probing for PCI bus adapters...
Use driver `i2c-nforce2' for device 0000:00:01.1: nVidia Corporation nForce4 SMBus (MCP)
We will now try to load each adapter module in turn.
Module `i2c-nforce2' already loaded.
If you have undetectable or unsupported I2C/SMBus adapters, you can have
them scanned by manually loading the modules before running this script.
We are now going to do the I2C/SMBus adapter probings. Some chips may
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.
Next adapter: SMBus nForce2 adapter at 1c00 (i2c-0)
Do you want to scan it? (YES/no/selectively): Client found at address 0x2e
Handled by driver `dme1737' (already loaded), chip type `dme1737'
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Next adapter: SMBus nForce2 adapter at 1c40 (i2c-1)
Do you want to scan it? (YES/no/selectively): Client found at address 0x2e
Handled by driver `dme1737' (already loaded), chip type `dme1737'
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no): Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM78-J' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... No
Trying family `ITE'... No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'... No
Trying family `SMSC'... Yes
Found `SMSC DME1737 Super IO'
(hardware monitoring capabilities accessible via SMBus only)
Some south bridges, CPUs or memory controllers may also contain
embedded sensors. Do you want to scan for them? (YES/no): Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... Success!
(driver `k8temp')
AMD K10 thermal sensors... No
Intel Core family thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `dme1737' (should be inserted):
Detects correctly:
* Bus `SMBus nForce2 adapter at 1c00'
Busdriver `i2c-nforce2', I2C address 0x2e
Chip `dme1737' (confidence: 6)
* Bus `SMBus nForce2 adapter at 1c40'
Busdriver `i2c-nforce2', I2C address 0x2e
Chip `dme1737' (confidence: 6)
Driver `k8temp' (should be inserted):
Detects correctly:
* Chip `AMD K8 thermal sensors' (confidence: 9)
I will now generate the commands needed to load the required modules.
Just press ENTER to continue:
To load everything that is needed, add this to /etc/modules:
#----cut here----
# I2C adapter drivers
i2c-nforce2
# Chip drivers
dme1737
k8temp
#----cut here----
Do you want to add these lines automatically? (yes/NO)
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (9 preceding siblings ...)
2009-09-05 19:07 ` Karl Schmidt
@ 2009-09-05 19:16 ` Karl Schmidt
2009-09-05 21:04 ` Jean Delvare
` (10 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-05 19:16 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
>> This is a Tyan S2865
I figured you would want a new listing of this:
> #i2cdump 1 0x2e
> No size specified (using byte-data access)
> Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or directory
oops?? Not what I expected.
When this is all over - I will document it up and have a sensors3.conf file to share. Is there a web
site for sharing these? (I will also send a copy to Tyan).
Really appreciate your help. Let me know if you need anything -
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
Man is the only animal that blushes - or needs to. -- Mark Twain
--------------------------------------------------------------------------------
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (10 preceding siblings ...)
2009-09-05 19:16 ` Karl Schmidt
@ 2009-09-05 21:04 ` Jean Delvare
2009-09-05 21:10 ` Jean Delvare
` (9 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-05 21:04 UTC (permalink / raw)
To: lm-sensors
On Sat, 05 Sep 2009 14:16:15 -0500, Karl Schmidt wrote:
> Jean Delvare wrote:
> >> This is a Tyan S2865
>
>
> I figured you would want a new listing of this:
>
>
> > #i2cdump 1 0x2e
> > No size specified (using byte-data access)
> > Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or directory
>
>
>
> oops?? Not what I expected.
You forgot: modprobe i2c-dev.
> When this is all over - I will document it up and have a sensors3.conf file to share. Is there a web
> site for sharing these? (I will also send a copy to Tyan).
We have a section in the wiki:
http://www.lm-sensors.org/wiki/Configurations
If you post your config on the list, we can add it there. Or if you
intend to contribute more, we can even create a wiki account for you.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (11 preceding siblings ...)
2009-09-05 21:04 ` Jean Delvare
@ 2009-09-05 21:10 ` Jean Delvare
2009-09-05 22:03 ` Karl Schmidt
` (8 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-05 21:10 UTC (permalink / raw)
To: lm-sensors
Hi Karl,
On Sat, 05 Sep 2009 14:07:49 -0500, Karl Schmidt wrote:
> Jean Delvare wrote:
> > Now, one thing I would like to understand is how the lm85 driver was
> > loaded in the first place. In the dump you sent, the chip is clearly
> > identified as an SMSC chip, with the device ID of the DME1737. So, if
> > the lm85 driver identifies this chip as a different device, it must
> > have been told to, by the means of a module parameter.
> >
> > Please provide the output of:
> >
> > modprobe -c | grep lm85
>
> # modprobe -c|grep lm85
>
> [returns nothing ]
>
> #lsmod |grep lm85
> lm85 35492 0
> hwmon_vid 7296 2 lm85,dme1737
> i2c_core 27936 4 i2c_nforce2,lm85,dme1737,i2c_dev
>
>
> - ah but looking at /et/modules I have:
> ---------------------------------
> # Generated by sensors-detect on Tue Mar 13 22:13:10 2007
> # I2C adapter drivers
> i2c-nforce2
> # Chip drivers
>
> #make it look like lm85b
> lm85 force_lm85b=0,0x2e
> #lm85
> eeprom
> k8temp
> # Warning: the required module k8temp is not currently installed
> # on your system. For status of 2.6 kernel ports check
> # http://www.lm-sensors.org/wiki/Devices. If driver is built
> # into the kernel, or unavailable, comment out the following line.
> #k8temp
>
> # Generated by sensors-detect on Fri Aug 28 12:15:00 2009
> # I2C adapter drivers
> i2c-nforce2
> ------------------
>
> >
> > I bet you have a force_lm85b module parameter there. If so, please
> > remove it.
> You are correct! Removed it - /etc/modules (modules to load at boot time) now reads:
>
>
> options dme1737 ignore=1,0x2e
> # Generated by sensors-detect on Sat Sep 5 12:51:21 2009
> # I2C adapter drivers
> i2c-nforce2
> # Chip drivers
> dme1737
> k8temp
>
> ?? It is still seeing that chip both times.
>
> dme1737-i2c-0-2e
> Adapter: SMBus nForce2 adapter at 1c00
> <sinp>
> dme1737-i2c-0-2e
> Adapter: SMBus nForce2 adapter at 1c00
Please double-check. I don't even see how this is technically possible.
The second entry would have a different address (1-2e), and live on an
adapter with a different address too. Not that it really matters...
>
> I rmmod dme1737 - and then
> modprobe dme1737 option ignore=1,0x2e
>
> failed to work -
As expected, this isn't a valid modprobe command.
>
> but
> modprobe dme1737 ignore=1,0x2e
>
> OK - it now sees just one chip - but alarms still won't work - I think the keyword 'option'
> shouldn't be used in /etc/modules - confirmed with a reboot.
>
> > #sensors
> > k8temp-pci-00c3
> > Adapter: PCI adapter
> > temp1: +20.0°C
> >
> > dme1737-i2c-0-2e
> > Adapter: SMBus nForce2 adapter at 1c00
> > in0: +2.61 V (min = +0.00 V, max = +2.00 V)
> > in1: +1.43 V (min = +0.00 V, max = +2.99 V)
> > in2: +3.35 V (min = +0.00 V, max = +4.38 V)
> > in3: +5.10 V (min = +0.00 V, max = +6.64 V)
> > in4: +12.09 V (min = +0.00 V, max = +15.94 V)
> > in5: +3.30 V (min = +0.00 V, max = +4.38 V)
> > in6: +3.00 V (min = +0.00 V, max = +4.38 V)
> > fan1: 7826 RPM (min = 8000 RPM)
> > fan2: 8157 RPM (min = 9000 RPM)
> > fan3: 7917 RPM (min = 0 RPM)
> > fan4: 7929 RPM (min = 0 RPM)
> > temp1: +37.1°C (low = -127.0°C, high = +127.0°C)
> > temp2: +26.8°C (low = -127.0°C, high = +127.0°C)
> > temp3: +23.4°C (low = -127.0°C, high = +127.0°C)
> > cpu0_vid: +1.550 V
>
> Is it ignoring the wrong one??
I doubt there is a "right one" and a "wrong one".
Tomorrow I'll look at the DME1737 datasheet and compare with the i2c
dump. I'm not too familiar with this chip, maybe the alarms can be
disabled somehow. Juerg, does it ring a bell?
> > I would also be curious to see the full output sensors-detect after
> > unloading both the lm85 and the dme1737 drivers.
>
> See attached
You forgot to rmmod dme1737 beforehand, which makes the output
uninteresting.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (12 preceding siblings ...)
2009-09-05 21:10 ` Jean Delvare
@ 2009-09-05 22:03 ` Karl Schmidt
2009-09-05 22:13 ` Karl Schmidt
` (7 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-05 22:03 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> On Sat, 05 Sep 2009 14:16:15 -0500, Karl Schmidt wrote:
>> Jean Delvare wrote:
>>>> This is a Tyan S2865
>>
>> I figured you would want a new listing of this:
>>
>>
>>> #i2cdump 1 0x2e
>>> No size specified (using byte-data access)
>>> Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or directory
>>
>>
>> oops?? Not what I expected.
>
> You forgot: modprobe i2c-dev.i2cdump 1 0x2e
OK -
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x2e, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ................
20: 64 79 c3 c3 c1 24 1a 17 b2 02 95 02 aa 02 ab 02 dy???$??????????
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5c 89 ..............\?
40: 05 00 00 00 00 4d 00 ff 00 ff 00 ff 00 ff 81 7f ?....M........??
50: 81 7f 81 7f a3 02 58 02 ff ff ff ff 02 02 02 a7 ??????X?....????
60: a7 a7 e0 00 00 00 00 2d 2d 2d 64 64 64 44 40 00 ???....---dddD@.
70: 00 00 00 09 09 09 09 09 09 00 30 00 40 00 00 1c ...??????.0.@..?
80: 00 a4 00 00 44 2a 86 c3 0d 00 4d 4d 0b 0b 0c 00 .?..D*???.MM???.
90: cc cc cc cc 0c 0c 0c 5a f1 c0 ae 00 ff 00 ff 00 ???????Z???.....
a0: 00 00 0c 00 00 00 00 0b 0b fe ff fe ff ff ff ff ..?....???.?....
b0: ff 00 00 00 00 00 28 28 0e 0e 2b 2b 00 00 00 00 ......((??++....
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
If everything seems to be going well,
I've obviously overlooked something.
--------------------------------------------------------------------------------
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (13 preceding siblings ...)
2009-09-05 22:03 ` Karl Schmidt
@ 2009-09-05 22:13 ` Karl Schmidt
2009-09-06 7:46 ` Jean Delvare
` (6 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-05 22:13 UTC (permalink / raw)
To: lm-sensors
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
Jean Delvare wrote:
>
> You forgot to rmmod dme1737 beforehand, which makes the output
> uninteresting.
once again attached
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
Golf: A good walk spoiled -- Mark Twain
--------------------------------------------------------------------------------
[-- Attachment #2: sensors-detect2.txt --]
[-- Type: text/plain, Size: 12049 bytes --]
# sensors-detect revision 5249 (2008-05-11 22:56:25 +0200)
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. 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.
Do you want to probe now? (YES/no): Probing for PCI bus adapters...
Use driver `i2c-nforce2' for device 0000:00:01.1: nVidia Corporation nForce4 SMBus (MCP)
We will now try to load each adapter module in turn.
Load `i2c-nforce2' (say NO if built into your kernel)? (YES/no): Module loaded successfully.
If you have undetectable or unsupported I2C/SMBus 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.
Do you want to load `i2c-dev' now? (YES/no): Module loaded successfully.
We are now going to do the I2C/SMBus adapter probings. Some chips may
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.
Next adapter: SMBus nForce2 adapter at 1c00 (i2c-0)
Do you want to scan it? (YES/no/selectively): Client found at address 0x2e
Probing for `Myson MTP008'... No
Probing for `National Semiconductor LM78'... No
Probing for `National Semiconductor LM78-J'... No
Probing for `National Semiconductor LM79'... No
Probing for `National Semiconductor LM80'... No
Probing for `National Semiconductor LM85 or LM96000'... No
Probing for `Analog Devices ADM1027, ADT7460 or ADT7463'... No
Probing for `SMSC EMC6D100, EMC6D101 or EMC6D102'... No
Probing for `Analog Devices ADT7462'... No
Probing for `Analog Devices ADT7467 or ADT7468'... No
Probing for `Analog Devices ADT7470'... No
Probing for `Analog Devices ADT7473'... No
Probing for `Analog Devices ADT7475'... No
Probing for `Analog Devices ADT7476'... No
Probing for `Andigilog aSC7611'... No
Probing for `Andigilog aSC7621'... No
Probing for `National Semiconductor LM87'... No
Probing for `National Semiconductor LM93'... No
Probing for `Winbond W83781D'... No
Probing for `Winbond W83782D'... No
Probing for `Winbond W83792D'... No
Probing for `Winbond W83793R/G'... No
Probing for `Winbond W83791SD'... No
Probing for `Winbond W83627HF'... No
Probing for `Winbond W83627EHF'... No
Probing for `Winbond W83627DHG'... No
Probing for `Asus AS99127F (rev.1)'... No
Probing for `Asus AS99127F (rev.2)'... No
Probing for `Asus ASB100 Bach'... No
Probing for `Winbond W83L786NR/NG/R/G'... No
Probing for `Winbond W83L785TS-S'... No
Probing for `Analog Devices ADM9240'... No
Probing for `Dallas Semiconductor DS1780'... No
Probing for `National Semiconductor LM81'... No
Probing for `Analog Devices ADM1026'... No
Probing for `Analog Devices ADM1025'... No
Probing for `Analog Devices ADM1029'... No
Probing for `Analog Devices ADM1030'... No
Probing for `Analog Devices ADM1031'... No
Probing for `Analog Devices ADM1022'... No
Probing for `Texas Instruments THMC50'... No
Probing for `Analog Devices ADM1028'... No
Probing for `ITE IT8712F'... No
Probing for `SMSC DME1737'... Success!
(confidence 6, driver `dme1737')
Probing for `SMSC SCH5027D-NW'... No
Probing for `Fintek F75373S/SG'... No
Probing for `Fintek F75375S/SP'... No
Probing for `Fintek F75387SG/RG'... No
Probing for `Analog Devices ADM1024'... No
Probing for `Winbond W83791D'... No
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Next adapter: SMBus nForce2 adapter at 1c40 (i2c-1)
Do you want to scan it? (YES/no/selectively): Client found at address 0x2e
Probing for `Myson MTP008'... No
Probing for `National Semiconductor LM78'... No
Probing for `National Semiconductor LM78-J'... No
Probing for `National Semiconductor LM79'... No
Probing for `National Semiconductor LM80'... No
Probing for `National Semiconductor LM85 or LM96000'... No
Probing for `Analog Devices ADM1027, ADT7460 or ADT7463'... No
Probing for `SMSC EMC6D100, EMC6D101 or EMC6D102'... No
Probing for `Analog Devices ADT7462'... No
Probing for `Analog Devices ADT7467 or ADT7468'... No
Probing for `Analog Devices ADT7470'... No
Probing for `Analog Devices ADT7473'... No
Probing for `Analog Devices ADT7475'... No
Probing for `Analog Devices ADT7476'... No
Probing for `Andigilog aSC7611'... No
Probing for `Andigilog aSC7621'... No
Probing for `National Semiconductor LM87'... No
Probing for `National Semiconductor LM93'... No
Probing for `Winbond W83781D'... No
Probing for `Winbond W83782D'... No
Probing for `Winbond W83792D'... No
Probing for `Winbond W83793R/G'... No
Probing for `Winbond W83791SD'... No
Probing for `Winbond W83627HF'... No
Probing for `Winbond W83627EHF'... No
Probing for `Winbond W83627DHG'... No
Probing for `Asus AS99127F (rev.1)'... No
Probing for `Asus AS99127F (rev.2)'... No
Probing for `Asus ASB100 Bach'... No
Probing for `Winbond W83L786NR/NG/R/G'... No
Probing for `Winbond W83L785TS-S'... No
Probing for `Analog Devices ADM9240'... No
Probing for `Dallas Semiconductor DS1780'... No
Probing for `National Semiconductor LM81'... No
Probing for `Analog Devices ADM1026'... No
Probing for `Analog Devices ADM1025'... No
Probing for `Analog Devices ADM1029'... No
Probing for `Analog Devices ADM1030'... No
Probing for `Analog Devices ADM1031'... No
Probing for `Analog Devices ADM1022'... No
Probing for `Texas Instruments THMC50'... No
Probing for `Analog Devices ADM1028'... No
Probing for `ITE IT8712F'... No
Probing for `SMSC DME1737'... Success!
(confidence 6, driver `dme1737')
Probing for `SMSC SCH5027D-NW'... No
Probing for `Fintek F75373S/SG'... No
Probing for `Fintek F75375S/SP'... No
Probing for `Fintek F75387SG/RG'... No
Probing for `Analog Devices ADM1024'... No
Probing for `Winbond W83791D'... No
Client found at address 0x50
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Client found at address 0x51
Probing for `Analog Devices ADM1033'... No
Probing for `Analog Devices ADM1034'... No
Probing for `SPD EEPROM'... Yes
(confidence 8, not a hardware monitoring chip)
Probing for `EDID EEPROM'... No
Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no): Probing for `National Semiconductor LM78' at 0x290... No
Probing for `National Semiconductor LM78-J' at 0x290... No
Probing for `National Semiconductor LM79' at 0x290... No
Probing for `Winbond W83781D' at 0x290... No
Probing for `Winbond W83782D' at 0x290... No
Probing for `IPMI BMC KCS' at 0xca0... No
Probing for `IPMI BMC SMIC' at 0xca8... No
Some Super I/O chips may also contain sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor'... No
Trying family `SMSC'... No
Trying family `VIA/Winbond/Fintek'... No
Trying family `ITE'... No
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor'... No
Trying family `SMSC'... Yes
Found `SMSC DME1737 Super IO'
(hardware monitoring capabilities accessible via SMBus only)
Some south bridges, CPUs or memory controllers may also contain
embedded sensors. Do you want to scan for them? (YES/no): Silicon Integrated Systems SIS5595... No
VIA VT82C686 Integrated Sensors... No
VIA VT8231 Integrated Sensors... No
AMD K8 thermal sensors... Success!
(driver `k8temp')
AMD K10 thermal sensors... No
Intel Core family thermal sensor... No
Intel AMB FB-DIMM thermal sensor... No
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `dme1737' (should be inserted):
Detects correctly:
* Bus `SMBus nForce2 adapter at 1c00'
Busdriver `i2c-nforce2', I2C address 0x2e
Chip `SMSC DME1737' (confidence: 6)
* Bus `SMBus nForce2 adapter at 1c40'
Busdriver `i2c-nforce2', I2C address 0x2e
Chip `SMSC DME1737' (confidence: 6)
Driver `k8temp' (should be inserted):
Detects correctly:
* Chip `AMD K8 thermal sensors' (confidence: 9)
I will now generate the commands needed to load the required modules.
Just press ENTER to continue:
To load everything that is needed, add this to /etc/modules:
#----cut here----
# I2C adapter drivers
i2c-nforce2
# Chip drivers
dme1737
k8temp
#----cut here----
Do you want to add these lines automatically? (yes/NO)
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (14 preceding siblings ...)
2009-09-05 22:13 ` Karl Schmidt
@ 2009-09-06 7:46 ` Jean Delvare
2009-09-06 8:21 ` Jean Delvare
` (5 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-06 7:46 UTC (permalink / raw)
To: lm-sensors
On Sat, 05 Sep 2009 17:13:01 -0500, Karl Schmidt wrote:
> Jean Delvare wrote:
>
> >
> > You forgot to rmmod dme1737 beforehand, which makes the output
> > uninteresting.
>
> once again attached
As you can see it never suggests loading the lm85 driver. So I don't
know where this line came from in your /etc/modules file. A legacy from
a previous installation maybe?
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (15 preceding siblings ...)
2009-09-06 7:46 ` Jean Delvare
@ 2009-09-06 8:21 ` Jean Delvare
2009-09-06 18:05 ` Karl Schmidt
` (4 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-06 8:21 UTC (permalink / raw)
To: lm-sensors
Hi Karl,
On Sat, 05 Sep 2009 17:03:40 -0500, Karl Schmidt wrote:
> No size specified (using byte-data access)
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-1, address 0x2e, mode byte
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
> 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ................
> 20: 64 79 c3 c3 c1 24 1a 17 b2 02 95 02 aa 02 ab 02 dy???$??????????
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5c 89 ..............\?
> 40: 05 00 00 00 00 4d 00 ff 00 ff 00 ff 00 ff 81 7f ?....M........??
> 50: 81 7f 81 7f a3 02 58 02 ff ff ff ff 02 02 02 a7 ??????X?....????
> 60: a7 a7 e0 00 00 00 00 2d 2d 2d 64 64 64 44 40 00 ???....---dddD@.
> 70: 00 00 00 09 09 09 09 09 09 00 30 00 40 00 00 1c ...??????.0.@..?
> 80: 00 a4 00 00 44 2a 86 c3 0d 00 4d 4d 0b 0b 0c 00 .?..D*???.MM???.
> 90: cc cc cc cc 0c 0c 0c 5a f1 c0 ae 00 ff 00 ff 00 ???????Z???.....
> a0: 00 00 0c 00 00 00 00 0b 0b fe ff fe ff ff ff ff ..?....???.?....
> b0: ff 00 00 00 00 00 28 28 0e 0e 2b 2b 00 00 00 00 ......((??++....
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
I have just checked the DME1737 datasheet. This chip doesn't have
real-time status registers but interrupt status registers. In these
registers, each bit can be enabled or disabled individually. If
interrupts are globally enabled, this lets the vendor decide which
events should trigger an interrupt.
The interrupt enable registers are at 0x7E, 0x80 and 0x82. As you can
see, you have only zeroes in these registers, meaning that all
interrupts are disabled. This is why you don't see any alarm flag.
According to the datasheet, this isn't the default value. So this
suggests your mainboard vendor willingly disabled all the individual
interrupt bits.
The global interrupt enable flag is also disabled (register 0x7c bit
2), which is the default. This makes me wonder why the vendor disabled
the individual bits, given that they wouldn't trigger any interrupt
anyway.
Juerg, I don't think the current situation is satisfying: the dme1737
driver is creating *_alarm files in sysfs for alarms which will never
trigger. I think the driver should be modified to check the individual
interrupt enable bits, and only export alarm files for interrupts which
can trigger. What do you think?
Then we may also discuss whether it is desirable to enable individual
interrupt bits when the rest of the configuration is such that physical
interrupts will never trigger anyway. If both the global interrupt bit
and the group enable bits are clear, this should be safe as far as I
can see. This would let users see the alarm flags even when the BIOS
disabled them without a good reason. What do you think?
Karl, I suggest that you go check the BIOS options of your system.
Maybe there are ways to enable or disable an action (such as beeping or
thermal throttling) on some hardware monitoring events? This might
explain what we're seeing. If there are such options, please toggle
them, check whether this gives your alarms in "sensors", and provide a
new i2c dump for each relevant combination.
If you can't find any such option, and want your alarm flags to raise,
here is how you can do that on your system:
# modprobe i2c-dev
# rmmod dme1737
# i2cset -y 0 0x2e 0x7e 0xec
# i2cset -y 0 0x2e 0x80 0x7e
# i2cset -y 0 0x2e 0x82 0x0e
# modprobe dme1737
This will restore the interrupt bits to what the datasheet lists as
the default. I expect this to let you see alarm flags on out-of-limits
conditions again.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (16 preceding siblings ...)
2009-09-06 8:21 ` Jean Delvare
@ 2009-09-06 18:05 ` Karl Schmidt
2009-09-06 18:28 ` Karl Schmidt
` (3 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-06 18:05 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> On Sat, 05 Sep 2009 17:13:01 -0500, Karl Schmidt wrote:
>> Jean Delvare wrote:
>>
>>> You forgot to rmmod dme1737 beforehand, which makes the output
>>> uninteresting.
>> once again attached
>
> As you can see it never suggests loading the lm85 driver. So I don't
> know where this line came from in your /etc/modules file. A legacy from
> a previous installation maybe?
>
Yes - from 2005 - used to work with that kludge - no longer needed - but that isn't the source of
the problem.
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
42.7% of all statistics are made up on the spot.
--------------------------------------------------------------------------------
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (17 preceding siblings ...)
2009-09-06 18:05 ` Karl Schmidt
@ 2009-09-06 18:28 ` Karl Schmidt
2009-09-07 19:08 ` Karl Schmidt
` (2 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-06 18:28 UTC (permalink / raw)
To: lm-sensors
Jean Delvare wrote:
> Hi Karl,
>
> On Sat, 05 Sep 2009 17:03:40 -0500, Karl Schmidt wrote:
>> No size specified (using byte-data access)
>> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>> I will probe file /dev/i2c-1, address 0x2e, mode byte
>> Continue? [Y/n] y
>> 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
>> 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ................
>> 20: 64 79 c3 c3 c1 24 1a 17 b2 02 95 02 aa 02 ab 02 dy???$??????????
>> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5c 89 ..............\?
>> 40: 05 00 00 00 00 4d 00 ff 00 ff 00 ff 00 ff 81 7f ?....M........??
>> 50: 81 7f 81 7f a3 02 58 02 ff ff ff ff 02 02 02 a7 ??????X?....????
>> 60: a7 a7 e0 00 00 00 00 2d 2d 2d 64 64 64 44 40 00 ???....---dddD@.
>> 70: 00 00 00 09 09 09 09 09 09 00 30 00 40 00 00 1c ...??????.0.@..?
>> 80: 00 a4 00 00 44 2a 86 c3 0d 00 4d 4d 0b 0b 0c 00 .?..D*???.MM???.
>> 90: cc cc cc cc 0c 0c 0c 5a f1 c0 ae 00 ff 00 ff 00 ???????Z???.....
>> a0: 00 00 0c 00 00 00 00 0b 0b fe ff fe ff ff ff ff ..?....???.?....
>> b0: ff 00 00 00 00 00 28 28 0e 0e 2b 2b 00 00 00 00 ......((??++....
>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> I have just checked the DME1737 datasheet. This chip doesn't have
> real-time status registers but interrupt status registers. In these
> registers, each bit can be enabled or disabled individually. If
> interrupts are globally enabled, this lets the vendor decide which
> events should trigger an interrupt.
>
> The interrupt enable registers are at 0x7E, 0x80 and 0x82. As you can
> see, you have only zeroes in these registers, meaning that all
> interrupts are disabled. This is why you don't see any alarm flag.
> According to the datasheet, this isn't the default value. So this
> suggests your mainboard vendor willingly disabled all the individual
> interrupt bits.
>
> The global interrupt enable flag is also disabled (register 0x7c bit
> 2), which is the default. This makes me wonder why the vendor disabled
> the individual bits, given that they wouldn't trigger any interrupt
> anyway.
Strange - I dug up a new BIOS I can put in the unit - I need to be physically there to do it.. may
be a few days.
>
> Then we may also discuss whether it is desirable to enable individual
> interrupt bits when the rest of the configuration is such that physical
> interrupts will never trigger anyway. If both the global interrupt bit
> and the group enable bits are clear, this should be safe as far as I
> can see. This would let users see the alarm flags even when the BIOS
> disabled them without a good reason. What do you think?
>
> Karl, I suggest that you go check the BIOS options of your system.
> Maybe there are ways to enable or disable an action (such as beeping or
> thermal throttling) on some hardware monitoring events? This might
> explain what we're seeing. If there are such options, please toggle
> them, check whether this gives your alarms in "sensors", and provide a
> new i2c dump for each relevant combination.
>
> If you can't find any such option, and want your alarm flags to raise,
> here is how you can do that on your system:
>
> # modprobe i2c-dev
> # rmmod dme1737
> # i2cset -y 0 0x2e 0x7e 0xec
> # i2cset -y 0 0x2e 0x80 0x7e
> # i2cset -y 0 0x2e 0x82 0x0e
> # modprobe dme1737
>
> This will restore the interrupt bits to what the datasheet lists as
> the default. I expect this to let you see alarm flags on out-of-limits
> conditions again.
>
OK - this is what I did in the mean time - just to test:
---------------------------------
# modprobe i2c-dev
root@kiwi:~# rmmod dme1737
root@kiwi:~# i2cset -y 0 0x2e 0x7e 0xec
No size specified (using byte-data access)
Value 0xec written, readback matched
root@kiwi:~# i2cset -y 0 0x2e 0x80 0x7e
No size specified (using byte-data access)
Value 0x7e written, readback matched
root@kiwi:~# i2cset -y 0 0x2e 0x82 0x0e
No size specified (using byte-data access)
Value 0x0e written, readback matched
root@kiwi:~# modprobe dme1737 ignore=1,0x2e
# sensors
k8temp-pci-00c3
Adapter: PCI adapter
temp1: +20.0°C
dme1737-i2c-0-2e
Adapter: SMBus nForce2 adapter at 1c00
in0: +2.61 V (min = +0.00 V, max = +2.00 V) ALARM
in1: +1.43 V (min = +0.00 V, max = +2.99 V)
in2: +3.35 V (min = +0.00 V, max = +4.38 V)
in3: +5.10 V (min = +0.00 V, max = +6.64 V)
in4: +12.09 V (min = +0.00 V, max = +15.94 V)
in5: +3.30 V (min = +0.00 V, max = +4.38 V)
in6: +3.00 V (min = +0.00 V, max = +4.38 V)
fan1: 7826 RPM (min = 8000 RPM)
fan2: 8157 RPM (min = 9000 RPM)
fan3: 7929 RPM (min = 0 RPM)
fan4: 7894 RPM (min = 0 RPM)
temp1: +36.2°C (low = -127.0°C, high = +127.0°C)
temp2: +26.3°C (low = -127.0°C, high = +127.0°C)
temp3: +22.9°C (low = -127.0°C, high = +127.0°C)
cpu0_vid: +1.550 V
----------------------------------------
I did get the voltage alarm that is set! But sadly still no fan alarms, but you are obviously on the
correct track.
I will the latest BIOS in and retest - In the BIOS change-logs.. I have version 3.00
There are these changes:
* Adjusted CPU temperature readings
* Changed the routing for the SMDC card to IRQ4
* Updated AMD PowerNOW! functionality
http://www.tyan.com/support_download_bios.aspx?model=S.S2865
I bet this will fix things -- will let you know and supply a config with BIOS comments etc..
I will also check that PNPOS is set to off - see if there are any sensor settings etc.. Anyother
BIOS settings to look for ?
Thanks again..
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
42.7% of all statistics are made up on the spot.
--------------------------------------------------------------------------------
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (18 preceding siblings ...)
2009-09-06 18:28 ` Karl Schmidt
@ 2009-09-07 19:08 ` Karl Schmidt
2009-09-07 19:42 ` Jean Delvare
2009-09-10 7:56 ` Jean Delvare
21 siblings, 0 replies; 23+ messages in thread
From: Karl Schmidt @ 2009-09-07 19:08 UTC (permalink / raw)
To: lm-sensors
I sure wish there was a way to search for older postings of this mailing list. I think there may be
some ongoing work on the k8temp?
Running
#sensors
k8temp-pci-00c3
Adapter: PCI adapter
temp1: +21.0°C
Trying to create an alarm for that temp:
#AMD K8 core temperature monitor
chip "k8temp-pci-00c3"
set temp1_max 10
But I get this:
# sensors -s
Error: Line 3: Unknown feature name
k8temp-pci-00c3: No such sub-feature known
--------------------------------------------------------------------------------
Karl Schmidt EMail Karl@xtronics.com
Transtronics, Inc. WEB http://xtronics.com
3209 West 9th Street Ph (785) 841-3089
Lawrence, KS 66049 FAX (785) 841-0434
Action speaks louder than words but not nearly as often. -- Mark Twain
--------------------------------------------------------------------------------
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (19 preceding siblings ...)
2009-09-07 19:08 ` Karl Schmidt
@ 2009-09-07 19:42 ` Jean Delvare
2009-09-10 7:56 ` Jean Delvare
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-07 19:42 UTC (permalink / raw)
To: lm-sensors
On Mon, 07 Sep 2009 14:08:05 -0500, Karl Schmidt wrote:
> I sure wish there was a way to search for older postings of this mailing list. I think there may be
> some ongoing work on the k8temp?
http://marc.info/?l=lm-sensors is searchable.
> Running
>
> #sensors
> k8temp-pci-00c3
> Adapter: PCI adapter
> temp1: +21.0°C
>
>
> Trying to create an alarm for that temp:
>
> #AMD K8 core temperature monitor
> chip "k8temp-pci-00c3"
> set temp1_max 10
>
> But I get this:
>
> # sensors -s
> Error: Line 3: Unknown feature name
> k8temp-pci-00c3: No such sub-feature known
The K8 CPU includes simple thermal sensors, which don't have limits. So
what you see is expected. If there were limits, they would be displayed
by "sensors".
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [lm-sensors] Creating alarm for fans
2009-08-28 18:36 [lm-sensors] Creating alarm for fans Karl Schmidt
` (20 preceding siblings ...)
2009-09-07 19:42 ` Jean Delvare
@ 2009-09-10 7:56 ` Jean Delvare
21 siblings, 0 replies; 23+ messages in thread
From: Jean Delvare @ 2009-09-10 7:56 UTC (permalink / raw)
To: lm-sensors
Hi Karl,
On Sun, 06 Sep 2009 13:28:04 -0500, Karl Schmidt wrote:
> OK - this is what I did in the mean time - just to test:
> ---------------------------------
> # modprobe i2c-dev
> root@kiwi:~# rmmod dme1737
> root@kiwi:~# i2cset -y 0 0x2e 0x7e 0xec
> No size specified (using byte-data access)
> Value 0xec written, readback matched
> root@kiwi:~# i2cset -y 0 0x2e 0x80 0x7e
> No size specified (using byte-data access)
> Value 0x7e written, readback matched
> root@kiwi:~# i2cset -y 0 0x2e 0x82 0x0e
> No size specified (using byte-data access)
> Value 0x0e written, readback matched
> root@kiwi:~# modprobe dme1737 ignore=1,0x2e
>
> # sensors
> k8temp-pci-00c3
> Adapter: PCI adapter
> temp1: +20.0°C
>
> dme1737-i2c-0-2e
> Adapter: SMBus nForce2 adapter at 1c00
> in0: +2.61 V (min = +0.00 V, max = +2.00 V) ALARM
> in1: +1.43 V (min = +0.00 V, max = +2.99 V)
> in2: +3.35 V (min = +0.00 V, max = +4.38 V)
> in3: +5.10 V (min = +0.00 V, max = +6.64 V)
> in4: +12.09 V (min = +0.00 V, max = +15.94 V)
> in5: +3.30 V (min = +0.00 V, max = +4.38 V)
> in6: +3.00 V (min = +0.00 V, max = +4.38 V)
> fan1: 7826 RPM (min = 8000 RPM)
> fan2: 8157 RPM (min = 9000 RPM)
> fan3: 7929 RPM (min = 0 RPM)
> fan4: 7894 RPM (min = 0 RPM)
> temp1: +36.2°C (low = -127.0°C, high = +127.0°C)
> temp2: +26.3°C (low = -127.0°C, high = +127.0°C)
> temp3: +22.9°C (low = -127.0°C, high = +127.0°C)
> cpu0_vid: +1.550 V
> ----------------------------------------
>
> I did get the voltage alarm that is set! But sadly still no fan alarms, but you are obviously on the
> correct track.
Strange... Can you please test all the voltage inputs, all the fan
inputs and all the temperature inputs, to summarize what works and what
doesn't? And then provide a new i2cdump when all alarms should be set.
Please note that you must re-issue the i2cset sequence above after
every reboot, or the changes are lost.
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply [flat|nested] 23+ messages in thread