On Tue, 29 Apr 1997, Ingo Molnar wrote:
> > Seeing as I have been having the same signal 7 problems that others
> > reported, I applied Ingo's patch and did:
> >
> > [root@Sleepy linux-2.1.36]# make zImage MAKE="make -j20"
> >
> > It went for a while, then died like this:
> >
> > gcc -D__KERNEL__ -I/usr/src/linux-2.1.36/include -Wall -Wstrict-prototypes
> > -O2 -fomit-frame-pointer -D__SMP__ -pipe -fno-strength-reduce -m486
> > -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586 -D__SMP__
> > -c -o dcache.o dcache.c
> > SIGBUS: ayiee, couldnt allocate page table.
> > gcc: Internal compiler error: program cc1 got fatal signal 7
>
> could you try "echo 128 256 512 > /proc/sys/vm/freepages" ?
I restarted my tests with bigger values for freepages. As I expected, the
problem did not show up that often, but it did show up. I got signal 7
once in about 4 hours. Before increasing freepages I got the error four
times in five hours:
------------------------------------------------------------------------
Apr 29 17:10:34 Celsius kernel: SIGBUS: ayiee, couldnt allocate page table.
Celsius:/usr/src/linux-2.0.30 # cat /proc/sys/vm/freepages
200 300 400
------------------------------------------------------------------------
Now I can increase freepages again. But IMHO that is no solution.
BTW: If I start that much processes that virtual memory gets exhausted, I
get the message "Virtual memory exhausted". This is correct. I think it is
_not_ correct to send signal 7 to some process, when there is lots of
unused swap. I get the feeling that under certain circumstances the kernel
"forgets" that it could free up some memory or start swapping.
Another thing: Problems seem not to be related to high NFS traffic. The
affected machine currently does practically no networking at all. It just
compiles kernels...
> -- mingo
Hubert mantel@suse.de