POV-Ray : Newsgroups : povray.unix : System lock-up: who's to blame? : Re: System lock-up: who's to blame? Server Time
26 Jun 2024 04:02:28 EDT (-0400)
  Re: System lock-up: who's to blame?  
From: Stefan Viljoen
Date: 2 Apr 2006 01:11:28
Message: <442f6b0f@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.