linux-kernel - system apparently coming to its knees with -rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20131103201457.GA26797@milliways>
Date:	Sun, 3 Nov 2013 20:14:57 +0000
From:	Ken Moffat <zarniwhoop@...world.com>
To:	linux-kernel@...r.kernel.org
Subject: system apparently coming to its knees with -rc7

 I'm not sure how best to describe this.  I've got a 4-processor AMD
phenom desktop (single socket, 8GB memory, 16GB swap available)
running 64-bit x86_64.  It was building some desktop packages using
'make -j4', doing a backup (rsync over nfs3, from fcrontab), with
firefox and some urxvt terms open.  My wm is icewm which has taskbar
windows for both net activity and cpu activity.

 Normally, the cpu activity window is green on black (bottom quarter
during configure and make install, and up to all four quarters during
make -j4).  I noticed that the bottom quarter had turned red, with
black above it.  At this point the system was still responding.  I
fired up 'top', that showed me that kswapd, rsync, and cc1 were each
using more than 99%, and only 1 cc1 process appeared to be running.
Gradually, the cpu indicator panel turned 3/4 red.

 The box was not swapping according to 'top' (still a little memory
available).  After some time I killed the build with with Ctrl-C.
'top' still showed cc1 using more than 99%.  I got a trace with
Sysrq-T and decided to reboot.

 Shut down the terms and the browser without difficulty, then tried
to leave X with ctrl-alt-backspace (call me a traditionalist).

 Nothing happened, except that the mouse pointer disappeared and the
desktop clock froze.  Possibly it _was_ going back to a tty.  After
about 10 seconds 1 got as far as MagicSysRQ-S and the screen went
black.  Unmounted, rebooted.

 I'm attaching gzipped versions of the part of the syslog that shows
the trace, and my config - the trace expands to over 300K.  System
is recent linuxfromscratch (gcc-4.8.1) but with make-4.0.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce

Download attachment "syslog.gz" of type "application/x-gunzip" (31224 bytes)

Download attachment "config.gz" of type "application/x-gunzip" (17064 bytes)