Thanks for this analysis.

I've since discovered that I'm not suffering so much from a system lock-up
but the aggravating but possibly normal effects of the odd thing I was
doing.

Odd thing I was doing:  a bash script to render every one of 3000  *.pov
files in a directory, some buggy, some involving massive parsing time, some
involving massive radiosity calc times.

Soooo, coming back to the box after letting it run overnight, I would shake
mouse and see the screen.  But the various components of the KDE session
were unresponsive. I for example, could not access files with konqueror.
They never came back to a usable state. (In computing terms, this means
they didn't come back within the three to four minutes it took to exhaust
my patience.  They *did* however come back on another day when I gave it a
full ten minutes.)  I guess this is understandable given the massive
undertaking of CPU resources in the background.



Stefan Viljoen <spamnot@<removethis>polard.com> wrote:
> gregjohn spake:
>
> > I was trying to do a render of a HUGE pile of .pov files using a bash
> > session.  When I came back the next morning, I found that the system was
> > locked up, and that it had essentially stopped mid-render.
> >
> > I am trying to diagnose the problem.  (At first I worried it a quirk of
> > linux or KDE and thoroughly embarassed myself on my local LUG email list.)
> >
> > So here's my current top readout when things appear to be running well.
> >
> > Suppose I find another alleged system lock-up tomorrow morning and am able
> > to get top to run. What kinds of things could go wrong, and how would I
> > differentiate between a  problem in KDE's abruptly sending system to
> > sleep, or my use of povray using up all the memory, memory leaks, etc?
> >
> > Thanks.
>
> Hmm - is it just a lockup of KDE? I. e. the rest of the system is still
> responsive?
>
> I've had this a few times (like, 2 or 3 times a -year-) on my system (FC3
> with 2.6.15.3 kernel) while using KDE and rendering. I've got an older KDE
> (3.3) and when the lockup happens my desktop freezes in total, I have to do
> the three finger salute (control-alt-backspace) to get back to a prompt. I
> start up in runlevel 3 always (text) so I drop back to a text terminal
> instead of GDM / its FC3 equivalent. But I do doubt if this has anything to
> do with Pov.
>
> Not that this helps a lot - in my experience, if POV tries to push my system
> too hard as regards memory (full physical and full virtual) it simply gets
> killed. This happened to me -once- only. My system got a bit unresponsive
> (as its memory resources where exhausted) but the moment the Pov process
> got killed it was back to normal. What kernel version are you using?
>
> As far as I know (if pov uses the normal libc calls for memory management)
> those are pretty robust and unlikely to fragment RAM badly enough to slow
> down the system or crash it.
>
> Best advice might be to render in runlevel 3 (text mode) and see if it still
> locks up? I usually do this - my system boots up in text mode, and I leave
> it in text mode for rendering in RL3. If I want to use the GUI, I simply
> start it up with "startx" in a terminal. Rendering like that (i. e. in text
> mode) I've never had any lockups. Are you sure your hardware is OK? I had a
> board with a flaky IDE interface once that did mostly what you described
> when I left it rendering overnight...
>
> Kind regards,
>
> --
> Stefan Viljoen
> Software Support Technician / Programmer
> Polar Design Solutions

Post a reply to this message