All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Dave Jones <davej@redhat.com>
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 20:03:09 +0100	[thread overview]
Message-ID: <200710292003.09317.ak@suse.de> (raw)
In-Reply-To: <20071029184747.GB1650@redhat.com>

On Monday 29 October 2007 19:47:47 Dave Jones wrote:
> On Mon, Oct 29, 2007 at 07:18:43PM +0100, Andi Kleen wrote:
>  > On Monday 29 October 2007 18:50:14 Dave Jones wrote:
>  > > We've had a number of people reporting that their x86-64s stopped booting
>  > > when they moved to 2.6.23.  It rebooted just after discovering the AGP bridge
>  > > as a result of the IOMMU init.
>  > 
>  > 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.

> 
>  > 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.

-Andi

  reply	other threads:[~2007-10-29 19:03 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 [this message]
2007-10-29 19:43       ` Dave Jones
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=200710292003.09317.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --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 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.