Re: [PATCH] Reserve memory for kdump kernel within RMO region
Hi, As of now the kdump kernel base is fixed to be 32MB. The intention of this patch is to modify that behaviour (for relocatable kernels) * Regular kernel size may exceed 32MB, in this case we can't have kdump kernelbase as 32MB. * crashkernel=auto also assumes that kdump kernelbase as 32MB, and it may also fail in reserving memory for kdump kernel. On 11/27/2009 12:56 AM, Bernhard Walle wrote: M. Mohan Kumar schrieb: On 11/26/2009 12:22 AM, Bernhard Walle wrote: M. Mohan Kumar schrieb: Reserve memory for kdump kernel within RMO region When the kernel size exceeds 32MB(observed with some distros), memory for kdump kernel can not be reserved as kdump kernel base is assumed to be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled, provide the feature to reserve the memory for kdump kernel anywhere in the RMO region. Hi Bernhard, Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that gets loaded as crashkernel, not for the kernel that loads the crashkernel. So it would be perfectly fine that a kernel that has not CONFIG_RELOCATABLE set would load another kernel that has CONFIG_RELOCATABLE set on an address != 32 M. No, with relocatable option, the same kernel is used as both production and kdump kernel. Can be, but it's not strictly necessary. It depends what userland does. Especially it's possible that a non-relocatable, self-compiled kernel loads a relocatable distribution kernel as capture kernel. Also, it would make sense to make the behaviour symmetric across platforms. Currently we have: - x86 and ia64: Without offset on command line, use any offset With offset on command line, use that offset and fail if no memory is available at that offset. - ppc64: Always use 32M and ignore the offset. If your patch gets applied, we have: - ppc64: With CONFIG_RELOCATABLE, use any offset With offset on command I don't see why the behaviour on ppc64 should be completely different. Having maintained kdump for SUSE for x86, ia64 and partly ppc64 in the past, I always felt that ppc64 is more different from x86 than ia64 is from x86. That's one more step into that direction without a technical reason. Having that all said: If your patch gets in mainline kernel, than we should change the behaviour also for x86 and ia64. Regards, Bernhard ___ kexec mailing list ke...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Reserve memory for kdump kernel within RMO region
On 11/27/2009 12:56 AM, Bernhard Walle wrote: M. Mohan Kumar schrieb: On 11/26/2009 12:22 AM, Bernhard Walle wrote: M. Mohan Kumar schrieb: Reserve memory for kdump kernel within RMO region When the kernel size exceeds 32MB(observed with some distros), memory for kdump kernel can not be reserved as kdump kernel base is assumed to be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled, provide the feature to reserve the memory for kdump kernel anywhere in the RMO region. Hi Bernhard, Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that gets loaded as crashkernel, not for the kernel that loads the crashkernel. So it would be perfectly fine that a kernel that has not CONFIG_RELOCATABLE set would load another kernel that has CONFIG_RELOCATABLE set on an address != 32 M. No, with relocatable option, the same kernel is used as both production and kdump kernel. Can be, but it's not strictly necessary. It depends what userland does. Especially it's possible that a non-relocatable, self-compiled kernel loads a relocatable distribution kernel as capture kernel. I don't understand why a non-relocatable kernel will use relocatable kernel for capturing kdump kernel. The idea for relocatable kernel is to avoid using two different kernels to capture kernel dump. Also, it would make sense to make the behaviour symmetric across platforms. Currently we have: - x86 and ia64: Without offset on command line, use any offset With offset on command line, use that offset and fail if no memory is available at that offset. - ppc64: Always use 32M and ignore the offset. If your patch gets applied, we have: - ppc64: With CONFIG_RELOCATABLE, use any offset With offset on command I don't see why the behaviour on ppc64 should be completely different. Having maintained kdump for SUSE for x86, ia64 and partly ppc64 in the past, I always felt that ppc64 is more different from x86 than ia64 is from x86. That's one more step into that direction without a technical reason. Also with the crashkernel=auto parameter (patches are not yet merged), the crashkernel base (offset) by default would be 32MB. In this case if a kernel passed with crashkernel=auto and if the first kernel size exceeds 32MB, memory for kdump kernel will always fail. Having that all said: If your patch gets in mainline kernel, than we should change the behaviour also for x86 and ia64. Regards, Bernhard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Reserve memory for kdump kernel within RMO region
On 11/26/2009 12:22 AM, Bernhard Walle wrote: M. Mohan Kumar schrieb: Reserve memory for kdump kernel within RMO region When the kernel size exceeds 32MB(observed with some distros), memory for kdump kernel can not be reserved as kdump kernel base is assumed to be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled, provide the feature to reserve the memory for kdump kernel anywhere in the RMO region. Hi Bernhard, Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that gets loaded as crashkernel, not for the kernel that loads the crashkernel. So it would be perfectly fine that a kernel that has not CONFIG_RELOCATABLE set would load another kernel that has CONFIG_RELOCATABLE set on an address != 32 M. No, with relocatable option, the same kernel is used as both production and kdump kernel. If the kernel is not relocatable, kdump kernel can be loaded *only at* 32MB. So if a kernel has RELOCATABLE option enabled and by chance if the production kernel size is beyond 32MB, current code will not load the kdump kernel at 32MB as current kernel overlaps with kdump kernel region. So if the kernel has RELOCATABLE option, we could reserve memory for kdump kernel within RMO region. So it would be part of the command line to determine whether a fixed or a variable address is used. The system configuration (or the admin) knows both: if the kernel that should be loaded is relocatable (can be detected with the x86 bzImage header or with the ELF type for vmlinux) and it can also influence the boot command line. To sum it up: I'm not against reserving it anywhere, I'm only against making it dependent on CONFIG_RELOCATABLE which has another function. Regards, Bernhard ___ kexec mailing list ke...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Reserve memory for kdump kernel within RMO region
Reserve memory for kdump kernel within RMO region
When the kernel size exceeds 32MB(observed with some distros), memory
for kdump kernel can not be reserved as kdump kernel base is assumed to
be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
provide the feature to reserve the memory for kdump kernel anywhere in
the RMO region.
Signed-off-by: M. Mohan Kumar
---
arch/powerpc/kernel/machine_kexec.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index baf1af0..99b2f9f 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -140,10 +140,29 @@ void __init reserve_crashkernel(void)
/* The crash region must not overlap the current kernel */
if (overlaps_crashkernel(__pa(_stext), _end - _stext)) {
+#ifdef CONFIG_RELOCATABLE
+ do {
+ /* Align kdump kernel to 16MB (size of large page) */
+ crashk_res.start = ALIGN(crashk_res.start +
+ (16 * 1024 * 1024), 0x100);
+ if (crashk_res.start + (_stext - _end) > lmb.rmo_size) {
+ printk(KERN_WARNING
+ "Not enough memory for crash kernel\n");
+ crashk_res.start = crashk_res.end = 0;
+ return;
+ }
+ } while (overlaps_crashkernel(__pa(_stext), _end - _stext));
+
+ crashk_res.end = crashk_res.start + crash_size - 1;
+ printk(KERN_INFO
+ "crash kernel memory overlaps with kernel memory\n"
+ "Moving it to %lx\n", (unsigned long)crashk_res.start);
+#else
printk(KERN_WARNING
"Crash kernel can not overlap current kernel\n");
crashk_res.start = crashk_res.end = 0;
return;
+#endif
}
/* Crash kernel trumps memory limit */
--
1.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Write to HVC terminal from purgatory cod
[PATCH] Write to HVC terminal from purgatory code
Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to serial
console/VGA while executing the purgatory code. Implement this feature for
POWERPC pseries platform by using the H_PUT_TERM_CHAR hypervisor call by
printng to hvc console.
Includes the changes suggested by Michael Ellerman
Signed-off-by: M. Mohan Kumar
---
kexec/arch/ppc64/fs2dt.c | 62 +++-
kexec/arch/ppc64/kexec-elf-ppc64.c |7
purgatory/arch/ppc64/Makefile |1 +
purgatory/arch/ppc64/console-ppc64.c | 14 +++
purgatory/arch/ppc64/hvCall.S | 26 +
purgatory/arch/ppc64/hvCall.h |8
purgatory/arch/ppc64/purgatory-ppc64.c |1 +
7 files changed, 118 insertions(+), 1 deletions(-)
create mode 100644 purgatory/arch/ppc64/hvCall.S
create mode 100644 purgatory/arch/ppc64/hvCall.h
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index b01ff86..68a90e0 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -48,6 +48,7 @@ static int crash_param = 0;
static char local_cmdline[COMMAND_LINE_SIZE] = { "" };
extern mem_rgns_t usablemem_rgns;
static struct bootblock bb[1];
+extern int my_debug;
void reserve(unsigned long long where, unsigned long long length)
{
@@ -434,6 +435,9 @@ static void putnode(void)
if (!strcmp(basename,"/chosen/")) {
size_t cmd_len = 0;
char *param = NULL;
+ char filename[MAXPATH];
+ char *buff;
+ int fd;
cmd_len = strlen(local_cmdline);
if (cmd_len != 0) {
@@ -446,7 +450,6 @@ static void putnode(void)
/* ... if not, grab root= from the old command line */
if (!param) {
- char filename[MAXPATH];
FILE *fp;
char *last_cmdline = NULL;
char *old_param;
@@ -483,8 +486,65 @@ static void putnode(void)
dt += (cmd_len + 3)/4;
fprintf(stderr, "Modified cmdline:%s\n", local_cmdline);
+
+ /*
+* Determine the platform type/stdout type, so that purgatory
+* code can print 'I'm in purgatory' message. Currently only
+* pseries/hvcterminal is supported.
+*/
+ strcpy(filename, pathname);
+ strncat(filename, "linux,stdout-path", MAXPATH);
+ fd = open(filename, O_RDONLY);
+ if (fd == -1) {
+ printf("Unable to find %s, printing from purgatory is
diabled\n",
+
filename);
+ goto no_debug;
+ }
+ if (fstat(fd, &statbuf)) {
+ printf("Unable to stat %s, printing from purgatory is
diabled\n",
+
filename);
+ close(fd);
+ goto no_debug;
+
+ }
+
+ buff = malloc(statbuf.st_size);
+ if (!buff) {
+ printf("Can not allocate memory for buff\n");
+ close(fd);
+ goto no_debug;
+ }
+ read(fd, buff, statbuf.st_size);
+ close(fd);
+ strncpy(filename, "/proc/device-tree/", MAXPATH);
+ strncat(filename, buff, MAXPATH);
+ strncat(filename, "/compatible", MAXPATH);
+ fd = open(filename, O_RDONLY);
+ if (fd == -1) {
+ printf("Unable to find %s printing from purgatory is
diabled\n",
+
filename);
+ goto no_debug;
+ }
+ if (fstat(fd, &statbuf)) {
+ printf("Unable to stat %s printing from purgatory is
diabled\n",
+
filename);
+ close(fd);
+ goto no_debug;
+ }
+ buff = realloc(buff, statbuf.st_size);
+ if (!buff) {
+ printf("Can not allocate memory for buff\n");
+ close(fd);
+ goto no_debug;
+ }
+ read(fd, buff, statbuf.st_size);
+ if (!strcmp(buff, "hvterm1") || !strcmp(buff,
Re: [RFC] [PATCH] Write to HVC terminal from purgatory code
> On Mon, Sep 07, 2009 at 10:44:07AM +0530, M. Mohan Kumar wrote: > > Write to HVC terminal from purgatory code > > > > Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to > > serial console/VGA while executing the purgatory code. Implement this > > feature for POWERPC pseries platform by using the H_PUT_TERM_CHAR > > hypervisor call by printng to hvc console. > > This change seems reasonable to me, can any of the ppc people offer a > review? > Sorry, I forgot to mention that this patch is tested on POWER5 (under hypervisor) and POWER4 Full System partition mode (under non-hypervisor) Regards, M. Mohan Kumar. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC] [PATCH] Write to HVC terminal from purgatory code
Write to HVC terminal from purgatory code
Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to
serial console/VGA while executing the purgatory code. Implement this
feature for POWERPC pseries platform by using the H_PUT_TERM_CHAR
hypervisor call by printng to hvc console.
Signed-off-by: M. Mohan Kumar
---
kexec/arch/ppc64/fs2dt.c | 47 +++-
kexec/arch/ppc64/kexec-elf-ppc64.c |7 +
kexec/arch/ppc64/kexec-ppc64.h |1 +
purgatory/arch/ppc64/Makefile |1 +
purgatory/arch/ppc64/console-ppc64.c | 14 +
purgatory/arch/ppc64/hvCall.S | 28 +++
purgatory/arch/ppc64/hvCall.h |8 +
purgatory/arch/ppc64/purgatory-ppc64.c |1 +
8 files changed, 106 insertions(+), 1 deletions(-)
create mode 100644 purgatory/arch/ppc64/hvCall.S
create mode 100644 purgatory/arch/ppc64/hvCall.h
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index b01ff86..bd9d36c 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -434,6 +434,9 @@ static void putnode(void)
if (!strcmp(basename,"/chosen/")) {
size_t cmd_len = 0;
char *param = NULL;
+ char filename[MAXPATH];
+ char buff[64];
+ int fd;
cmd_len = strlen(local_cmdline);
if (cmd_len != 0) {
@@ -446,7 +449,6 @@ static void putnode(void)
/* ... if not, grab root= from the old command line */
if (!param) {
- char filename[MAXPATH];
FILE *fp;
char *last_cmdline = NULL;
char *old_param;
@@ -483,8 +485,51 @@ static void putnode(void)
dt += (cmd_len + 3)/4;
fprintf(stderr, "Modified cmdline:%s\n", local_cmdline);
+
+ /*
+* Determine the platform type/stdout type, so that purgatory
+* code can print 'I'm in purgatory' message. Currently only
+* pseries/hvcterminal is supported.
+*/
+ strcpy(filename, pathname);
+ strcat(filename, "linux,stdout-path");
+ fd = open(filename, O_RDONLY);
+ if (fd == -1) {
+ printf("Unable to find linux,stdout-path, printing"
+ " from purgatory is diabled\n");
+ goto no_debug;
+ }
+ if (fstat(fd, &statbuf)) {
+ printf("Unable to stat linux,stdout-path, printing"
+ " from purgatory is diabled\n");
+ close(fd);
+ goto no_debug;
+ }
+ read(fd, buff, statbuf.st_size);
+ close(fd);
+ strcpy(filename, "/proc/device-tree/");
+ strcat(filename, buff);
+ strcat(filename, "/compatible");
+ fd = open(filename, O_RDONLY);
+ if (fd == -1) {
+ printf("Unable to find linux,stdout-path/compatible, "
+ " printing from purgatory is diabled\n");
+ goto no_debug;
+ }
+ if (fstat(fd, &statbuf)) {
+ printf("Unable to stat linux,stdout-path/compatible, "
+ " printing from purgatory is diabled\n");
+ close(fd);
+ goto no_debug;
+ }
+ read(fd, buff, statbuf.st_size);
+ if (!strcmp(buff, "hvterm1") ||
+ !strcmp(buff, "hvterm-protocol"))
+ my_debug = 1;
+ close(fd);
}
+no_debug:
for (i=0; i < numlist; i++) {
dp = namelist[i];
strcpy(dn, dp->d_name);
diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c
b/kexec/arch/ppc64/kexec-elf-ppc64.c
index 21533cb..65fc42f 100644
--- a/kexec/arch/ppc64/kexec-elf-ppc64.c
+++ b/kexec/arch/ppc64/kexec-elf-ppc64.c
@@ -41,6 +41,8 @@
uint64_t initrd_base, initrd_size;
unsigned char reuse_initrd = 0;
const char *ramdisk;
+/* Used for enabling printing message from purgatory code */
+int my_debug = 0;
int elf_ppc64_probe(const char *buf, off_t len)
{
@@ -296,6 +298,8 @@ int elf_ppc64_load(int argc, char **argv, const char *buf,
off_t len,
toc_addr = my_r2(&info->rhdr);
elf_rel_set_symbol(&info->rhdr, "my_toc", &toc_addr, sizeof(toc_addr));
+ /* Set debug */
+ elf_rel_set_symbol(&info->rhdr, "debug", &my_debug,
[PATCH] powerpc: Invoke kdump for system reset exception
Invoke kdump for system reset exception Dump restart operation from HMC raises system reset exception (0x100) and xmon is invoked(even if kdump kernel is loaded). User has to exit from xmon by saying 'Don't recover' to invoke kdump. Modify this behaviour so that xmon will return immediately for system reset exception and kdump kernel will be invoked (if its loaded). If kdump kernel is not loaded, proceed with xmon Signed-off-by: M. Mohan Kumar --- arch/powerpc/xmon/xmon.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c index e1f33a8..6847334 100644 --- a/arch/powerpc/xmon/xmon.c +++ b/arch/powerpc/xmon/xmon.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include @@ -348,6 +349,14 @@ static int xmon_core(struct pt_regs *regs, int fromipi) unsigned long timeout; #endif + /* +* If the exception is 0x100 and if kexec crash image is loaded, +* continue with kexec_crash +*/ + if (kexec_should_crash(current) && kexec_crash_image && + regs->trap == 0x100) + return 0; + local_irq_save(flags); bp = in_breakpoint_table(regs->nip, &offset); -- 1.6.2.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] Support R_PPC64_REL32 relocation type
[PATCH 2/2] Support R_PPC64_REL32 relocation type gcc-4.4 compiler creates R_PPC64_REL32 relocation type in the ppc64 purgatory code. Add support to handle R_PPC64_REL32 relocation type. Signed-off-by: M. Mohan Kumar --- kexec/arch/ppc64/kexec-elf-rel-ppc64.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/kexec/arch/ppc64/kexec-elf-rel-ppc64.c b/kexec/arch/ppc64/kexec-elf-rel-ppc64.c index 80543af..97aa34c 100644 --- a/kexec/arch/ppc64/kexec-elf-rel-ppc64.c +++ b/kexec/arch/ppc64/kexec-elf-rel-ppc64.c @@ -62,6 +62,10 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, unsigned long r_type, *(uint64_t *)location = value; break; + case R_PPC64_REL32: + *(uint32_t *)location = value - (uint32_t)location; + break; + case R_PPC64_TOC: *(uint64_t *)location = my_r2(ehdr); break; -- 1.6.2.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] Make dtstruct variable to be 8 byte aligned
[PATCH 1/2] Make dtstruct variable to be 8 byte aligned
kexec is creating a version 3 device tree to be backwards compatible. This
version of the struct has 8-byte alignment for properties whose value is 8 or
more bytes. As the code directly checks the pointer when deciding to add the
alignment word, the struct memory must start on an 8 byte boundary. Force the
dtstruct variable to be always 8 bytes aligned.
Signed-off-by: M. Mohan Kumar
---
kexec/arch/ppc64/fs2dt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 1f551fd..b01ff86 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -41,7 +41,7 @@
static char pathname[MAXPATH], *pathstart;
static char propnames[NAMESPACE] = { 0 };
-static unsigned dtstruct[TREEWORDS], *dt;
+static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt;
static unsigned long long mem_rsrv[2*MEMRESERVE] = { 0, 0 };
static int crash_param = 0;
--
1.6.2.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Fri, Aug 07, 2009 at 08:05:49PM +0530, M. Mohan Kumar wrote: > Hi, > > After enabling EARLY_DEBUG (and DEBUG in some of the files in > arch/powerpc/kernel directory), without forcing the dtstruct variable to 8 > byte alignment: > > # ./kexec -e > Starting new kernel > console [udbg0] enabled > -> early_setup(), dt_ptr: 0x7723000 > -> early_init_devtree(c7723000) > Invalid tag 5 scanning flattened device tree ! > search "chosen", depth: 0, uname: > Invalid tag 5 scanning flattened device tree ! > dt_root_size_cells = 2 > dt_root_addr_cells = 2 > Invalid tag 5 scanning flattened device tree ! > reserving: 128c000 -> 5ec1f7 > reserving: 7734000 -> 8cc000 > reserving: 7723000 -> f698 > Phys. mem: 0 > -> move_device_tree > <- move_device_tree > Scanning CPUs ... > Invalid tag 5 scanning flattened device tree ! > <- early_init_devtree() > Probing machine type ... > pSeries ... > No suitable machine found ! > > > So device-tree is getting corrupted when dtstruct variable is not aligned to > 8 byte variable. This problem is not seen with gcc-3.4. Is it compiler > issue? or bug in the code. > I tried writing the device tree to a binary file with and without dt_len and compared the files after hexdump: 0001 2f00 0003 0004 0001 2f00 0003 0004 0002 0003 0004 0002 0003 0004 000f 0002 0003 0004 000f 0002 0003 0004 001b 3ef1 4800 0003 000d 001b 3ef1 4800 0003 000d 002b 4942 4d2c 3931 3135 | 002b 4942 4d2c 3931 3135 2d35 3035 2d35 3035 0003 0005 | 0003 0005 0036 Regards, M. Mohan Kumar > > On Fri, Aug 07, 2009 at 12:24:20AM +1000, Michael Ellerman wrote: > > On Wed, 2009-08-05 at 22:19 +0530, M. Mohan Kumar wrote: > > > Hi, > > > > > > When I align the dtstruct variable to 8 bytes, I am able to invoke kdump. > > > > > > When the line > > > static unsigned dtstruct[TREEWORDS], *dt; > > > changed to > > > static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt; > > > > > > kexec-tool works. > > > > Hmm, odd. > > > > Can you check how it's aligned without your change? ie. in the original > > binary, is it 4 byte aligned? > > > > When you make the change, is the only thing that changes in the binary > > the alignedness of dtstruct, or does it cause other things to move > > around? > > > > I don't think an unaligned dt blob should have any effect on the kernel, > > ie. it should copy it in fine, but I'd have to look at the code. > > > > cheers > > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
Hi, After enabling EARLY_DEBUG (and DEBUG in some of the files in arch/powerpc/kernel directory), without forcing the dtstruct variable to 8 byte alignment: # ./kexec -e Starting new kernel console [udbg0] enabled -> early_setup(), dt_ptr: 0x7723000 -> early_init_devtree(c7723000) Invalid tag 5 scanning flattened device tree ! search "chosen", depth: 0, uname: Invalid tag 5 scanning flattened device tree ! dt_root_size_cells = 2 dt_root_addr_cells = 2 Invalid tag 5 scanning flattened device tree ! reserving: 128c000 -> 5ec1f7 reserving: 7734000 -> 8cc000 reserving: 7723000 -> f698 Phys. mem: 0 -> move_device_tree <- move_device_tree Scanning CPUs ... Invalid tag 5 scanning flattened device tree ! <- early_init_devtree() Probing machine type ... pSeries ... No suitable machine found ! So device-tree is getting corrupted when dtstruct variable is not aligned to 8 byte variable. This problem is not seen with gcc-3.4. Is it compiler issue? or bug in the code. Regards, M. Mohan Kumar. On Fri, Aug 07, 2009 at 12:24:20AM +1000, Michael Ellerman wrote: > On Wed, 2009-08-05 at 22:19 +0530, M. Mohan Kumar wrote: > > Hi, > > > > When I align the dtstruct variable to 8 bytes, I am able to invoke kdump. > > > > When the line > > static unsigned dtstruct[TREEWORDS], *dt; > > changed to > > static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt; > > > > kexec-tool works. > > Hmm, odd. > > Can you check how it's aligned without your change? ie. in the original > binary, is it 4 byte aligned? > > When you make the change, is the only thing that changes in the binary > the alignedness of dtstruct, or does it cause other things to move > around? > > I don't think an unaligned dt blob should have any effect on the kernel, > ie. it should copy it in fine, but I'd have to look at the code. > > cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
Hi, When I align the dtstruct variable to 8 bytes, I am able to invoke kdump. When the line static unsigned dtstruct[TREEWORDS], *dt; changed to static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt; kexec-tool works. Regards, M. Mohan Kumar On Mon, Aug 03, 2009 at 11:19:19AM +0530, M. Mohan Kumar wrote: > On Wed, Jun 24, 2009 at 10:27:43AM +1000, Michael Ellerman wrote: > > On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote: > > > On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote: > > > > > > > Well it definately looks like removing that variable had some code > > > changes. > > > It'll take some time to match it up to source, but Most interesting I > > > think is > > > the variance in putprops around address f34. Looks like its doing some > > > string > > > maniuplation in a reversed order, using a huge offset. Might be > > > worthwhile to > > > check to see if theres any string overruns in this code. > > > > Yeah I still suspect it's just a bug in the code that's being exposed > > now. > > > Hi, > > The same code works with gcc-3.4. > > > Mohan, can you try running it under valgrind? > > Still I am not able to use valgrind to debug kexec-tools > > Regards, > M. Mohan Kumar. > > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, Jun 24, 2009 at 10:27:43AM +1000, Michael Ellerman wrote: > On Tue, 2009-06-23 at 09:56 -0400, Neil Horman wrote: > > On Tue, Jun 23, 2009 at 06:25:34PM +0530, M. Mohan Kumar wrote: > > > > > Well it definately looks like removing that variable had some code changes. > > It'll take some time to match it up to source, but Most interesting I think > > is > > the variance in putprops around address f34. Looks like its doing some > > string > > maniuplation in a reversed order, using a huge offset. Might be worthwhile > > to > > check to see if theres any string overruns in this code. > > Yeah I still suspect it's just a bug in the code that's being exposed > now. > Hi, The same code works with gcc-3.4. > Mohan, can you try running it under valgrind? Still I am not able to use valgrind to debug kexec-tools Regards, M. Mohan Kumar. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, Jun 17, 2009 at 10:05:14AM -0400, Neil Horman wrote: > On Wed, Jun 17, 2009 at 07:04:35PM +0530, M. Mohan Kumar wrote: > > On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote: > > > On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote: > > > > > > > > What compiler version are you using? Does the behaviour change if you > > > > use a newer/older compiler? It sounds to me like there's some deeper bug > > > > and your patch is just papering over it. > > > > > > > > I tried with gcc 4.3.2. Let me try with a recent version and update. > > > > > Agreed, this doesn't make any sense. Try changing the compiler version to > > > see if > > > the problem goes away or stops. It might also be worthwhile to dump the > > > contents of the device tree at the start and end of the kexec process. > > > If the > > > changing of how a function is inlined is causing a hang, its likely > > > changing how > > > the putprops function is writing information to the device tree. > > > Understanding > > > what that change is will likely provide clues to how the code has changed. > > > > Neil, there was no code change in fs2dt.c > > > Sure there was, by modifying the code to tell it to not inline the putprops > function, you changed how the complier optimizes that code block. There may > not > be any source level code change, but the assembly is certainly different, and > it > must be so in a way thats causing a hang. The putpops function changes the > contents of the ppc64 device-tree, so if this is a compiler bug, and its > causing > a hang, I imagine we'll see some manifestation in a change in the device tree > contents. As I mentioned in the patch description, when I retained the variable dt_len and dt_len = dt assignment, kexec/kdump kernel would work. But even if I comment the "dt_len = dt" assignment kernel would hang. If you need I can send objdump of fs2dt.o with and without this assignment. Regards, M. Mohan Kumar. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Do not inline putprops function
On Wed, Jun 17, 2009 at 09:04:13AM -0400, Neil Horman wrote: > On Wed, Jun 17, 2009 at 10:26:35PM +1000, Michael Ellerman wrote: > > > > What compiler version are you using? Does the behaviour change if you > > use a newer/older compiler? It sounds to me like there's some deeper bug > > and your patch is just papering over it. > > I tried with gcc 4.3.2. Let me try with a recent version and update. > Agreed, this doesn't make any sense. Try changing the compiler version to see > if > the problem goes away or stops. It might also be worthwhile to dump the > contents of the device tree at the start and end of the kexec process. If the > changing of how a function is inlined is causing a hang, its likely changing > how > the putprops function is writing information to the device tree. > Understanding > what that change is will likely provide clues to how the code has changed. Neil, there was no code change in fs2dt.c Regards, M. Mohan Kumar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Do not inline putprops function
Do not inline putprops function
With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e
kexec -l and kexec -p respectively). This happened after the patch "ppc64:
cleanups" commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried
reverting each hunk and then found out that retaining following lines in
fs2dt.c makes kexec/kdump work.
-static unsigned *dt_len; /* changed len of modified cmdline
- in flat device-tree */
[]
- dt_len = dt;
I don't have any clue why removing a unused variable would cause the kexec
kernel to hang. After further investigation, I observed that if the putprops
function is not inlined, kexec/kdump kernel would work even after removing
the above lines.
This patch directs gcc to not inline the putprops function. Now we could
invoke kexec and kdump kernels.
Signed-off-by: M. Mohan Kumar
---
kexec/arch/ppc64/fs2dt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 1f551fd..1e01f74 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -259,7 +259,7 @@ static void add_usable_mem_property(int fd, int len)
}
/* put all properties (files) in the property structure */
-static void putprops(char *fn, struct dirent **nlist, int numlist)
+__attribute__ ((noinline)) static void putprops(char *fn, struct dirent
**nlist, int numlist)
{
struct dirent *dp;
int i = 0, fd, len;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Do not inline putprops function
Do not inline putprops function
With the recent kexec-tools git tree, both kexec and kdump kernels hang (i.e
kexec -l and kexec -p respectively). This happened after the patch "ppc64:
cleanups" commit b43a84a31a4be6ed025c1bdef3bb1c3c12e01b16. I tried
reverting each hunk and then found out that retaining following lines in
fs2dt.c makes kexec/kdump work.
-static unsigned *dt_len; /* changed len of modified cmdline
- in flat device-tree */
[]
- dt_len = dt;
I don't have any clue why removing a unused variable would cause the kexec
kernel to hang. After further investigation, I observed that if the putprops
function is not inlined, kexec/kdump kernel would work even after removing
the above lines.
This patch directs gcc to not inline the putprops function. Now we could
invoke kexec and kdump kernels.
---
kexec/arch/ppc64/fs2dt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 1f551fd..1e01f74 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -259,7 +259,7 @@ static void add_usable_mem_property(int fd, int len)
}
/* put all properties (files) in the property structure */
-static void putprops(char *fn, struct dirent **nlist, int numlist)
+__attribute__ ((noinline)) static void putprops(char *fn, struct dirent
**nlist, int numlist)
{
struct dirent *dp;
int i = 0, fd, len;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5 + 2] kexec updates
> On Fri, Jan 02, 2009 at 02:42:38PM -0600, Milton Miller wrote: > > Follwing this mail are 5 patches for kexec userspace and two for the > > kernel. The first fixes an array overflow and the second updates > > userspace to the merged 2.6.28 kdump support. The remaining are > > cleanups and warning fixes, including one for the common code. > > > > The two patchs for the kernel are independent. > > Hi all, > > sorry to be a bit slow in responding, this email landed just > as I was leaving for a weeks holiday. > > The kexec-tools patches seem reasonable to me and I'm happy to merge what I > think are the latest versions - thanks Michael for your review. Hi, I tested both kernel and kexec-tools patches and kdump works fine. Tested on a POWER5 machine. Regards, Mohan. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ppc64: Enable RELOCATABLE option for CRASH_DUMP
Enable RELOCATABLE option if user selects CRASH_DUMP option. Without this patch user has to first select RELOCATABLE option and then has to enable CRASH_DUMP option. Signed-off-by: M. Mohan Kumar --- arch/powerpc/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 79f25ce..acda551 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -326,7 +326,8 @@ config KEXEC config CRASH_DUMP bool "Build a kdump crash kernel" - depends on (PPC64 && RELOCATABLE) || 6xx + depends on PPC64 || 6xx + select RELOCATABLE if PPC64 help Build a kernel suitable for use as a kdump capture kernel. The same kernel binary can be used as production kernel and dump -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ppc64: Enable RELOCATABLE option for CRASH_DUMP
Enable RELOCATABLE option if user selects CRASH_DUMP option. Without this patch user has to first select RELOCATABLE option and then has to enable CRASH_DUMP option. Signed-off-by: M. Mohan Kumar --- arch/powerpc/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 79f25ce..0cdce19 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -326,7 +326,8 @@ config KEXEC config CRASH_DUMP bool "Build a kdump crash kernel" - depends on (PPC64 && RELOCATABLE) || 6xx + depends on PPC64 || 6xx + select RELOCATABLE help Build a kernel suitable for use as a kdump capture kernel. The same kernel binary can be used as production kernel and dump -- 1.6.0.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ppc64: Support for relocatable kernel in kexec-tools
Support for relocatable kernel in kexec-tools This patch is based on the patch sent by Milton Miller with the subject [PATCH 1/2 kexec-tools] ppc64: new relocatble kernel activation ABI http://patchwork.ozlabs.org/patch/5378/ Even with the above patch, the relocatable kernel always move to physical address 0 (ie PHYSICAL_START). Following patch fixes this problem by marking a local variable to 1 in purgatory during kdump kernel load time (kexec -p). After a crash, purgatory sets __run_at_load variable location in the kernel to 1 if the local variable is set to 1. So that the kernel will be running as a relocatable kernel. Signed-off-by: M. Mohan Kumar Signed-off-by: Milton Miller --- kexec/arch/ppc64/crashdump-ppc64.h |2 ++ kexec/arch/ppc64/kexec-elf-ppc64.c | 17 + purgatory/arch/ppc64/v2wrap.S | 25 - 3 files changed, 31 insertions(+), 13 deletions(-) diff --git a/kexec/arch/ppc64/crashdump-ppc64.h b/kexec/arch/ppc64/crashdump-ppc64.h index 9608782..be02213 100644 --- a/kexec/arch/ppc64/crashdump-ppc64.h +++ b/kexec/arch/ppc64/crashdump-ppc64.h @@ -23,6 +23,8 @@ void add_usable_mem_rgns(unsigned long long base, unsigned long long size); #define _ALIGN_UP(addr,size) (((addr)+((size)-1))&(~((size)-1))) #define _ALIGN_DOWN(addr,size) ((addr)&(~((size)-1))) +#define KERNEL_RUN_AT_ZERO_MAGIC 0x72756e30/* "run0" */ + extern uint64_t crash_base; extern uint64_t crash_size; extern unsigned int rtas_base; diff --git a/kexec/arch/ppc64/kexec-elf-ppc64.c b/kexec/arch/ppc64/kexec-elf-ppc64.c index d72550d..870315e 100644 --- a/kexec/arch/ppc64/kexec-elf-ppc64.c +++ b/kexec/arch/ppc64/kexec-elf-ppc64.c @@ -93,6 +93,7 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len, uint64_t my_stack, my_backup_start; uint64_t toc_addr; unsigned int slave_code[256/sizeof (unsigned int)], master_entry; + unsigned int run_at_load; #define OPT_APPEND (OPT_ARCH_MAX+0) #define OPT_RAMDISK (OPT_ARCH_MAX+1) @@ -307,6 +308,18 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len, my_backup_start = info->backup_start; elf_rel_set_symbol(&info->rhdr, "backup_start", &my_backup_start, sizeof(my_backup_start)); + + /* Tell relocatable kernel to run at load address +* via word before slave code in purgatory +*/ + + elf_rel_get_symbol(&info->rhdr, "run_at_load", &run_at_load, + sizeof(run_at_load)); + if (run_at_load == KERNEL_RUN_AT_ZERO_MAGIC) + run_at_load = 1; + /* else it should be a fixed offset image */ + elf_rel_set_symbol(&info->rhdr, "run_at_load", &run_at_load, + sizeof(run_at_load)); } /* Set stack address */ @@ -325,10 +338,13 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len, my_backup_start = 0; my_stack = 0; toc_addr = 0; + run_at_load = 0; elf_rel_get_symbol(&info->rhdr, "kernel", &my_kernel, sizeof(my_kernel)); elf_rel_get_symbol(&info->rhdr, "dt_offset", &my_dt_offset, sizeof(my_dt_offset)); + elf_rel_get_symbol(&info->rhdr, "run_at_load", &run_at_load, + sizeof(run_at_load)); elf_rel_get_symbol(&info->rhdr, "panic_kernel", &my_panic_kernel, sizeof(my_panic_kernel)); elf_rel_get_symbol(&info->rhdr, "backup_start", &my_backup_start, @@ -341,6 +357,7 @@ int elf_ppc64_load(int argc, char **argv, const char *buf, off_t len, fprintf(stderr, "kernel is %llx\n", (unsigned long long)my_kernel); fprintf(stderr, "dt_offset is %llx\n", (unsigned long long)my_dt_offset); + fprintf(stderr, "run_at_load flag is %x\n", run_at_load); fprintf(stderr, "panic_kernel is %x\n", my_panic_kernel); fprintf(stderr, "backup_start is %llx\n", (unsigned long long)my_backup_start); diff --git a/purgatory/arch/ppc64/v2wrap.S b/purgatory/arch/ppc64/v2wrap.S index f69dad2..78b6eec 100644 --- a/purgatory/arch/ppc64/v2wrap.S +++ b/purgatory/arch/ppc64/v2wrap.S @@ -45,11 +45,14 @@ orisrn,rn,nam...@h; \ ori rn,rn,nam...@l -#define KDUMP_SIGNATURE 0xfeed1234 - .machine ppc64 .globl purgatory_start purgatory_start: b master + .org purgatory_start + 0x5c # ABI: possible run_at_load flag at 0x5c +run_at_load: + .globl run_at_load + .long 0 + .size run_at_lo
