From mboxrd@z Thu Jan 1 00:00:00 1970 From: Karl Schmidt Date: Sat, 05 Sep 2009 19:07:49 +0000 Subject: Re: [lm-sensors] Creating alarm for fans Message-Id: <4AA2B705.7000109@xtronics.com> MIME-Version: 1 Content-Type: multipart/mixed; boundary="------------080108090804090205030007" List-Id: References: <4A9823A2.2010907@xtronics.com> In-Reply-To: <4A9823A2.2010907@xtronics.com> To: lm-sensors@vger.kernel.org This is a multi-part message in MIME format. --------------080108090804090205030007 Content-Type: text/plain; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable Jean Delvare wrote: > Hi Karl, >=20 > 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 th= e alarm? >=20 > 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. >=20 >>> 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=20 >> appearing twice was the problem. I think it may be a host image due to i= ncomplete hard ware encoding. >> >> >> This is a Tyan S2865 >> >> In case there is something being misidentified I have the spec sheet lin= k 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=3D0,0x2e >> # sensors -s # >> # Edited by: Raphael Deng 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?? >=20 > Correct, we now do have support for the DME1737, which is definitely > present on that board. >=20 > 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. >=20 > 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. >=20 > Please provide the output of: >=20 > 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=3D0,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 ------------------ >=20 > 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) n= ow reads: options dme1737 ignore=3D1,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 dme1737-i2c-0-2e Adapter: SMBus nForce2 adapter at 1c00 I rmmod dme1737 - and then modprobe dme1737 option ignore=3D1,0x2e failed to work - but modprobe dme1737 ignore=3D1,0x2e OK - it now sees just one chip - but alarms still won't work - I think the = keyword 'option'=20 shouldn't be used in /etc/modules - confirmed with a reboot. > #sensors > k8temp-pci-00c3 > Adapter: PCI adapter > temp1: +20.0=B0C >=20 > dme1737-i2c-0-2e > Adapter: SMBus nForce2 adapter at 1c00 > in0: +2.61 V (min =3D +0.00 V, max =3D +2.00 V) > in1: +1.43 V (min =3D +0.00 V, max =3D +2.99 V) > in2: +3.35 V (min =3D +0.00 V, max =3D +4.38 V) > in3: +5.10 V (min =3D +0.00 V, max =3D +6.64 V) > in4: +12.09 V (min =3D +0.00 V, max =3D +15.94 V) > in5: +3.30 V (min =3D +0.00 V, max =3D +4.38 V) > in6: +3.00 V (min =3D +0.00 V, max =3D +4.38 V) > fan1: 7826 RPM (min =3D 8000 RPM) > fan2: 8157 RPM (min =3D 9000 RPM) > fan3: 7917 RPM (min =3D 0 RPM) > fan4: 7929 RPM (min =3D 0 RPM) > temp1: +37.1=B0C (low =3D -127.0=B0C, high =3D +127.0=B0C) > temp2: +26.8=B0C (low =3D -127.0=B0C, high =3D +127.0=B0C) > temp3: +23.4=B0C (low =3D -127.0=B0C, high =3D +127.0=B0C) > cpu0_vid: +1.550 V Is it ignoring the wrong one?? More digging