public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Greg KH <greg@kroah.com>, Dave Jones <davej@redhat.com>,
	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>,
	Andi Kleen <ak@suse.de>,
	stable@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
	Christoph Lameter <clameter@sgi.com>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [stable] 2.6.23 boot failures on x86-64.
Date: Mon, 29 Oct 2007 20:23:11 +0000	[thread overview]
Message-ID: <20071029202311.GO5529@shadowen.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0710291123200.30120@woody.linux-foundation.org>

On Mon, Oct 29, 2007 at 11:37:40AM -0700, Linus Torvalds wrote:
> 
> 
> On Mon, 29 Oct 2007, Greg KH wrote:
> > 
> > I'll be glad to revert it in -stable, if it's also reverted in Linus's
> > tree first :)
> 
> We've had some changes since 2.6.23, and afaik, the 
> "alloc_bootmem_high_node()" code is alreadt effectively dead there. It's 
> only called if CONFIG_SPARSEMEM_VMEMMAP is *not* enabled, and I *think* we 
> enable it by force on x86-64 these days.

CONFIG_SPARSEMEM_VMEMMAP is the default when SPARSEMEM is enabled
on x86_64.   The overall default remains DISCONTIGMEM, mainly as a
safety measure while the i386/x86_64 => x86 merge stablises.  But yes
this code is only used when SPARSEMEM is enabled but VMEMMAP is not.
So it is effectivly redundant.

> More people added to Cc, just to clarify whether I'm just confused.
> 
> Andy, Christoph, Mel: commit 2e1c49db4c640b35df13889b86b9d62215ade4b6 aka 
> "x86_64: allocate sparsemem memmap above 4G" is the one that causes the 
> failures, just fyi.

That patch seems to have a laudable goal of trying to push the memory
which backs the sparsemem memmap out to non-dma memory.  I would have
expected that call to actually succeed as the bootmem allocator seems to
try at the goal which would likely be outside the node on a small
machine, and then retry without a goal.  Which is what the code without
the goal does.  Most illogical.

> Martin - it would be great if you could try out your failing machine with 
> 2.6.24-rc1 (or a nightly snapshot or current git.. the more recent the 
> better).
> 
> But if I'm right, that commit should be reverted from 2.6.24 just because 
> it's pointless (even if the bug itself is gone). And if I'm wrong, it 
> should be reverted. So something like the appended would make sense 
> regardless.
> 
> Can I get a "tested-by"? And/or ack/nack's on my half-arsed theory above?

This code is definatly only used when SPARSEMEM is enabled, and VMEMMAP
is not which is not a combination we see on x86_64.

Acked-by: Andy Whitcroft <apw@shadowen.org>

> 		Linus
> --
> From: Linus Torvalds <torvalds@woody.linux-foundation.org>
> 
> Revert "x86_64: allocate sparsemem memmap above 4G"
> 
> This reverts commit 2e1c49db4c640b35df13889b86b9d62215ade4b6, since
> testing in Fedora has shown it to cause boot failures, as per Dave
> Jones. Bisected down by Martin Ebourne.
> 
> Cc: Dave Jones <davej@redhat.com>
> Cc: Martin Ebourne <fedora@ebourne.me.uk>
> Cc: Zou Nan hai <nanhai.zou@intel.com>
> Cc: Suresh Siddha <suresh.b.siddha@intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 1e3862e..a7308b2 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -728,12 +728,6 @@ int in_gate_area_no_task(unsigned long addr)
>  	return (addr >= VSYSCALL_START) && (addr < VSYSCALL_END);
>  }
>  
> -void * __init alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size)
> -{
> -	return __alloc_bootmem_core(pgdat->bdata, size,
> -			SMP_CACHE_BYTES, (4UL*1024*1024*1024), 0);
> -}
> -
>  const char *arch_vma_name(struct vm_area_struct *vma)
>  {
>  	if (vma->vm_mm && vma->vm_start == (long)vma->vm_mm->context.vdso)
> diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
> index c83534e..0365ec9 100644
> --- a/include/linux/bootmem.h
> +++ b/include/linux/bootmem.h
> @@ -59,7 +59,6 @@ extern void *__alloc_bootmem_core(struct bootmem_data *bdata,
>  				  unsigned long align,
>  				  unsigned long goal,
>  				  unsigned long limit);
> -extern void *alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size);
>  
>  #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
>  extern void reserve_bootmem(unsigned long addr, unsigned long size);
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 08fb14f..e06f514 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -220,12 +220,6 @@ static int __meminit sparse_init_one_section(struct mem_section *ms,
>  	return 1;
>  }
>  
> -__attribute__((weak)) __init
> -void *alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size)
> -{
> -	return NULL;
> -}
> -
>  static unsigned long usemap_size(void)
>  {
>  	unsigned long size_bytes;
> @@ -267,11 +261,6 @@ struct page __init *sparse_mem_map_populate(unsigned long pnum, int nid)
>  	if (map)
>  		return map;
>  
> -  	map = alloc_bootmem_high_node(NODE_DATA(nid),
> -                       sizeof(struct page) * PAGES_PER_SECTION);
> -	if (map)
> -		return map;
> -
>  	map = alloc_bootmem_node(NODE_DATA(nid),
>  			sizeof(struct page) * PAGES_PER_SECTION);
>  	return map;

-apw

  parent reply	other threads:[~2007-10-29 20:24 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 [this message]
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
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=20071029202311.GO5529@shadowen.org \
    --to=apw@shadowen.org \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=davej@redhat.com \
    --cc=fedora@ebourne.me.uk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --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