Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: <linux-parisc@vger.kernel.org>
Subject: Machine stuck when userspace 100% busy
Date: Mon, 22 Oct 2012 09:41:36 +0200	[thread overview]
Message-ID: <35fd660c364b9a45770b17a5bd0ecbaf@sf-mail.de> (raw)

My C3600 runs the CMake nightly builds. Basically this is a master 
process (ctest) that forks other binaries that do the actual tests. 
Afterwards it collects the output. If the child does not respond for 
some time (usually set to 30 minutes) it will get killed by ctest.

Yesterday someone accidentially introduced an endless loop into CMake, 
so some of the called tests will run at 100% CPU load forever. The 
master process was not affected by this, so these childs should have 
eventually got killed. But this did not happen. It did happen on all 
other machines building those tests 
(http://open.cdash.org/index.php?project=CMake&date=2012-10-21, e.g. 
http://open.cdash.org/viewTest.php?onlyfailed&buildid=2621607), but not 
on my machine. And from all what I can tell it does not look as if it is 
a ctest bug, but something in the scheduler or something like that not 
working properly.

$ ping voyager
PING voyager (192.168.2.119) 56(84) bytes of data.
64 bytes from voyager (192.168.2.119): icmp_seq=1 ttl=64 time=0.504 ms
64 bytes from voyager (192.168.2.119): icmp_seq=2 ttl=64 time=0.268 ms
64 bytes from voyager (192.168.2.119): icmp_seq=3 ttl=64 time=0.274 ms

So, the machine is alive and the ping time is ok. Doing ssh to it will 
get stuck for hours (literally). So, sadly, I have currently no way to 
get into userland of the machine. What I know is:

-ssh doesn't work
-kernel is alive
-the machine is very likely running at 100% CPU load from a normal user 
account (with not too excessive RAM usage AFAIK)

So for me it looks like this "userspace is at 100%" does something 
utterly bad to the scheduling, as it seems that no other processes will 
get their chance of running. If ctest would get it's chance it should 
have killed the slave after ~30 minutes, and ssh should definitely work. 
 From what I see on other machines the worst case scenario would be 18 of 
these amok processes, so after ~9 hours the dust should start to clear. 
That would have been nearly 20 hours ago, so something is not working 
there.

Any ideas?

Eike

             reply	other threads:[~2012-10-22  7:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22  7:41 Rolf Eike Beer [this message]
2012-10-22 13:27 ` Machine stuck when userspace 100% busy Carlos O'Donell
2012-10-22 14:07   ` Rolf Eike Beer
2012-10-22 14:15     ` Carlos O'Donell
2012-10-23 15:23       ` Rolf Eike Beer
2012-10-24 23:22         ` John David Anglin
2012-10-25  7:35           ` Rolf Eike Beer

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=35fd660c364b9a45770b17a5bd0ecbaf@sf-mail.de \
    --to=eike-kernel@sf-tec.de \
    --cc=linux-parisc@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox