mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Greg KH <greg@kroah.com>
Cc: 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>,
	Andy Whitcroft <apw@shadowen.org>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [stable] 2.6.23 boot failures on x86-64.
Date: Mon, 29 Oct 2007 11:37:40 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.999.0710291123200.30120@woody.linux-foundation.org> (raw)
In-Reply-To: <20071029180739.GA17595@kroah.com>



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.

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.

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?

		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;

  reply	other threads:[~2007-10-29 18:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 17:50 Dave Jones
2007-10-29 18:07 ` [stable] " Greg KH
2007-10-29 18:37   ` Linus Torvalds [this message]
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
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=alpine.LFD.0.999.0710291123200.30120@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=apw@shadowen.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 \
    /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

all inboxes | Powered by JetHome®