All of lore.kernel.org
 help / color / mirror / Atom feed
From: jroland@linux-migration.net (Jon Roland)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] Fw: Processes causing CPU to overheat
Date: Tue, 23 Aug 2005 06:27:12 +0000	[thread overview]
Message-ID: <430A5F69.10808@linux-migration.net> (raw)
In-Reply-To: <430A5153.2040604@linux-migration.net>

Thanks for your response. No, it's not dust. Problem hasn't recurred, so I can't 
open the case to see if the fan has stopped or slowed when the temp begins to 
rise, but that is an obvious next move if it does.

Of course, mechanical problems would not correlate with CPU load, processes, and 
disk load, stopping the CPU fan (or increasing power to the CPU) when the nice 
usage (not system or user) pegs at 100%, and dropping back to normal when the 
first perl process is killed, which also causes all the other perl processes to 
end, and the nice usage to drop to zero. Nothing else causes the CPU temp to rise. 
I have done this process kill twice now, so it is not a coincidence.

I don't know why my log file is truncated at 80 columns to reveal more information 
about those perl processes.

Phil Edelbrock wrote:
> 
> Weird.  Something I would check is to make sure that dust hasn't  caused 
> the CPU fan to slow (or stop).  I had problems with a server  this 
> summer which had lots of dust, and a slightly mis-installed CPU  
> heatsink.  The result was rapidly rising temps (and hangs) when the  
> computer was loaded.
> 
> I think you need to look inside the server to see just what is going  on 
> there at the heatsink and CPU.  Are things installed right?  Is  there 
> dust or something causing the heatsink/fan to not work  properly?  Is 
> the environment the server is in OK (temp and humidity  should be low).  
> Heatsinks sometimes have a piece of plastic which  needs to be peeled 
> off the heatsink compound before installation.
> 
> BTW- I hope you know what's causing the strange loading (those Perl  
> processes?).  If that's unusual, then you could have some nasty  spammer 
> or somebody using your box to do evil things.  BBTW- Your top  output 
> doesn't show much becuase that it's cut off on the right side  where 
> things are just get interesting. Oh, and I have no idea why  sensor 
> values disappear unless the driver or something is being  unloaded(?).
> 
> 
> Phil

-- 

----------------------------------------------------------------
Linux Migration Network   7793 Burnet Road #37, Austin, TX 78757
512/374-9585 www.linux-migration.net jroland@linux-migration.net
----------------------------------------------------------------

  reply	other threads:[~2005-08-23  6:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-23  5:28 [lm-sensors] Fw: Processes causing CPU to overheat Jon Roland
2005-08-23  6:27 ` Jon Roland [this message]
2005-08-23  6:55 ` Phil Edelbrock
2005-08-23 18:45 ` Craig Sylla
2005-08-23 20:27 ` [lm-sensors] " Jon Roland
2005-08-24 17:59 ` Jon Roland
2005-08-24 22:48 ` Jon Roland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=430A5F69.10808@linux-migration.net \
    --to=jroland@linux-migration.net \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.