From: Adam Litke <agl@us.ibm.com>
To: Bill Irwin <bill.irwin@oracle.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
akpm@linux-foundation.org
Subject: Re: Kernel Oops with shm namespace cleanups
Date: Fri, 02 Mar 2007 10:29:16 -0600 [thread overview]
Message-ID: <1172852957.12220.4.camel@localhost.localdomain> (raw)
In-Reply-To: <20070302000808.GE10643@holomorphy.com>
On Thu, 2007-03-01 at 16:08 -0800, Bill Irwin wrote:
> On Wed, Feb 28, 2007 at 02:13:29PM -0600, Adam Litke wrote:
> > Hey. While testing 2.6.21-rc2 with libhugetlbfs, the shm-fork test case
> > causes the kernel to oops. To reproduce: Execute 'make check' in the
> > latest libhugetlbfs source on a 2.6.21-rc2 kernel with 100 huge pages
> > allocated. Using fewer huge pages will likely also trigger the oops.
> > Libhugetlbfs can be downloaded from:
> > http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070228.tar.gz
>
> Looks like I should grab these testcases for the sake of due diligence
> (not to say I intend to alter maintenance style from primarily review,
> approval, and bugfixing, not that I've been doing as much of any of those
> as I should). To which architectures and/or distributions have the
> userspace bits been ported, or otherwise run/tested on? A quick sniff
> test on an Altix suggests SLES and/or ia64 may trip up the scripts:
Right now we support x86, powerpc, and x86_64. Segment remapping and
hugetlb malloc won't work on ia64 until long format vhpt is supported (I
suspect). But the test framework should be adaptable to other
architectures.
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
next prev parent reply other threads:[~2007-03-02 16:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-28 20:13 Kernel Oops with shm namespace cleanups Adam Litke
2007-03-01 0:57 ` Eric W. Biederman
2007-03-02 0:08 ` Bill Irwin
2007-03-02 16:29 ` Adam Litke [this message]
2007-03-02 21:58 ` Bill Irwin
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=1172852957.12220.4.camel@localhost.localdomain \
--to=agl@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bill.irwin@oracle.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
/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.