[lkml]   [2013]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectsystem 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.

das eine Mal als Tragödie, dieses Mal als Farce
[unhandled content-type:application/x-gunzip][unhandled content-type:application/x-gunzip]
 \ /
  Last update: 2013-11-03 21:41    [W:0.027 / U:5.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site