From: dann frazier <dannf@debian.org>
To: linux-ia64@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Rik van Riel <riel@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Nick Piggin <npiggin@suse.de>, Mel Gorman <mel@csn.ul.ie>,
Minchan Kim <minchan.kim@gmail.com>,
Ralf Baechle <ralf@linux-mips.org>
Subject: ia64 hang/mca running gdb 'make check'
Date: Tue, 20 Jul 2010 17:35:12 +0000 [thread overview]
Message-ID: <20100720173512.GF26783@ldl.fc.hp.com> (raw)
Debian's ia64 autobuilders have been experiencing system crashes while
trying to run the gdb test suite:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bugX8574
I was able to reproduce this w/ the latest git tree, and bisected it
down to this commit, introduced in 2.6.32:
commit 62eede62dafb4a6633eae7ffbeb34c60dba5e7b1
Author: Hugh Dickins <hugh.dickins@tiscali.co.uk>
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.
fyi, I found this to not be reproducible on SLES11 SP1 (which is
2.6.32-based). I compared the .configs and found that the relevant
difference is the PAGE_SIZE. It does not fail w/ 64KB pages, but
reliably fails w/ 16KB pages.
WARNING: multiple messages have this Message-ID (diff)
From: dann frazier <dannf@debian.org>
To: linux-ia64@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Rik van Riel <riel@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Nick Piggin <npiggin@suse.de>, Mel Gorman <mel@csn.ul.ie>,
Minchan Kim <minchan.kim@gmail.com>,
Ralf Baechle <ralf@linux-mips.org>
Subject: ia64 hang/mca running gdb 'make check'
Date: Tue, 20 Jul 2010 11:35:12 -0600 [thread overview]
Message-ID: <20100720173512.GF26783@ldl.fc.hp.com> (raw)
Debian's ia64 autobuilders have been experiencing system crashes while
trying to run the gdb test suite:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588574
I was able to reproduce this w/ the latest git tree, and bisected it
down to this commit, introduced in 2.6.32:
commit 62eede62dafb4a6633eae7ffbeb34c60dba5e7b1
Author: Hugh Dickins <hugh.dickins@tiscali.co.uk>
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.
fyi, I found this to not be reproducible on SLES11 SP1 (which is
2.6.32-based). I compared the .configs and found that the relevant
difference is the PAGE_SIZE. It does not fail w/ 64KB pages, but
reliably fails w/ 16KB pages.
next reply other threads:[~2010-07-20 17:35 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 17:35 dann frazier [this message]
2010-07-20 17:35 ` ia64 hang/mca running gdb 'make check' dann frazier
2010-07-21 1:51 ` KAMEZAWA Hiroyuki
2010-07-21 1:51 ` KAMEZAWA Hiroyuki
2010-07-21 3:06 ` dann frazier
2010-07-21 3:06 ` dann frazier
2010-07-21 4:19 ` Hugh Dickins
2010-07-21 4:19 ` Hugh Dickins
2010-07-21 12:54 ` KOSAKI Motohiro
2010-07-21 12:54 ` KOSAKI Motohiro
2010-07-27 7:19 ` dann frazier
2010-07-27 7:19 ` dann frazier
2010-07-27 9:03 ` KAMEZAWA Hiroyuki
2010-07-27 9:03 ` KAMEZAWA Hiroyuki
2010-07-27 14:43 ` dann frazier
2010-07-27 14:43 ` dann frazier
2010-07-29 3:50 ` Hugh Dickins
2010-07-29 3:50 ` Hugh Dickins
2010-07-29 19:22 ` dann frazier
2010-07-29 19:22 ` dann frazier
2010-07-30 0:41 ` KAMEZAWA Hiroyuki
2010-07-30 0:41 ` KAMEZAWA Hiroyuki
2010-07-30 2:01 ` Hugh Dickins
2010-07-30 2:01 ` Hugh Dickins
2010-07-30 4:34 ` dann frazier
2010-07-30 4:34 ` dann frazier
2010-07-30 17:52 ` Hugh Dickins
2010-07-30 17:52 ` Hugh Dickins
2010-07-30 17:58 ` [PATCH] mm: fix ia64 crash when gcore reads gate area Hugh Dickins
2010-07-30 17:58 ` Hugh Dickins
2010-07-29 7:38 ` ia64 hang/mca running gdb 'make check' Luming Yu
2010-07-29 7:38 ` Luming Yu
2010-07-29 7:58 ` KAMEZAWA Hiroyuki
2010-07-29 7:58 ` KAMEZAWA Hiroyuki
2010-07-29 8:40 ` Luming Yu
2010-07-29 8:40 ` Luming Yu
2010-07-29 8:44 ` KAMEZAWA Hiroyuki
2010-07-29 8:44 ` KAMEZAWA Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100720173512.GF26783@ldl.fc.hp.com \
--to=dannf@debian.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=npiggin@suse.de \
--cc=ralf@linux-mips.org \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.