spurious erroneous ALARM flag on fan reading and Soyo Dragon Plus notes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> I randomly see this sort of thing
> 
>  P/S Fan:  1418 RPM  (min = 1250 RPM, div = 4)          ALARM
> 
> often followed by this
> 
>  P/S Fan:  1418 RPM  (min = 1250 RPM, div = 4)
> 
> This is, of course, silly.  Is there something subtle in the alarm
> code that it can not compare "1418 < 1250" and determine "false"?  I
> took a quick look at the code, but didn't try to decipher all the
> macros.  Does the chip generate this alarm signal itself?

Yes, it does.

> Sometimes I see this only once when I first run "sensors" after boot,
> but sometimes it seems to happen repeatedly.
> 
> This variable speed fan starts very slowly, around 1150 rpm when the
> computer is first turned on cold.  I changed the divisor to 8 and the
> min to 1100. If the ALARM is generated on the chip, does the chip
> latch the ALARM state? and does "sensors" clear the ALARM state after
> reading the alarm?  Then this would literally be a real passing ALARM
> generated during startup when the P/S fan temperature sensor is cold.

You got it. The alarm is generated by the chip, and has to be read at
least once before it can wear off.

> If so a little note about latching ALARM states would be in order.

This is fully documented in almost all doc/chips/* files. If it isn't
for your specific chip, it could be added. We accept patches.

This is also documented in our FAQ:
http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/lm_sensors-FAQ.html#Section-2_002e6
http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/lm_sensors-FAQ.html#Section-4_002e4

> And still, I'll get this
> 
>  P/S Fan:  1480 RPM  (min = 1096 RPM, div = 8)          ALARM
> 
> mixed occasionally with this erroneous rpm reading (divide by 2)
> 
>  P/S Fan:   740 RPM  (min = 1096 RPM, div = 8)          ALARM
> 
> even when the system is warmed up.  The fan is just running at the
> same speed, of course.  If there is a hardware problem with the fan
> signal, there is still the issue of where the alarm is generated.  Is
> the alarm, again, being latched by the chip?

The alarm is doubtlessly latched by the chip. As for the bad readings,
I'm not sure. It could be temporarily caused by changing the clock
divider, or this is a hardware problem.

> I realize that there is an ambiguity about the fan divisor.  With
> respect to the fan divisor chart and explanation on the web site, do
> the "rpm's" refer to the "pre-compute" or "post-compute" values with
> respect to the fan"compute" equations?

99% of the time there are no compute lines needed for fans. There only
are when you use fans which don't issue 2 pulses per revolutions like
all other fans do.

> I assume they have to be
> "pre-compute" because the hardware doesn't know anything about fan
> pulses per revolution, but then the fan divisor chart should say
> "pulses per minute" and NOT "revolutions per minute", which would make
> the numbers in the chart all wrong by a factor of 2 anyway, yes?

Correct. This would make things more complex for the average reader
though. And I can see that you saw the trick ;) Again, we take patches
on the documentation, providing it doesn't make things more complex for
newcomers.

> I tried changing the fan divisor back to 4, but leaving the minimum at
> 1100. Compared to the original configuration, the fan1_min value is
> lower.  This works sometimes
> 
>  P/S Fan:  1360 RPM  (min = 1102 RPM, div = 4)
>  P/S Fan:  1430 RPM  (min = 1102 RPM, div = 4)
> 
> but sometimes does this
> 
>  P/S Fan:  1480 RPM  (min = 1102 RPM, div = 4)          ALARM
>  P/S Fan:    -0 RPM  (min = 1102 RPM, div = 4)          ALARM
>  P/S Fan:  1467 RPM  (min = 1102 RPM, div = 4)          ALARM

With such a low fan you should really stick to div=8.

The fact that fan1 is "lower" may be the consequence of measure
resolution varying depending on div. Lower div, higher resolution
(smaller steps), but then you can't measure the lowest speeds at all.
It's all explained in the chart.

> Using a fan divisor of 16 does not help
> 
>  P/S Fan:  1454 RPM  (min = 1110 RPM, div = 16)          ALARM
> 
> 
> I have in /etc/sensors.conf
> 
>     label fan1  "P/S Fan"
>     compute fan1  @ / 2,  @ * 2    # 4 pulse per rev
>     set fan1_div 4
>     set fan1_min 1100
> 
> I'm inferring the factor of two compute equation based upon the fan
> speed reported by the BIOS.  I've only made the two readings display
> the same.  I haven't measured the actual fan speed or pulse frequency,
> but the hardware only knows about the pulse frequency anyway.

How come that the BIOS knows you have a 4 pulse/rev fan?

> Also, another issue, I always get from "sensors"
> 
>  VBat:      +0.00 V
> 
> I don't know if this is normal for this board or not.  The BIOS
> display always has a correct battery voltage reading.  Maybe some
> other chip generates that reading, but that seems unlikely.

Agreed, seems bogus.

> A note about the documentation.
> 
> I would have found helpful a little more information about the fan
> divisors in either the man page or the top of the /etc/sensors.conf.
>
> Perhaps you could simply add the small chart from
> 
>  THEORY OF OPERATION - Guide to Fan Divisors
>  http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/fan-divisors
> 
> to the top of /etc/sensors.conf, with a link to the web page "for more
> info".  You might want to change this to "Pulses per minute" with a
> note about "Pulses per revolution", but this would still be helpful as
> it is.

Note that the chart is chip dependant. We don't want to duplicate the
documentation. Maybe a pointer to the doc file would be fine? We take
patches.

Anyway I have plans to make the divider selection automatic in the
future so it would solve the problem.

Thanks.

-- 
Jean Delvare
http://khali.linux-fr.org/



[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux