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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- +---------------------------------------------------------+ | Ron Johnson, Jr. Home: [EMAIL PROTECTED] | | 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]