mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Hans Rosenfeld <hans.rosenfeld@amd.com>
Cc: Conny Seidel <conny.seidel@amd.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 32bit NUMA and fakeNUMA broken for AMD CPUs
Date: Wed, 29 Jun 2011 11:44:51 +0200	[thread overview]
Message-ID: <20110629094451.GJ3386@htj.dyndns.org> (raw)
In-Reply-To: <20110628174613.GP478@escobedo.osrc.amd.com>

(cc'ing x86 and lkml.  Please keep them cc'd on x86 related issues).

Hello,

On Tue, Jun 28, 2011 at 07:46:14PM +0200, Hans Rosenfeld wrote:
> We found another related but different panic on a 4-socket 8-node system,
> caused by this commit:
> 
>     commit 2706a0bf7b02693ed88752df877f10c2206292ff
>     Author: Tejun Heo <tj@kernel.org>
>     Date:   Mon May 2 17:24:48 2011 +0200
> 
>     x86, NUMA: Enable CONFIG_AMD_NUMA on 32bit too
>     
>     Now that NUMA init path is unified, amdtopology can be enabled on
>     32bit.  Make amdtopology.c safe on 32bit by explicitly using u64 and
>     drop X86_64 dependency from Kconfig.
>     
>     Inclusion of bootmem.h is added for max_pfn declaration.
>     
>     Signed-off-by: Tejun Heo <tj@kernel.org>
>     Cc: Ingo Molnar <mingo@redhat.com>
>     Cc: Yinghai Lu <yinghai@kernel.org>
>     Cc: David Rientjes <rientjes@google.com>
>     Cc: Thomas Gleixner <tglx@linutronix.de>
>     Cc: "H. Peter Anvin" <hpa@zytor.com>
> 
> 
> The fix for the other panic does not fix this one.
> Full bootlog and config are attached.

Hmmm, interesting.

> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  BIOS-e820: 0000000000000000 - 0000000000087800 (usable)
> [    0.000000]  BIOS-e820: 0000000000087800 - 00000000000a0000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000cc000 - 0000000000100000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000100000 - 00000000c7e70000 (usable)
> [    0.000000]  BIOS-e820: 00000000c7e70000 - 00000000c7e8c000 (ACPI data)
> [    0.000000]  BIOS-e820: 00000000c7e8c000 - 00000000c7e8e000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000c7e8e000 - 00000000c8000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
> [    0.000000]  BIOS-e820: 0000000100000000 - 0000001838000000 (usable)

Okay, a fairly large machine.  Memory goes over PAE limit.

> [    0.000000] Scanning NUMA topology in Northbridge 24
> [    0.000000] Number of physical nodes 8
> [    0.000000] Node 0 MemBase 0000000000000000 Limit 0000000238000000
> [    0.000000] Node 1 MemBase 0000000238000000 Limit 0000000638000000
> [    0.000000] Node 2 MemBase 0000000638000000 Limit 0000000838000000
> [    0.000000] Node 3 MemBase 0000000838000000 Limit 0000000c38000000
> [    0.000000] Node 4 MemBase 0000000c38000000 Limit 0000000e38000000
> [    0.000000] Node 5 MemBase 0000000e38000000 Limit 0000001000000000
> [    0.000000] Node 6 bogus settings 1238000000-1000000000.
> [    0.000000] Node 7 bogus settings 1438000000-1000000000.

amdtopology code behaved correctly.  It trimmed node 5 which spans
over the PAE limit and squashed nodes above that.

> [    0.000000] BUG: Int 6: CR2   (null)
> [    0.000000]      EDI   (null)  ESI 00000002  EBP 00000002  ESP c1543ecc
> [    0.000000]      EBX f2400000  EDX 00000006  ECX   (null)  EAX 00000001
> [    0.000000]      err   (null)  EIP c16209aa   CS 00000060  flg 00010002
> [    0.000000] Stack: f2400000 00220000 f7200800 c1620613 00220000 01000000 04400000 00238000
> [    0.000000]          (null) f7200000 00000002 f7200b58 f7200800 c1620929 000375fe   (null)
> [    0.000000]        f7200b80 c16395f0 00200a02 f7200a80   (null) 000375fe 00000002   (null)
> [    0.000000] Pid: 0, comm: swapper Not tainted 2.6.39-rc5-00181-g2706a0b #17
> [    0.000000] Call Trace:
> [    0.000000]  [<c136b1e5>] ? early_fault+0x2e/0x2e
> [    0.000000]  [<c16209aa>] ? mminit_verify_page_links+0x12/0x42
> [    0.000000]  [<c1620613>] ? memmap_init_zone+0xaf/0x10c
> [    0.000000]  [<c1620929>] ? free_area_init_node+0x2b9/0x2e3
> [    0.000000]  [<c1607e99>] ? free_area_init_nodes+0x3f2/0x451
> [    0.000000]  [<c1601d80>] ? paging_init+0x112/0x118
> [    0.000000]  [<c15f578d>] ? setup_arch+0x791/0x82f
> [    0.000000]  [<c15f43d9>] ? start_kernel+0x6a/0x257

