Re: fork() failing on athlon system
Since those are big images, and JPEGs are compressed, I presume
that when Gimp decompresses all of them into it's address space
(RAM+swap), that it runs out of resources.
Can you add another swap partition? I had to bump up from
256MB swap to 650MB swap when opening up some really big JPEGs,
even though I have 768MB RAM.
Also, as always, adding RAM, which is still pretty cheap,
_always_ helps when doing graphics work.
On Fri, 2002-05-31 at 10:21, Charles Briscoe-Smith wrote:
> Hi,
>
> Just a couple of (perhaps related) questions.
>
> The machine in question is a 800MHz Athlon box with 256MB RAM. It's
> running Linux 2.4.18-ac3 at present and Debian woody (I just finished
> upgrading everything to woody).
>
> Question 1: I heard about the Athlon/AGP cache-coherency bug and the
> machine has had "mem=nopentium" on its commandline since then. Is there
> a reliable fix/workaround in Linux 2.4.18(-ac3)? Can I remove the
> "mem=nopentium" safely?
>
> Question 2: The machine's main use is for running the Gimp. I have the
> Gimp's tile cache set to about 160MB, to encourage it to make use of
> the available RAM. However, it regularly packs up after a bit of work
> (typically after opening 4 2000x1312 JPEGs, cropping them a bit, adding
> a text layer and printing them). Using strace, I've determined that the
> problem is that fork(2) is returning ENOMEM. An invocation of free(1)
> just afterwards reports that there's somewhere in the region of 20MB+
> of free core and 50MB+ of free swap. The gimp process is about 160MB
> in size, with 150MB+ in core. According to the man page for fork(2),
> fork() should only be copying page tables and allocating a task struct.
>
> Could it be the case that, especially with "mem=nopentium" on the
> kernel command line, the Gimp process's page table is so huge that there
> genuinely isn't enough space for it? Or is it more likely that there's
> a limit set somwhere that's being exceeded? (I've checked ulimit -a,
> and the only one that looks like a possible problem is stack size, set
> at 8192. But exceeding that shouldn't cause fork() to fail like that
> should it?) I've browsed through /proc/sys, but I don't see anything
> obviously relevant. Any ideas what else I should check?
>
> Thanks,
>
> --
> Charles Briscoe-Smith Hacking Free Software for fun and profit
> "When you do things right, people won't be sure you've done anything at all."
> -- God, Futurama ep. 3ACV20, "Godfellas"
>
>
> --
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
+---------------------------------------------------------+
| Ron Johnson, Jr. Home: ron.l.johnson@cox.net |
| Jefferson, LA USA http://ronandheather.dhs.org:81 |
| |
| "I have created a government of whirled peas..." |
| Maharishi Mahesh Yogi, 12-May-2002, |
! CNN, Larry King Live |
+---------------------------------------------------------+
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: