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]
