> Something like that. I've started getting SIGNAL 7 from GCC since
> upgrading to 2.0.30. This happens when I stress test the machine.
I got this on three different machines. Everybody would say that it's a
classical hardware problem (see http://www.bitwizard.nl/sig11), but too
many machines are affected so I cannot believe it's a hardware problem.
> (4 concurrent kernel builds with -j8) I'm not getting any NMIs - just
> SIGNAL 7. I've also gotten a few "Couldn't get a free page." Could that
> have anything to do with it?
I'm getting "Couldn't get a free page..." even on machines with 32MB RAM
and lots of unused swap. With 2.0.29 I never saw this on the affected
machines...
While playing around with different values for "freepages" I noticed
something in mm/page_alloc.c which seems to be the cause for my problems.
I'm currently testing a kernel with this patch applied:
------------------------------------------------------------------------
diff -urN linux-2.0.30/mm/page_alloc.c linux-2.0.30-test/mm/page_alloc.c
--- linux-2.0.30/mm/page_alloc.c Sat Aug 17 20:19:29 1996
+++ linux-2.0.30-test/mm/page_alloc.c Mon Apr 28 16:44:59 1997
@@ -202,8 +202,8 @@
priority = GFP_ATOMIC;
}
}
- reserved_pages = 5;
- if (priority != GFP_NFS)
+/* reserved_pages = 5;
+ if (priority != GFP_NFS) */
reserved_pages = min_free_pages;
save_flags(flags);
repeat:
------------------------------------------------------------------------
As I understand, whithout this patch, NFS will get memory even when there
are only 5 pages left. With this patch, there have to be reserved at least
reserved_pages pages, otherwise try_to_free_page will be called. I tried
this because I'm under the impression that the problems are triggered by
high network activity.
Of course, I don't really know what I'm doing. Can anyone explain why
there's a special handling when __get_free_pages is called with priority
GFP_NFS?
> Y.
Hubert mantel@suse.de