All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Suzuki K. Poulose" <suzuki@in.ibm.com>
To: kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org
Cc: Matthew McClintock <msm@freescale.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Handling spin table in kdump
Date: Tue, 22 May 2012 18:12:10 +0530	[thread overview]
Message-ID: <4FBB89A2.90709@in.ibm.com> (raw)

Hi

I came across the following issue while testing Kdump on an SMP 
board(Currituck) running a non-SMP kernel. Even though the kernel is UP,
the device-tree has the nodes for second CPU and the related details.


The kexec tool adds the spin table area as a reserved section in the 
device tree for the dump capture kernel. This value is read from the 
'cpu-release-addr'.

But now, if the spin table is not located within the 'Reserved region' 
for the crash kernel, the dump capture kernel would fail to boot, 
hitting a BUG in mm/bootmem.c as in [1].

This is because we try to reserve a region which is not available to the 
kernel.

So I am wondering how is this handled really on an SMP board (Fsl_bookE).

There are two possible solutions :
1) Do not reserve the regions for the spin-table, as we will use
only the crashing CPU in the second kernel(maxcpus=1).


2) Add the spin-table region to the available memory regions passed
to the kernel by kexec-tools.

I have tested (1) and it works fine for me. Yet to test (2).


Thoughts ?


Thanks
Suzuki



[1] Kernel Bug
----------------


Linux version 3.3.0-rc5 (root@suzukikp.in.ibm.com) (gcc version 4.3.4 
[gcc-4_3-branch revision 152973] (GCC) ) #12 Tue May 22 18:03:01 IST2
Found legacy serial port 0 for /plb/opb/serial@10000000
   mem=20010000000, taddr=20010000000, irq=0, clk=1851851, speed=115200
------------[ cut here ]------------
kernel BUG at mm/bootmem.c:351!
Vector: 700 (Program Check) at [c8a61e90]
     pc: c847f91c: mark_bootmem+0xa0/0x14c
     lr: c8472670: do_init_bootmem+0x1ac/0x218
     sp: c8a61f40
    msr: 21000
   current = 0xc8a4a500
     pid   = 0, comm = swapper
kernel BUG at mm/bootmem.c:351!
enter ? for help
[c8a61f70] c8472670 do_init_bootmem+0x1ac/0x218
[c8a61f90] c847025c setup_arch+0x1bc/0x234
[c8a61fb0] c846b62c start_kernel+0x98/0x358
[c8a61ff0] c80000b4 _start+0xb4/0xf8


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: "Suzuki K. Poulose" <suzuki@in.ibm.com>
To: kexec@lists.infradead.org, linuxppc-dev@lists.ozlabs.org
Cc: Matthew McClintock <msm@freescale.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Handling spin table in kdump
Date: Tue, 22 May 2012 18:12:10 +0530	[thread overview]
Message-ID: <4FBB89A2.90709@in.ibm.com> (raw)

Hi

I came across the following issue while testing Kdump on an SMP 
board(Currituck) running a non-SMP kernel. Even though the kernel is UP,
the device-tree has the nodes for second CPU and the related details.


The kexec tool adds the spin table area as a reserved section in the 
device tree for the dump capture kernel. This value is read from the 
'cpu-release-addr'.

But now, if the spin table is not located within the 'Reserved region' 
for the crash kernel, the dump capture kernel would fail to boot, 
hitting a BUG in mm/bootmem.c as in [1].

This is because we try to reserve a region which is not available to the 
kernel.

So I am wondering how is this handled really on an SMP board (Fsl_bookE).

There are two possible solutions :
1) Do not reserve the regions for the spin-table, as we will use
only the crashing CPU in the second kernel(maxcpus=1).


2) Add the spin-table region to the available memory regions passed
to the kernel by kexec-tools.

I have tested (1) and it works fine for me. Yet to test (2).


Thoughts ?


Thanks
Suzuki



[1] Kernel Bug
----------------


Linux version 3.3.0-rc5 (root@suzukikp.in.ibm.com) (gcc version 4.3.4 
[gcc-4_3-branch revision 152973] (GCC) ) #12 Tue May 22 18:03:01 IST2
Found legacy serial port 0 for /plb/opb/serial@10000000
   mem=20010000000, taddr=20010000000, irq=0, clk=1851851, speed=115200
------------[ cut here ]------------
kernel BUG at mm/bootmem.c:351!
Vector: 700 (Program Check) at [c8a61e90]
     pc: c847f91c: mark_bootmem+0xa0/0x14c
     lr: c8472670: do_init_bootmem+0x1ac/0x218
     sp: c8a61f40
    msr: 21000
   current = 0xc8a4a500
     pid   = 0, comm = swapper
kernel BUG at mm/bootmem.c:351!
enter ? for help
[c8a61f70] c8472670 do_init_bootmem+0x1ac/0x218
[c8a61f90] c847025c setup_arch+0x1bc/0x234
[c8a61fb0] c846b62c start_kernel+0x98/0x358
[c8a61ff0] c80000b4 _start+0xb4/0xf8

             reply	other threads:[~2012-05-22 13:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-22 12:42 Suzuki K. Poulose [this message]
2012-05-22 12:42 ` Handling spin table in kdump Suzuki K. Poulose
2012-05-22 15:34 ` McClintock Matthew-B29882
2012-05-22 15:34   ` McClintock Matthew-B29882
2012-05-24  6:09   ` [PATCH] [ppc] Do not reserve cpu spin-table for crash kernel Suzuki K. Poulose
2012-05-24  6:09     ` Suzuki K. Poulose
2012-06-18  6:27     ` Suzuki K. Poulose
2012-06-18  6:27       ` Suzuki K. Poulose
2012-06-25 11:17       ` Suzuki K. Poulose
2012-07-05  7:56         ` Suzuki K. Poulose
2012-07-13  6:31           ` Simon Horman
2012-07-13  6:33     ` Simon Horman
2012-07-13  6:33       ` Simon Horman

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=4FBB89A2.90709@in.ibm.com \
    --to=suzuki@in.ibm.com \
    --cc=bigeasy@linutronix.de \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=msm@freescale.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.