Hi David, > OK. I finally got a bit of time to look at this again. Here's what > I've seen, even if it doesn't make any sense. > > I'm running a Red Hat 9 box with version 2.9.0 of i2c and lm_sensors > now. This box also has two lm87s in it. The fan speeds of 6 fans > are controlled by the smsc superio. Each superio pwm output controls > 3 fans. One of those fans is monitored by the superio and the > remaining two are each monitored by a different lm87. > > After upgrading to the latest version of lm_sensors and i2c, I > verified the fan speeds and fan control. It worked as expected. > > I then shut off the server and unplugged one bank of fans (don't > worry, they are set up in a redundant configuration). When I booted > up, the unplugged fans showed alarms on the lm87s but not on the smsc > superio. > > I then raised the alarm threshold for the smsc monitored fans in the > /etc/sensors.conf to a value greater than the fans were currently > running. I then ran sensors -s. Sensors showed errors for BOTH > fans on the superIO the first time it was run, then the error on the > disconnected fan cleared. I then tried running sensors -s by itself. > > Each time I ran sensors -s followed by sensors, the disconnected fan > on the superIO had an alarm, but it cleared the second time sensors > was run. Sounds like 1* missing fans don't reassert alarms and 2* writing to the limits register does fore the alarm to reassert if needed. The smsc47m1 driver clears alarms after it reads them. Typically the other drivers don't do it because other chips do clear them automatically. What you describe suggests that it should probably not be done (or not always). I guess that this code was put there for a reason though. You could try commenting it out (in smsc47m1_update_client): if(data->alarms) smsc47m1_write_value(client, SMSC47M1_REG_ALARM1, 0xc0); But if you do, I suspect that at some point alarms will stay even once the alarm condition has gone. Also note that we attempt to clear both alarm bits regardless of which is set. Could it be the cause of the trouble you observe (both alarms raised when only one fan is missing)? It would be really weird. I tend to think that your chip has a hardware issue, either because it is broken or because it wasn't properly wired. > However... I've found something new when trying the "unplug the fan > test". When I unplugged the fan, sensors indicates that the fan > speed has not changed. Here's the output of sensors: > (...) > smsc47m1-isa-0680 > Adapter: ISA adapter > superio,Fan1: > 1517 RPM (min = 1396 RPM, div = 8) > superio,Fan2: > 1498 RPM (min = 1396 RPM, div = 8) > > The superio,Fan1 input should read 0. > > Here's the dump from the superio chip while it's in this state: > # isadump -f 0x0680 0x80 > WARNING! Running this program can cause system crashes, data loss and > worse! I will probe address range 0x680 to 0x6ff. > Continue? [Y/n] y > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: 01 00 01 00 18 ff e7 1f 00 00 d8 00 00 00 00 00 > 10: 02 02 67 1f c0 00 00 00 00 00 00 00 00 00 03 03 > 20: 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 > 30: 00 00 00 05 05 04 04 01 00 04 84 84 00 01 01 05 > 40: 05 05 04 05 04 05 04 01 01 00 00 00 84 12 04 57 > 50: 00 00 00 00 00 00 14 14 f0 b9 ba 68 68 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The dump confirms the non-zero speed report (at 0x59 and 0x5a) and no alarm raised, so this is definitely a hardware issue. Not the first time I hear about this, although I don't remember if it was for the same chip or a different one. At any rate there nothing we can do as far as I can see. Unless you have an idea? -- Jean Delvare http://khali.linux-fr.org/
