Re: out of memory in 2.0.30...

Dan Merillat (dan@merillat.org)
Mon, 19 May 1997 12:18:43 -0400

Stephen Costaras writes:
> > I have 64 megs of real memory, and nothing can get a free page...
> > Here's a procinfo when it happened:
>
> {system information snipped}
>
> > Looks like the kernel is aggressivly paging programs out to make room for
> > buffer cache... to the point that I can't compile (gcc: exausted virtual me
mory)dmesg only has complaints about being unable to allocate a DMA buffer for
> > sound. I see the latest stable version is still 2.0.30... is there a pre-
31
> > patch out I could test?
> >
> > BTW: I can also reliably bring a completely unloaded 2.0.30 box to it's kne
es
> > by doing badblocks -w on a scsi device (obviously, one with nothing importa
nt
> > on it.) I have yet to be able to check the disk, since it runs out of
> > memory (with plenty of swap free) before it finishes checking...
>
> I have seen similar problems on my news server running 2.0.30 w/ 128mb ram +
> 128mb swap. It appears that the kernel kills off the processes (couldn't get
> a free page) and doesn't even attempt to use the swap. (only have 2000-3000k
b
> used out of the 128meg swap partition). I'm back to 2.0.29 as well for the
> interim.

I tried that, 2.0.29 got lots of nasty messages:
eth0: Couldn't allocate a sk_buff of size 246.
Couldn't get a free page.....
eth0: Couldn't allocate a sk_buff of size 258.
Couldn't get a free page.....
eth0: Couldn't allocate a sk_buff of size 92.
eth0: Couldn't allocate a sk_buff of size 92.
Couldn't get a free page.....
eth0: Couldn't allocate a sk_buff of size 228.

this was doing badblocks -w, but at least it completed.

I'm not sure if it was a totally clean 2.0.29, I'll redownload the source
and recompile if someone thinks these results are strange.

--Dan