Charlie said:
I'm looking at a customer's Packard Bell XP machine where the CPU fan revs
high soon after start-up, and stays that way. In BIOS, the PC reports that
the CPU fan is working OK. Nothing is reported about the system fan, except
that it is running at 0 revs. This isn't true; you can see the fan spinning
in its chassis, and feel the airflow with your hand.
The latest thing that the customer tells me is that the CPU only revs after
logging into XP. If he leaves the machine at the login screen, it never revs
up.
There is no dirt in either fan.
Any comments/ideas?
Charlie Lewis
The fan would need at least three wires, to be sensor equipped. You have the
+12V and the ground wire, and the third wire is the RPM or tachometer wire.
That third wire pulses twice per revolution. It is likely open collector, and
a pullup on the motherboard establishes the logic high level, between
pulses.
So if the fan only had two wires, the answer would be simple as to why
the readout was zero.
If the transistor in the fan hub failed for some reason, that could cause
a zero reading. If the signal wire is shorted to ground or was open
circuit, that would do it as well.
Fortunately, there is another answer for why the readout is zero, and it
has to do with the measurement method. The measurement chip measures the
interval between pulses, and the software takes the inverse to get the
RPMs.
To measure the interval, the measurement chip starts with a high speed
clock input. That clock is divided by a programmable prescaler.
Say that the time between RPM pulses is 45 of the prescaler output pulses. If
we changed the prescaler by a factor of 2 in one direction, the readout
register would say 22 counts. Adjusted in the other direction, it would
read 88 counts perhaps.
Say the readout register is 8 bits wide. The maximum value that can be stored
is 255. Now, imagine the fan is spinning really, really slowly. The
readout register is rapidly incrementing (because the first RPM pulse from
the fan has been seen). But the second pulse from the fan hasn't happened
yet. The register gets to 255 and won't go further (this is the overflow
condition). When the software takes the inverse, it recognizes the overflow
condition of 255 in the register. What the software doesn't know, is whether
the second pulse was ever seen. The software has the option to record a value
based on the 255 stored in the register, or it can take the inverse of
"infinity" and claim the fan speed is zero, when the readout register
contains 255.
This happens more often than you'd think. My computer will do this, when it
first starts up cold in the morning. The power supply fan is really slow,
and the computer thinks it is spinning at zero. And that is because the
readout register overflows, and the software doesn't know the real fan
speed, so it claims the fan is running at zero.
Why does this happen ? Partly, it is due to stupidity. The BIOS sets the
prescaler to a particular fixed value. It isn't clear why the value was selected.
The BIOS doesn't alter the setting according to the circumstances, and just
plugs in a constant value at startup.
There is a utility for measuring temperatures, voltages, and fan speeds,
called Speedfan ( almico.com ). The author of that program, recognized this
issue, while designing his program. He "auto-adjusts" the prescaler value.
Say the register holds 8 bits, or a maximum reading of 255. The Speedfan
program takes a reading, say the reading was 22. Speedfan would change the
prescaler by a factor of 2. Now the reading is 44. Speedfan would adjust it again.
A third adjustment makes the readout 88. A fourth results in 176, and now
we're past the half way point. So perhaps we can settle back to the 88
reading. We're making decent use of the dynamic range of the register.
And the arithmetic that is done, to compute the RPMs, does take the
prescaler value into account, to get a correct value for the RPMs.
So in fact, changing the prescaler value should not hurt any other
software that relies on the readout register. (The prescaler value
is part of the equation to work out the RPMs.)
If the Speedfan code was running in the BIOS module, then we'd
never have a zero reading due to "readout register overflow".
Except for the case that the prescaler is "railed", or pushed
to one extreme, as would happen in the case that the fan had
actually stopped. So if that extreme condition arose, then we'd
still get a zero reading via the arithmetic. It might be that
any RPM below about 500RPM or so, would be recorded as a zero
RPM value.
Anyway, the purpose of that long winded explanation, is to point
out that a zero reading can be due to exceeding the dynamic
range of the measurement chip - and for no good reason. If
the code for the measurement chip is written right (as in Speedfan),
then you're more likely to get good readout values.
If you try Speedfan, and the value is still zero, then I'd suspect
that the RPM signal is not making it to the measurement chip.
On purpose, I'm avoiding addressing the control algorithm used
by your computer. There are a number of ways it could be
implemented. For example, on some modern measurement chips,
the chip has a "cruise control" option, where the chip takes
care of adjusting the fan speed. Older chips rely on either
a BIOS or a utility program to manually adjust the speed, some
number of times a second. There are various open loop or
closed loop control methods, threshold temperatures, response
times and so on, that are used to control the fan.
It would be normal engineering practice, to run a fan at full
speed, until the software takes control. That would be the
case, if the designer wanted to avoid the system overheating,
in the event that the BIOS or the utility program did not
start promptly. I believe at least one Macintosh computer model
behaves that way, much to the annoyance of its users.
What your machine is doing, and what it might be doing
"normally", I can't even begin to guess at. Someone with
more Packard Bell experience, might be more familiar with
how and when the fan control starts to operate. Even your
customer, may know what is "normal" for the machine, such
as proper fan control happening even when staring at the
BIOS screen. Or proper fan control not starting to occur,
until Windows is booted. If the latter case, then you'd want
to know what item in the startup items, might be the
Packard Bell fan control software.
If some software interfered with the prescaler value, that
might affect how other things worked. For example, say
a customer doesn't know about intelligent fan control,
and accidentally loads Speedfan on the computer. Perhaps
there would be some interaction between the two programs,
depending on how well written they are. Back when the
measurement chip was on the SMBUS, it was possible to
get corrupted readings from the measurement chip, just
by having two pieces of software polling the SMBUS
at the same time (no semaphore to give exclusive
access).
I think the fact that the CPU fan is listed as being
at zero RPMs is significant, and perhaps by connecting
a known working fan to the CPU fan header, and connecting
the CPU fan to a fan header known to deliver a fixed 12V
output, you can do some more testing. It could be that
the RPM signal on the CPU fan has gone bad. But there
are also some possible software ways for it to screw
up - just hard to say without knowing how Packard Bell
does stuff like that.
HTH,
Paul