But it later tripped in mminit_verify_page_links().  Maybe
page_to_nid() doesn't match?

Hmmm... I can't see how it would have worked before.  amdtopology used
ulong for @end and would simply have been zero.  Maybe NUMA config
failed and it booted as flatmem instead?  Can you please post boot log
before the patch?

Also, can you please apply the following patch, reproduce the boot
failure and post the log?  Thank you.


diff --git a/mm/mm_init.c b/mm/mm_init.c
index 4e0e265..cb230bf 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -124,6 +124,12 @@ void __init mminit_verify_pageflags_layout(void)
 void __meminit mminit_verify_page_links(struct page *page, enum zone_type zone,
 			unsigned long nid, unsigned long pfn)
 {
+	if (page_to_nid(page) != nid || page_zonenum(page) != zone ||
+	    page_to_pfn(page) != pfn)
+		printk(KERN_CRIT "mminit_verify_page_links: nid=%lu/%lu zone=%d/%d pfn=0x%lx/0x%lx\n",
+		       page_to_nid(page), nid, page_zonenum(page), zone,
+		       page_to_pfn(page), pfn);
+
 	BUG_ON(page_to_nid(page) != nid);
 	BUG_ON(page_zonenum(page) != zone);
 	BUG_ON(page_to_pfn(page) != pfn);

  parent reply	other threads:[~2011-06-29  9:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-21 15:41 Conny Seidel
2011-06-26 10:22 ` Tejun Heo
     [not found]   ` <20110626223807.47cef5c6.conny.seidel_amd.com@marah.osrc.amd.com>
2011-06-28  9:41     ` [PATCH tip:x86/urgent] x86-32, NUMA: Fix boot regression caused by NUMA init unification on highmem machines Tejun Heo
2011-06-28 12:35       ` Conny Seidel
2011-07-01 15:26       ` [tip:x86/urgent] " tip-bot for Tejun Heo
     [not found]     ` <20110628174613.GP478@escobedo.osrc.amd.com>
2011-06-29  9:44       ` Tejun Heo [this message]
2011-06-29 10:51         ` 32bit NUMA and fakeNUMA broken for AMD CPUs Tejun Heo
2011-06-29 12:34         ` Tejun Heo
2011-06-29 12:55           ` Hans Rosenfeld
2011-06-29 13:03             ` Tejun Heo
2011-06-29 16:15               ` Tejun Heo
2011-06-30 13:13                 ` Hans Rosenfeld
2011-06-30 15:55                   ` Tejun Heo
2011-06-30 16:32                     ` Hans Rosenfeld
2011-06-30 16:42                       ` Tejun Heo
2011-06-30 17:04                         ` Hans Rosenfeld
2011-07-01 16:22         ` [PATCH x86/urgent 1/2] x86: s/PAGES_PER_ELEMENT/PAGES_PER_SECTION/ Tejun Heo
2011-07-01 16:23           ` [PATCH x86/urgent 2/2] x86: Implement pfn -> nid mapping granularity check Tejun Heo
2011-07-09  8:32             ` Tejun Heo
2011-07-09  8:42               ` H. Peter Anvin
2011-07-11  8:34                 ` [PATCH x86/urgent] x86: Disable AMD_NUMA for 32bit for now Tejun Heo
2011-07-11 14:01                   ` Tejun Heo
2011-07-11 18:58                   ` [tip:x86/urgent] " tip-bot for Tejun Heo
2011-07-11 14:20                 ` [PATCH x86/urgent 2/2] x86: Implement pfn -> nid mapping granularity check Hans Rosenfeld
2011-07-13  5:34       ` [tip:x86/numa] x86, numa: " tip-bot for Tejun Heo
2011-07-12  7:44 [PATCH x86/mm 1/2] x86: s/PAGES_PER_ELEMENT/PAGES_PER_SECTION/ Tejun Heo
2011-07-12  7:45 ` [PATCH x86/mm 2/2] x86: Implement pfn -> nid mapping granularity check Tejun Heo
2011-07-13  5:33 ` [tip:x86/numa] x86, mm: s/PAGES_PER_ELEMENT/PAGES_PER_SECTION/ tip-bot for Tejun Heo

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=20110629094451.GJ3386@htj.dyndns.org \
    --to=tj@kernel.org \
    --cc=conny.seidel@amd.com \
    --cc=hans.rosenfeld@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@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 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®