cpu overheating

[Mike McCarty]

James Wilkinson wrote:
> I really shouldn't be joining in this thread again. It's obvious Mike
> can't quite get the hang of a simple concept...

The simple concept which I missed is (according to Gordon Messmer)
is that the software which is consuming the CPU is already
known. I missed that.

What I've been proposing is to find what piece of software was
consuming the CPU. Somehow, I missed the fact that we *already*
know what piece of software is doing so, and it is normal
operation for that.

I have never claimed that he doesn't have a hardware problem
with heat.

[snip]

> If, as appears *highly* probable, the system really was overheating,
> *whatever* Linux does it logically cannot be responsible. 

That is not an a-priori fact. In this case, everyone be I seemingly
knew that the culprit was also already known, which put what I wrote
off-base. Sorry about that.

> Hardware should not overheat whatever software does, so whatever Linux

I never claimed that it should.

> is doing, the hardware should still not overheat. If it was happening in
> Windows, Windows would not be responsible. It *cannot* be a software
> bug!

It can be a symptom of a software defect, which was my only claim.

> There is, however, a related argument you could make. That it is
> important to find out exactly what is happening so that whoever is
> appropriate can stop it happening again. But for this we need to know
> such things as:
>  * where did the error messages come from;
>  * how hot does that processor actually get;
>  * are any temperature probes correctly configured.
> 
> But these are different questions, and we'd want to gather different
> data. The question "what was going on" is relatively unimportant -- we
> know the Original Poster was running yum, and we *know* that stresses
> the processor.

But, unfortunately, I missed that point, and caused this big
furor.

For which I apologize.

>>If thinking we should take every opportunity to investigate
>>unusual behavior for possible defects is being an "idiot", then
>>every industry in the world which considers availability and
>>reliability in software to be important is full of idiots.
>>This includes telecomm, aviation, and power systems at
>>least.
> 
> 
> These industries have the sense to know that reliable software is
> dependent on reliable hardware. If the Original Poster's hardware is not
> reliable, crashing software is expected. Indeed, fly-by-wire aeroplanes
> are designed around the possibility that the computers will fail, and
> usually have multiple redundant "voting" systems to identify and
> neutralise rogue systems.

Re-read that in light of the fact that I missed that someone
had already identified the software culprit. That was the
only point I ever was trying to make: That we should identify
the software eating the CPU, and ascertain whether that was
considered to be normal behavior for that software.

That I missed this fact, is an oversight on my part, for which
I apologize.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!