"Peter Ross" <Petros.Listig@fdrive.com.au> writes:

for the last few weeks I have problems with unresponsive konsoles (and gnome-terminals as well, I tried) under KDE with Debian 7.8.

They seem to be extremely slow (I have to wait for 10 seconds after entering a simple command) and I believe it happens only when I am running commands with large output in other windows (e.g. a ssh session to a FreeBSD server and "make buildworld")

When this happens, check loadavg (it should be below N, where N is the number of CPU cores); check for procs in D state; check iostat; check free. NB: iostat's first paragraph of output is *boot time* stats, not current stats. My initial suspicion is you're doing make with too high a -jN option, and just fork bombing / OOMing your system. In my experience with fbcon, large output (e.g. dmesg or cat /var/log/syslog) will slow the entire system noticably, but switching to another vt (Ctrl+Alt+F2) "fixes" it. I also noticed it running scren inside xterm, but it was MUCH MUCH MUCH faster to recover -- it's the main reason I start X by default these days. I am not really famliar with libvte (gnome/xfce Terminal) nor konsole, but I would expect them to be on the order of xterm more than fbcon. Are you running screen / tmux? When this happens, is the "lots of output" window onscreen? Try minimizing it (konsole) and switching window or detaching (screen), so that fewer layers are trying to render the "lots of output". I suppose a compositor (as is built into the tier1 WMs these days) could also cause problems by trying to render the window even when it is unmapped; try disabling compositing temporarily. You could also try using scroll lock (^S), which was originally intended for exactly this purpose. In my experience, it's totally useless. If you need test codebase to generate lots of output or create lots of load, "make -jN V=1" in the busybox codebase is very good at it. Doing "make -j" (unbounded parallelism) on busybox kills my system :-)