From: Hugh Dickins A small change to the tests for "Bad page state", to avoid one class of the page_remove_rmap BUG reports, giving more information while letting the system continue: check page_mapcount (_mapcount != -1) rather than page_mapped (_mapcount >= 0). And how does _mapcount go bad? In the case under study, it looks sure now that an overheating(?) Pentium III sometimes gets confused by a pair of instructions in the no-buddy-bitmap __free_pages_bulk, and clears the PG_private bit from the _mapcount field while buddying around - changing PG_private value changes the bit cleared from _mapcount. Bad page state mapcount:-4096 would have tracked this down much sooner, and will be recognizable if other cpus show the same aberrant reaction to 2.6.11. The page_remove_rmap BUG does need to be replaced by more permissive and informative handling, but I'm not yet ready to to finalize such a patch. Please admit Colin Harrison to the Order of the Iridescent Penguin, for his tireless testing. Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton --- 25-akpm/mm/page_alloc.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN mm/page_alloc.c~bad-page-state-mapcount mm/page_alloc.c --- 25/mm/page_alloc.c~bad-page-state-mapcount 2005-03-02 17:09:30.000000000 -0800 +++ 25-akpm/mm/page_alloc.c 2005-03-02 17:09:30.000000000 -0800 @@ -276,7 +276,7 @@ static inline void __free_pages_bulk (st static inline void free_pages_check(const char *function, struct page *page) { - if ( page_mapped(page) || + if ( page_mapcount(page) || page->mapping != NULL || page_count(page) != 0 || (page->flags & ( @@ -404,7 +404,7 @@ void set_page_refs(struct page *page, in */ static void prep_new_page(struct page *page, int order) { - if (page->mapping || page_mapped(page) || + if (page->mapping || page_mapcount(page) || (page->flags & ( 1 << PG_private | 1 << PG_locked | _