I was able to easily reproduce it by running 'make check'. The first test case (gcore) reliably fails with either a system hang or an MCA.
Bisect shows that it was introduced by the following commit: 62eede62dafb4a6633eae7ffbeb34c60dba5e7b1 is the first bad commit commit 62eede62dafb4a6633eae7ffbeb34c60dba5e7b1 Author: Hugh Dickins <[email protected]> Date: Mon Sep 21 17:03:34 2009 -0700 mm: ZERO_PAGE without PTE_SPECIAL Reinstate anonymous use of ZERO_PAGE to all architectures, not just to those which __HAVE_ARCH_PTE_SPECIAL: as suggested by Nick Piggin. Contrary to how I'd imagined it, there's nothing ugly about this, just a zero_pfn test built into one or another block of vm_normal_page(). But the MIPS ZERO_PAGE-of-many-colours case demands is_zero_pfn() and my_zero_pfn() inlines. Reinstate its mremap move_pte() shuffling of ZERO_PAGEs we did from 2.6.17 to 2.6.19? Not unless someone shouts for that: it would have to take vm_flags to weed out some cases. Signed-off-by: Hugh Dickins <[email protected]> Cc: Rik van Riel <[email protected]> Reviewed-by: KAMEZAWA Hiroyuki <[email protected]> Cc: KOSAKI Motohiro <[email protected]> Cc: Nick Piggin <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Ralf Baechle <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> I also checked SLES11 SP1, but this issue was not reproducible. I went through the config differences & found that the relevant difference is PAGE_SIZE. For whatever reason, 64KB pages (which SLES uses) masks the issue, while 16KB (Debian) does not. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
