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
next 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.