All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: yhlu.kernel@gmail.com
Cc: Balbir, Kamalesh, kernel list <linux-kernel@vger.kernel.org>,
	Babulal <kamalesh@linux.vnet.ibm.com>,
	Yinghai Lu <yhlu.kernel.send@gmail.com>,
	linuxppc-dev@ozlabs.org, Badari Pulavarty <pbadari@us.ibm.com>,
	Ingo Molnar <mingo@elte.hu>, Singh <balbir@linux.vnet.ibm.com>
Subject: Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
Date: Wed, 2 Apr 2008 15:52:47 -0700	[thread overview]
Message-ID: <20080402155247.5e746be7.akpm@linux-foundation.org> (raw)
In-Reply-To: <200804021525.48799.yhlu.kernel@gmail.com>

On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:

> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> 
> on powerpc,
> 
> On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > 
> > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> >  > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> >  > > Andrew Morton wrote:
> >  > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >  > > >
> >  > > >> Hi Andrew,
> >  > > >>
> >  > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> >  > > >>
> >  > > >> [    0.000000] ------------[ cut here ]------------
> >  > > >> [    0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> >  > > >> [    0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> >  > > >> [    0.000000] SMP NR_CPUS=32 NUMA PowerMac
> >  > > >> [    0.000000] Modules linked in:
> >  > > >> [    0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> >  > > >> [    0.000000] REGS: c00000000049b960 TRAP: 0700   Not tainted  (2.6.25-rc8-mm1-autokern1)
> >  > > >> [    0.000000] MSR: 9000000000021032 <ME,IR,DR>  CR: 44000088  XER: 20000000
> >  > > >> [    0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> >  > > >> [    0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> >  > > >> [    0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> >  > > >> [    0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> >  > > >> [    0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> >  > > >> [    0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >  > > >> [    0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> >  > > >> [    0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> >  > > >> [    0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> >  > > >> [    0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> >  > > >> [    0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> >  > > >> [    0.000000] Call Trace:
> >  > > >> [    0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> >  > > >> [    0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> >  > > >> [    0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> >  > > >> [    0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> >  > > >> [    0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> >  > > >> [    0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> >  > > >> [    0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> >  > > >> [    0.000000] Instruction dump:
> >  > > >> [    0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> >  > > >> [    0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> >  > > >> [    0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> >  > > >> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >
> >  mm-make-mem_map-allocation-continuous.patch
> >  and its friends in -mm.
> >  
> >  You have to call sparse_init_one_section() on each pmap and usemap
> >  as we allocate - since valid_section() depends on it (which is needed
> >  by vmemmap_populate() to check if the section is populated or not).
> >  On ppc, we need to call htab_bolted_mapping() on each section and
> >  we need to skip existing sections.
> >  
> >  These patches tried to group all allocations together and then later
> >  calls sparse_init_one_section() - which is not good :(
> 
> so try to allocate usemap at first altogether.

I have to turn all the above crud into a proper changelog.  I'd prefer that
you do it.

Unless this patch should be folded into another one, in which case it
doesn't matter.

> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
> 
> diff --git a/mm/sparse.c b/mm/sparse.c
> index d3cb085..782ebe5 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c

We shouldn't merge this patch on its own because then that will leave a
non-bisectable region in the powerpc history.

So which patch is this patch fixing?  Lexically it applies to
mm-allocate-section_map-for-sparse_init.patch (and its updates).  But is
that where it logically lies?

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: yhlu.kernel@gmail.com
Cc: Yinghai Lu <yhlu.kernel.send@gmail.com>,
	Ingo Molnar <mingo@elte.hu>,
	Badari Pulavarty <pbadari@us.ibm.com>,
	michael@ellerman.id.au,
	Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
	linuxppc-dev@ozlabs.org, Balbir Singh <balbir@linux.vnet.ibm.com>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
Date: Wed, 2 Apr 2008 15:52:47 -0700	[thread overview]
Message-ID: <20080402155247.5e746be7.akpm@linux-foundation.org> (raw)
In-Reply-To: <200804021525.48799.yhlu.kernel@gmail.com>

On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:

> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> 
> on powerpc,
> 
> On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > 
> > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> >  > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> >  > > Andrew Morton wrote:
> >  > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >  > > >
> >  > > >> Hi Andrew,
> >  > > >>
> >  > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> >  > > >>
> >  > > >> [    0.000000] ------------[ cut here ]------------
> >  > > >> [    0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> >  > > >> [    0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> >  > > >> [    0.000000] SMP NR_CPUS=32 NUMA PowerMac
> >  > > >> [    0.000000] Modules linked in:
> >  > > >> [    0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> >  > > >> [    0.000000] REGS: c00000000049b960 TRAP: 0700   Not tainted  (2.6.25-rc8-mm1-autokern1)
> >  > > >> [    0.000000] MSR: 9000000000021032 <ME,IR,DR>  CR: 44000088  XER: 20000000
> >  > > >> [    0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> >  > > >> [    0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> >  > > >> [    0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> >  > > >> [    0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> >  > > >> [    0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> >  > > >> [    0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >  > > >> [    0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> >  > > >> [    0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> >  > > >> [    0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> >  > > >> [    0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> >  > > >> [    0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> >  > > >> [    0.000000] Call Trace:
> >  > > >> [    0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> >  > > >> [    0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> >  > > >> [    0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> >  > > >> [    0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> >  > > >> [    0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> >  > > >> [    0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> >  > > >> [    0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> >  > > >> [    0.000000] Instruction dump:
> >  > > >> [    0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> >  > > >> [    0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> >  > > >> [    0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> >  > > >> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >
> >  mm-make-mem_map-allocation-continuous.patch
> >  and its friends in -mm.
> >  
> >  You have to call sparse_init_one_section() on each pmap and usemap
> >  as we allocate - since valid_section() depends on it (which is needed
> >  by vmemmap_populate() to check if the section is populated or not).
> >  On ppc, we need to call htab_bolted_mapping() on each section and
> >  we need to skip existing sections.
> >  
> >  These patches tried to group all allocations together and then later
> >  calls sparse_init_one_section() - which is not good :(
> 
> so try to allocate usemap at first altogether.

I have to turn all the above crud into a proper changelog.  I'd prefer that
you do it.

Unless this patch should be folded into another one, in which case it
doesn't matter.

> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
> 
> diff --git a/mm/sparse.c b/mm/sparse.c
> index d3cb085..782ebe5 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c

We shouldn't merge this patch on its own because then that will leave a
non-bisectable region in the powerpc history.

So which patch is this patch fixing?  Lexically it applies to
mm-allocate-section_map-for-sparse_init.patch (and its updates).  But is
that where it logically lies?


  reply	other threads:[~2008-04-02 22:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-02 22:25 [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init Yinghai Lu
2008-04-02 22:25 ` Yinghai Lu
2008-04-02 22:52 ` Andrew Morton [this message]
2008-04-02 22:52   ` Andrew Morton
2008-04-03  0:44   ` Yinghai Lu
2008-04-03  0:44     ` Yinghai Lu
2008-04-03  1:30     ` [PATCH] mm: make mem_map allocation continuous v2 Yinghai Lu
2008-04-03  1:30       ` Yinghai Lu
2008-04-03  2:22       ` Andrew Morton
2008-04-03  2:22         ` Andrew Morton
2008-04-03  4:16         ` Yinghai Lu
2008-04-03  4:16           ` Yinghai Lu
2008-04-03 10:49           ` Kamalesh Babulal
2008-04-03 10:49             ` Kamalesh Babulal
2008-04-03  3:22       ` Yasunori Goto
2008-04-03  3:22         ` Yasunori Goto
2008-04-03  1:43     ` [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init Yinghai Lu
2008-04-03  1:43       ` Yinghai Lu
2008-04-02 23:51 ` Badari Pulavarty
2008-04-02 23:51   ` Badari Pulavarty
2008-04-03  0:47   ` Yinghai Lu
2008-04-03  0:47     ` Yinghai Lu

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=20080402155247.5e746be7.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=pbadari@us.ibm.com \
    --cc=yhlu.kernel.send@gmail.com \
    --cc=yhlu.kernel@gmail.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 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.