From: Dave Jones <davej@redhat.com>
To: Andi Kleen <ak@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Martin Ebourne <fedora@ebourne.me.uk>,
Zou Nan hai <nanhai.zou@intel.com>,
Suresh Siddha <suresh.b.siddha@intel.com>,
stable@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: 2.6.23 boot failures on x86-64.
Date: Mon, 29 Oct 2007 15:43:11 -0400 [thread overview]
Message-ID: <20071029194311.GE1650@redhat.com> (raw)
In-Reply-To: <200710292003.09317.ak@suse.de>
On Mon, Oct 29, 2007 at 08:03:09PM +0100, Andi Kleen wrote:
> > > It's probably the usual "nobody tests sparsemem at all" issue.
> >
> > We've been using SPARSEMEM in Fedora for a *long* time.
> > So long in fact, I forget why we moved away from DISCONTIGMEM, so there's
> > a significant number of users using that configuration for some time.
>
> Supposedly you wanted a slower kernel that needs more memory?
>
> Ok I wasn't aware of that. I tended to get sparsemem reports usually
> at least 1-2 releases after the fact, so it looked like it was undertested.
Looking at cvs history, I can't figure out what the reasoning was,
but every Fedora (and RHEL5) kernel since 2006/07/05 has been that way.
Curious how no-one noticed either of the side-effects you mention.
> > > But if allocating bootmem >4G doesn't work on these systems
> > > most likely they have more problems anyways. It might be better
> > > to find out what goes wrong exactly.
> > Any ideas on what to instrument ?
>
> See what address the bootmem_alloc_high returns; check if it overlaps
> with something etc.
>
> Fill the memory on the system and see if it can access all of its memory.
Martin, as you have one of the affected systems, do you feel up to this?
Dave
--
http://www.codemonkey.org.uk
next prev parent reply other threads:[~2007-10-29 19:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-29 17:50 2.6.23 boot failures on x86-64 Dave Jones
2007-10-29 18:07 ` [stable] " Greg KH
2007-10-29 18:37 ` Linus Torvalds
2007-10-29 19:51 ` Christoph Lameter
2007-10-29 19:52 ` Siddha, Suresh B
2007-10-29 20:09 ` Christoph Lameter
2007-10-29 20:23 ` Andy Whitcroft
2007-10-29 20:27 ` Martin Ebourne
2007-10-29 18:18 ` Andi Kleen
2007-10-29 18:47 ` Dave Jones
2007-10-29 19:03 ` Andi Kleen
2007-10-29 19:43 ` Dave Jones [this message]
2007-10-29 19:56 ` Andi Kleen
2007-10-29 21:21 ` Martin Ebourne
2007-10-31 6:04 ` Zou Nan hai
2007-10-31 6:19 ` Zou Nan hai
2007-10-29 20:06 ` Dave Jones
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=20071029194311.GE1650@redhat.com \
--to=davej@redhat.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=fedora@ebourne.me.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=nanhai.zou@intel.com \
--cc=stable@kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox