[PATCH 0/5 + 2] kexec updates

[PATCH 0/5 + 2] kexec updates

[Milton Miller]

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.

milton

(no subject)

[Milton Miller]

Subject [PATCH kexec-tools 1/5] ppc64: always check number of ranges when adding
Date: Fri, 02 Jan 2009 14:43:49 -0600
Subject: (No subject header)
X-Originating-IP: 205.232.218.102

make the idom "always call realloc_memory_ranges when filling a range entry"

kexec was core dumping after using 5 exclude_range pairs when only 3
were allocated.

also delcare realloc_memory_ranges to take no arguments.

Signed-off-by: Milton Miller <miltonm@bga.com>

Index: kexec-tools/kexec/arch/ppc64/kexec-ppc64.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-ppc64.c	2009-01-02 02:08:58.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-ppc64.c	2009-01-02 02:09:08.000000000 -0600
@@ -96,7 +96,7 @@ err1:
 
 }
 
-static int realloc_memory_ranges()
+static int realloc_memory_ranges(void)
 {
 	size_t memory_range_len;
 
@@ -469,6 +469,8 @@ static int get_devtree_details(unsigned 
 				exclude_range[i].start = initrd_start;
 				exclude_range[i].end = initrd_end;
 				i++;
+				if (i >= max_memory_ranges)
+					realloc_memory_ranges();
 			}
 		} /* chosen */
 
@@ -581,6 +583,8 @@ static int get_devtree_details(unsigned 
 			exclude_range[i].start = tce_base;
 			exclude_range[i].end = tce_base + tce_size;
 			i++;
+			if (i >= max_memory_ranges)
+				realloc_memory_ranges();
 			if (kexec_flags & KEXEC_ON_CRASH)
 				add_usable_mem_rgns(tce_base, tce_size);
 			closedir(cdir);
@@ -634,6 +638,8 @@ int setup_memory_ranges(unsigned long ke
 				memory_range[j].end = exclude_range[i].start - 1;
 				memory_range[j].type = RANGE_RAM;
 				j++;
+				if (j >= max_memory_ranges)
+					realloc_memory_ranges();
 			}
 		} /* i == 0 */
 		/* If the last exclude range does not end at memory_max, include
@@ -646,6 +652,8 @@ int setup_memory_ranges(unsigned long ke
 				memory_range[j].end = memory_max;
 				memory_range[j].type = RANGE_RAM;
 				j++;
+				if (j >= max_memory_ranges)
+					realloc_memory_ranges();
 				/* Limit the end to rmo_top */
 				if (memory_range[j-1].start >= rmo_top) {
 					j--;
@@ -666,6 +674,8 @@ int setup_memory_ranges(unsigned long ke
 		memory_range[j].end = exclude_range[i+1].start - 1;
 		memory_range[j].type = RANGE_RAM;
 		j++;
+		if (i >= max_memory_ranges)
+			realloc_memory_ranges();
 		/* Limit range to rmo_top */
 		if (memory_range[j-1].start >= rmo_top) {
 			j--;

(no subject)

[Milton Miller]

Subject [PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28 relocatable kernel
Date: Fri, 02 Jan 2009 14:44:01 -0600
Subject: (No subject header)
X-Originating-IP: 205.232.218.102

The kernel updated its ABI to tell the relocatable kernel to run
where it was loaded.

We now need to set a flag in the kernel image.  Since we only have
the kernel image avialable as const data to kexec-tools c code, set
the flag in the copy we put in purgatory, and have it set the flag
in the kernel (after purgatory has run its checksum).  To simplfy
the purgatory code we can always copy the flag word back to the
kernel as the c code made a copy of the original flag value.

Signed-off-by: Milton Miller <miltonm@bga.com>
---
v3: 
purgatory now copies the flag to the kernel master entrypoint instead of
the kernel reading the value copied to 0 with the slave spinloop.

rename the local varable to my_run_at_load to be more consistent, and
change its type to uint32_t from unsigned int


Index: kexec-tools/purgatory/arch/ppc64/v2wrap.S
===================================================================
--- kexec-tools.orig/purgatory/arch/ppc64/v2wrap.S	2009-01-01 21:46:15.000000000 -0600
+++ kexec-tools/purgatory/arch/ppc64/v2wrap.S	2009-01-01 22:01:10.000000000 -0600
@@ -45,11 +45,14 @@
 	oris    rn,rn,name##@h;         \
 	ori     rn,rn,name##@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
+	.globl run_at_load
+run_at_load:
+	.long 0
+	.size run_at_load, . - run_at_load
 	.org purgatory_start + 0x60     # ABI: slaves start at 60 with r3=phys
 slave:	b $
 	.org purgatory_start + 0x100    # ABI: end of copied region
@@ -57,7 +60,7 @@ slave:	b $
 
 #
 # The above 0x100 bytes at purgatory_start are replaced with the
-# code from the kernel (or next stage) by kexec/arch/ppc64/kexec-ppc64.c
+# code from the kernel (or next stage) by kexec/arch/ppc64/kexec-elf-ppc64.c
 #
 
 master:
@@ -65,7 +68,6 @@ master:
 	isync
 	mr      17,3            # save cpu id to r17
 	mr      15,4            # save physical address in reg15
-	mr      18,6            # save kdump flag in reg18
 
 	LOADADDR(6,my_toc)
 	ld      2,0(6)          #setup toc
@@ -92,18 +94,13 @@ master:
 80:
 	LOADADDR(6,kernel)
 	ld      4,0(6)          # load the kernel address
+	LOADADDR(6,run_at_load) # the load flag
+	lwz	7,0(6)		# possibly patched by kexec-elf-ppc64
+	stw	7,0x5c(4)	# and patch it into the kernel
 	li	5,0		# r5 will be 0 for kernel
 	mtctr	4		# prepare branch too
 	mr      3,16            # restore dt address
 
-	LOADADDR(6,KDUMP_SIGNATURE)
-	cmpd	18,6
-	bne	regular
-	li	7,1
-	std	7,24(4)		# mark kdump flag at kernel
-regular:
-	lwz	7,0(4)		# get the first instruction that we stole
-	stw	7,0(0)		# and put it in the slave loop at 0
 				# skip cache flush, do we care?
 
 	bctr			# start kernel
Index: kexec-tools/kexec/arch/ppc64/crashdump-ppc64.h
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/crashdump-ppc64.h	2009-01-01 21:46:15.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/crashdump-ppc64.h	2009-01-01 21:46:24.000000000 -0600
@@ -23,6 +23,8 @@ void add_usable_mem_rgns(unsigned long l
 #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;
Index: kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-elf-ppc64.c	2009-01-01 21:46:15.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c	2009-01-01 21:46:24.000000000 -0600
@@ -92,6 +92,7 @@ int elf_ppc64_load(int argc, char **argv
 	unsigned int my_panic_kernel;
 	uint64_t my_stack, my_backup_start;
 	uint64_t toc_addr;
+	uint32_t my_run_at_load;
 	unsigned int slave_code[256/sizeof (unsigned int)], master_entry;
 
 #define OPT_APPEND     (OPT_ARCH_MAX+0)
@@ -307,6 +308,18 @@ int elf_ppc64_load(int argc, char **argv
 		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", &my_run_at_load,
+				sizeof(my_run_at_load));
+		if (my_run_at_load == KERNEL_RUN_AT_ZERO_MAGIC)
+			my_run_at_load = 1;
+			/* else it should be a fixed offset image */
+		elf_rel_set_symbol(&info->rhdr, "run_at_load", &my_run_at_load,
+				sizeof(my_run_at_load));
 	}
 
 	/* Set stack address */
@@ -325,10 +338,13 @@ int elf_ppc64_load(int argc, char **argv
 	my_backup_start = 0;
 	my_stack = 0;
 	toc_addr = 0;
+	my_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", &my_run_at_load,
+				sizeof(my_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
 	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", my_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);

(no subject)

[Milton Miller]

Subject [PATCH kexec-tools 4/5] ppc64: cleanups
Date: Fri, 02 Jan 2009 14:44:26 -0600
Subject: (No subject header)
X-Originating-IP: 205.232.218.102

don't copy purgatory, as elf-load-rel does that for us (like x86_64).

move function declarations from c to h files

remove casts between void  * and various pointers

change some pointers between char and unsigned char *

change args to be vars of the right type instead of casting or
copying between types

Signed-off-by: Milton Miller <miltonm@bga.com>
---
we still need to cast purgatory or we get a signed-ness warning on the pointer


Index: kexec-tools/kexec/arch/ppc64/fs2dt.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/fs2dt.c	2009-01-02 02:16:17.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/fs2dt.c	2009-01-02 02:16:19.000000000 -0600
@@ -46,8 +46,6 @@ static unsigned long long mem_rsrv[2*MEM
 
 static int crash_param = 0;
 static char local_cmdline[COMMAND_LINE_SIZE] = { "" };
-static unsigned *dt_len; /* changed len of modified cmdline
-			    in flat device-tree */
 extern mem_rgns_t usablemem_rgns;
 static struct bootblock bb[1];
 
@@ -314,7 +312,6 @@ static void putprops(char *fn, struct di
 		len = statbuf.st_size;
 
 		*dt++ = 3;
-		dt_len = dt;
 		*dt++ = len;
 		*dt++ = propnum(fn);
 
@@ -509,12 +506,11 @@ static void putnode(void)
 	free(namelist);
 }
 
-int create_flatten_tree(struct kexec_info *info, unsigned char **bufp,
-			unsigned long *sizep, char *cmdline)
+int create_flatten_tree(char **bufp, off_t *sizep, char *cmdline)
 {
 	unsigned long len;
 	unsigned long tlen;
-	unsigned char *buf;
+	char *buf;
 	unsigned long me;
 
 	me = 0;
@@ -556,7 +552,7 @@ int create_flatten_tree(struct kexec_inf
 
 	reserve(me, bb->totalsize); /* patched later in kexec_load */
 
-	buf = (unsigned char *) malloc(bb->totalsize);
+	buf = malloc(bb->totalsize);
 	*bufp = buf;
 	memcpy(buf, bb, bb->off_mem_rsvmap);
 	tlen = bb->off_mem_rsvmap;
Index: kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-elf-ppc64.c	2009-01-02 02:16:17.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c	2009-01-02 02:16:19.000000000 -0600
@@ -42,10 +42,6 @@ uint64_t initrd_base, initrd_size;
 unsigned char reuse_initrd = 0;
 const char *ramdisk;
 
-int create_flatten_tree(struct kexec_info *, unsigned char **, unsigned long *,
-			char *);
-int my_r2(struct mem_ehdr *ehdr);
-
 int elf_ppc64_probe(const char *buf, off_t len)
 {
 	struct mem_ehdr ehdr;
@@ -80,7 +76,7 @@ int elf_ppc64_load(int argc, char **argv
 	const char *devicetreeblob;
 	int cmdline_len, modified_cmdline_len;
 	uint64_t max_addr, hole_addr;
-	unsigned char *seg_buf = NULL;
+	char *seg_buf = NULL;
 	off_t seg_size = 0;
 	struct mem_phdr *phdr;
 	size_t size;
@@ -187,8 +183,7 @@ int elf_ppc64_load(int argc, char **argv
 	if (size > phdr->p_memsz)
 		size = phdr->p_memsz;
 
-	my_kernel = hole_addr = (uint64_t)locate_hole(info, size, 0, 0,
-			max_addr, 1);
+	my_kernel = hole_addr = locate_hole(info, size, 0, 0, max_addr, 1);
 	ehdr.e_phdr[0].p_paddr = hole_addr;
 	result = elf_exec_load(&ehdr, info);
 	if (result < 0) {
@@ -210,16 +205,6 @@ int elf_ppc64_load(int argc, char **argv
 	}
 
 	/* Add v2wrap to the current image */
-	seg_buf = NULL;
-	seg_size = 0;
-
-	seg_buf = (unsigned char *) malloc(purgatory_size);
-	if (seg_buf == NULL) {
-		free_elf_info(&ehdr);
-		return -1;
-	}
-	memcpy(seg_buf, purgatory, purgatory_size);
-	seg_size = purgatory_size;
 	elf_rel_build_load(info, &info->rhdr, (const char *)purgatory,
 				purgatory_size, 0, max_addr, 1, 0);
 
@@ -232,7 +217,7 @@ int elf_ppc64_load(int argc, char **argv
 			"Can't use ramdisk with device tree blob input\n");
 			return -1;
 		}
-		seg_buf = (unsigned char *)slurp_file(ramdisk, &seg_size);
+		seg_buf = slurp_file(ramdisk, &seg_size);
 		hole_addr = add_buffer(info, seg_buf, seg_size, seg_size,
 			0, 0, max_addr, 1);
 		initrd_base = hole_addr;
@@ -240,21 +225,11 @@ int elf_ppc64_load(int argc, char **argv
 	} /* ramdisk */
 
 	if (devicetreeblob) {
-		unsigned char *blob_buf = NULL;
-		off_t blob_size = 0;
-
 		/* Grab device tree from buffer */
-		blob_buf =
-			(unsigned char *)slurp_file(devicetreeblob, &blob_size);
-
-		seg_buf = blob_buf;
-		seg_size = blob_size;
+		seg_buf = slurp_file(devicetreeblob, &seg_size);
 	} else {
 		/* create from fs2dt */
-		seg_buf = NULL;
-		seg_size = 0;
-		create_flatten_tree(info, (unsigned char **)&seg_buf,
-				(unsigned long *)&seg_size,cmdline);
+		create_flatten_tree(&seg_buf, &seg_size, cmdline);
 	}
 	my_dt_offset = add_buffer(info, seg_buf, seg_size, seg_size,
 				0, 0, max_addr, -1);
@@ -264,14 +239,13 @@ int elf_ppc64_load(int argc, char **argv
 	 * entry is before this one
 	 */
 	bb_ptr = (struct bootblock *)(seg_buf);
-	rsvmap_ptr = (uint64_t *)
-		(((char *)seg_buf) + bb_ptr->off_mem_rsvmap);
+	rsvmap_ptr = (uint64_t *)(seg_buf + bb_ptr->off_mem_rsvmap);
 	while (*rsvmap_ptr || *(rsvmap_ptr+1))
 		rsvmap_ptr += 2;
 	rsvmap_ptr -= 2;
 	*rsvmap_ptr = my_dt_offset;
 	rsvmap_ptr++;
-	*rsvmap_ptr = (uint64_t)bb_ptr->totalsize;
+	*rsvmap_ptr = bb_ptr->totalsize;
 
 	/* Set kernel */
 	elf_rel_set_symbol(&info->rhdr, "kernel", &my_kernel, sizeof(my_kernel));
@@ -319,7 +293,7 @@ int elf_ppc64_load(int argc, char **argv
 	elf_rel_set_symbol(&info->rhdr, "stack", &my_stack, sizeof(my_stack));
 
 	/* Set toc */
-	toc_addr = (unsigned long) my_r2(&info->rhdr);
+	toc_addr = my_r2(&info->rhdr);
 	elf_rel_set_symbol(&info->rhdr, "my_toc", &toc_addr, sizeof(toc_addr));
 
 #ifdef DEBUG
Index: kexec-tools/kexec/arch/ppc64/kexec-elf-rel-ppc64.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-elf-rel-ppc64.c	2009-01-02 02:16:17.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-elf-rel-ppc64.c	2009-01-02 02:16:19.000000000 -0600
@@ -3,6 +3,7 @@
 #include <string.h>
 #include "../../kexec.h"
 #include "../../kexec-elf.h"
+#include "kexec-ppc64.h"
 
 int machine_verify_elf_rel(struct mem_ehdr *ehdr)
 {
Index: kexec-tools/kexec/arch/ppc64/kexec-ppc64.h
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-ppc64.h	2009-01-02 02:16:17.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-ppc64.h	2009-01-02 02:16:19.000000000 -0600
@@ -14,6 +14,9 @@ int elf_ppc64_load(int argc, char **argv
 void elf_ppc64_usage(void);
 void reserve(unsigned long long where, unsigned long long length);
 
+int create_flatten_tree(char **, off_t *, char *);
+unsigned long my_r2(const struct mem_ehdr *ehdr);
+
 extern uint64_t initrd_base, initrd_size;
 extern int max_memory_ranges;
 extern unsigned char reuse_initrd;

(no subject)

[Milton Miller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]

Subject [PATCH kexec-tools 5/5] entry wants to be void *
Date: Fri, 02 Jan 2009 14:44:40 -0600
Subject: (No subject header)
X-Originating-IP: 205.232.218.102

The kexec info struct defines entry to be a void *, so pass around the
user supplied value as one.

This fixes the following warning:

gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include -I./util_lib/include -Iinclude/ -I./kexec/arch/ppc64/include  -c -MD -o kexec/kexec.o kexec/kexec.c
kexec/kexec.c: In function ‘my_load’:
kexec/kexec.c:773: warning: assignment makes pointer from integer without a cast

Signed-off-by: Milton Miller <miltonm@bga.com>
---

Index: kexec-tools/kexec/kexec.c
===================================================================
--- kexec-tools.orig/kexec/kexec.c	2009-01-02 02:54:37.000000000 -0600
+++ kexec-tools/kexec/kexec.c	2009-01-02 02:55:06.000000000 -0600
@@ -666,7 +666,7 @@ static void update_purgatory(struct kexe
  *	Load the new kernel
  */
 static int my_load(const char *type, int fileind, int argc, char **argv,
-		   unsigned long kexec_flags, unsigned long entry)
+		   unsigned long kexec_flags, void *entry)
 {
 	char *kernel;
 	char *kernel_buf;
@@ -846,23 +846,20 @@ static int my_exec(void)
 
 static int kexec_loaded(void);
 
-static int load_jump_back_helper_image(unsigned long kexec_flags,
-				       unsigned long entry)
+static int load_jump_back_helper_image(unsigned long kexec_flags, void *entry)
 {
 	int result;
 	struct kexec_segment seg;
 
 	memset(&seg, 0, sizeof(seg));
-	result = kexec_load((void *)entry, 1, &seg,
-			    kexec_flags);
+	result = kexec_load(entry, 1, &seg, kexec_flags);
 	return result;
 }
 
 /*
  *	Jump back to the original kernel
  */
-static int my_load_jump_back_helper(unsigned long kexec_flags,
-				    unsigned long entry)
+static int my_load_jump_back_helper(unsigned long kexec_flags, void *entry)
 {
 	int result;
 
@@ -1036,7 +1033,7 @@ int main(int argc, char *argv[])
 	int do_ifdown = 0;
 	int do_unload = 0;
 	int do_reuse_initrd = 0;
-	unsigned long entry = 0;
+	void *entry = 0;
 	char *type = 0;
 	char *endptr;
 	int opt;
@@ -1096,7 +1093,7 @@ int main(int argc, char *argv[])
 			kexec_flags = KEXEC_PRESERVE_CONTEXT;
 			break;
 		case OPT_ENTRY:
-			entry = strtoul(optarg, &endptr, 0);
+			entry = (void *)strtoul(optarg, &endptr, 0);
 			if (*endptr) {
 				fprintf(stderr,
 					"Bad option value in --load-jump-back-helper=%s\n",

[PATCH] powerpc: make dummy section a valid note header

[Milton Miller]

We are declaring the dummy section (used to work around a binutils
bug) as PT_NOTE, but we don't have enough bytes for it to be a valid
note header, and kexec userspace complains:

Warning: Elf Note name is not null terminated
Warning: append= option is not passed. Using the first kernel root partition
Warning: Elf Note name is not null terminated

Instead of using the arbitray value 0xf177 (aka "fill"), declare a
no-name no-description note of type 0.

Signed-off-by: Milton Miller <miltonm@bga.com>
---
verified on binutils-2.6.17 that the workaround still works (that
is we get a phdr that does not have all zeros in the paddr field,
and a relocatable kernel booted).

Index: common/arch/powerpc/kernel/vmlinux.lds.S
===================================================================
--- common.orig/arch/powerpc/kernel/vmlinux.lds.S	2009-01-02 01:07:12.000000000 -0600
+++ common/arch/powerpc/kernel/vmlinux.lds.S	2009-01-02 01:18:00.000000000 -0600
@@ -87,7 +87,9 @@ SECTIONS
 	/* The dummy segment contents for the bug workaround mentioned above
 	   near PHDRS.  */
 	.dummy : AT(ADDR(.dummy) - LOAD_OFFSET) {
-		LONG(0xf177)
+		LONG(0)
+		LONG(0)
+		LONG(0)
 	} :kernel :dummy
 
 /*

[PATCH] powerpc: check crash_base for relocatable kernel

[Milton Miller]

Enforce that the crash kernel region never overlaps the current kernel,
as it will be written directly on kexec load.

Also, default to the previous KDUMP_KERNELBASE if the start is 0.

Other architectures (x86, ia64) state that specifying the start address
0 (or omitting it) will result in the kernel allocating it.  Before the
relocatable patch in 2.6.28, powerpc would adjust any other start value
to the hardcoded KDUMP_KERNELBASE of 32M.

Signed-off-by: Milton Miller <miltonm@bga.com>
---
consider for stable 2.6.28:

A crash region start of 0 results either in a kernel panic (if all of
segemnt 0 is reserved) or confused kexec userspace (as the start
and length are not exported to userspace):

Starting new kernel
Reserving 512MB of memory at 0MB for crashkernel (System RAM: 2048MB)
Using pSeries machine description

...

[boot]0012 Setup Arch
Kernel panic - not syncing: ERROR: Failed to allocate 0x4000 bytes below 0x10000000.

or

# kexec -p /root/vmlinux
Memory for crashkernel is not reserved
Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
Then try loading kdump kernel
# cat /proc/cmdline
retain_initrd crashkernel=64M
#


Index: common/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- common.orig/arch/powerpc/kernel/machine_kexec.c	2009-01-01 23:43:45.000000000 -0600
+++ common/arch/powerpc/kernel/machine_kexec.c	2009-01-02 00:40:24.000000000 -0600
@@ -13,6 +13,7 @@
 #include <linux/reboot.h>
 #include <linux/threads.h>
 #include <linux/lmb.h>
+#include <asm/sections.h>
 #include <asm/machdep.h>
 #include <asm/prom.h>
 
@@ -94,10 +95,35 @@ void __init reserve_crashkernel(void)
 				KDUMP_KERNELBASE);
 
 	crashk_res.start = KDUMP_KERNELBASE;
+#else
+	if (!crashk_res.start) {
+		/*
+		 * unspecified address, choose a region of specified size
+		 * can overlap with initrd (ignoring corruption when retained)
+		 * ppc64 requires kernel and some stacks to be in first segemnt
+		 */
+		crashk_res.start = KDUMP_KERNELBASE;
+	}
+
+	crash_base = PAGE_ALIGN(crashk_res.start);
+	if (crash_base != crashk_res.start) {
+		printk("Crash kernel base must be aligned to 0x%lx\n",
+				PAGE_SIZE);
+		crashk_res.start = crash_base;
+	}
+
 #endif
 	crash_size = PAGE_ALIGN(crash_size);
 	crashk_res.end = crashk_res.start + crash_size - 1;
 
+	/* The crash region must not overlap the current kernel */
+	if (overlaps_crashkernel(__pa(_stext), _end - _stext)) {
+		printk(KERN_WARNING
+			"Crash kernel can not overlap current kernel\n");
+		crashk_res.start = crashk_res.end = 0;
+		return;
+	}
+
 	/* Crash kernel trumps memory limit */
 	if (memory_limit && memory_limit <= crashk_res.end) {
 		memory_limit = crashk_res.end + 1;

Re: [PATCH] powerpc: check crash_base for relocatable kernel

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

On Fri, 2009-01-02 at 14:46 -0600, Milton Miller wrote:
> @@ -94,10 +95,35 @@ void __init reserve_crashkernel(void)
>  				KDUMP_KERNELBASE);
>  
>  	crashk_res.start = KDUMP_KERNELBASE;
> +#else
> +	if (!crashk_res.start) {
> +		/*
> +		 * unspecified address, choose a region of specified size
> +		 * can overlap with initrd (ignoring corruption when retained)
> +		 * ppc64 requires kernel and some stacks to be in first segemnt
> +		 */
> +		crashk_res.start = KDUMP_KERNELBASE;
> +	}
> +
> +	crash_base = PAGE_ALIGN(crashk_res.start);
> +	if (crash_base != crashk_res.start) {
> +		printk("Crash kernel base must be aligned to 0x%lx\n",
> +				PAGE_SIZE);
> +		crashk_res.start = crash_base;
> +	}
> +
>  #endif
>  	crash_size = PAGE_ALIGN(crash_size);
>  	crashk_res.end = crashk_res.start + crash_size - 1;
>  
> +	/* The crash region must not overlap the current kernel */
> +	if (overlaps_crashkernel(__pa(_stext), _end - _stext)) {
> +		printk(KERN_WARNING
> +			"Crash kernel can not overlap current kernel\n");
> +		crashk_res.start = crashk_res.end = 0;
> +		return;
> +	}

I think we can be smarter here. Why don't we adjust the crash kernel
region so that it doesn't overlap the first kernel? ie. move it up a
bit.

There's also the issue of the RMO, I'm not sure what we should do there,
but I think the kernel needs some smarts otherwise users are going to
shoot themselves in the foot.

We could ignore the @x setting and split the RMO between both kernels
somewhat intelligently.

What might work is multiple crash regions, that way we could have some
space in the RMO for the second kernel (say 32MB?), but the rest outside
- leaving some RMO for the first kernel. But I think that would require
some serious surgery.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] powerpc: check crash_base for relocatable kernel

[Milton Miller]

[removed Paul from cc and fixed Mohan's email]

On Jan 6, 2009, at 5:44 PM, Michael Ellerman wrote:

> On Fri, 2009-01-02 at 14:46 -0600, Milton Miller wrote:
>> @@ -94,10 +95,35 @@ void __init reserve_crashkernel(void)
>>  				KDUMP_KERNELBASE);
>>
>>  	crashk_res.start = KDUMP_KERNELBASE;
>> +#else
>> +	if (!crashk_res.start) {
>> +		/*
>> +		 * unspecified address, choose a region of specified size
>> +		 * can overlap with initrd (ignoring corruption when retained)
>> +		 * ppc64 requires kernel and some stacks to be in first segemnt
>> +		 */
>> +		crashk_res.start = KDUMP_KERNELBASE;
>> +	}
>> +
>> +	crash_base = PAGE_ALIGN(crashk_res.start);
>> +	if (crash_base != crashk_res.start) {
>> +		printk("Crash kernel base must be aligned to 0x%lx\n",
>> +				PAGE_SIZE);
>> +		crashk_res.start = crash_base;
>> +	}
>> +
>>  #endif
>>  	crash_size = PAGE_ALIGN(crash_size);
>>  	crashk_res.end = crashk_res.start + crash_size - 1;
>>
>> +	/* The crash region must not overlap the current kernel */
>> +	if (overlaps_crashkernel(__pa(_stext), _end - _stext)) {
>> +		printk(KERN_WARNING
>> +			"Crash kernel can not overlap current kernel\n");
>> +		crashk_res.start = crashk_res.end = 0;
>> +		return;
>> +	}
>
> I think we can be smarter here. Why don't we adjust the crash kernel
> region so that it doesn't overlap the first kernel? ie. move it up a
> bit.

How much?   In addition to the size of the kernel, we have to allocate 
(1) the emergeency stacks as we use them to bring up secondary cpus (2) 
the irq stacks in the first segment.   While the second could be met 
easier on systems with 1TB slbs we don't take advantage of that yet.


>
> There's also the issue of the RMO, I'm not sure what we should do 
> there,
> but I think the kernel needs some smarts otherwise users are going to
> shoot themselves in the foot.

I was looking at the code in kexec-tools for the rmo, and it seems 
extremely broken (ie it sets rmo_top on every memory block instead of 
the lowest; the clamp to 768M is the savior for systems with multiple 
blocks).

Do we care about loading a kernel below a relocated kernel (between the 
interrupt vectors and the new kernel)?   I ignored that for now, 
arguing that we always run the first kernel at 0.


>
> We could ignore the @x setting and split the RMO between both kernels
> somewhat intelligently.
>
> What might work is multiple crash regions, that way we could have some
> space in the RMO for the second kernel (say 32MB?), but the rest 
> outside
> - leaving some RMO for the first kernel. But I think that would require
> some serious surgery.
>

Other archs have this, i guess because they read the memory out of 
/proc/iomem.   The trick is knowing what has to be put in real space 
and what can go abvoe the rmo.   Also, we have those horrible hard-code 
rmo to 768M max because some platform (one of the cell ones?) didn't 
make the device tree to show it.  Maybe we can track it down and add 
linux,usable-mem-ranges to fix it up?

Does the generic code support loading into the split regions, or is it 
just for giving the kernel room to run?



So while all of these are nice, what do you think about merging this as 
an interm measure, especially for backporting to 2.6.28 stable (and any 
distro that wants to pick up relocatable kdump)?

milton

Re: [PATCH] powerpc: check crash_base for relocatable kernel

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 4767 bytes --]

On Wed, 2009-01-07 at 08:57 -0600, Milton Miller wrote:
> [removed Paul from cc and fixed Mohan's email]
> 
> On Jan 6, 2009, at 5:44 PM, Michael Ellerman wrote:
> 
> > On Fri, 2009-01-02 at 14:46 -0600, Milton Miller wrote:
> >> @@ -94,10 +95,35 @@ void __init reserve_crashkernel(void)
> >>  				KDUMP_KERNELBASE);
> >>
> >>  	crashk_res.start = KDUMP_KERNELBASE;
> >> +#else
> >> +	if (!crashk_res.start) {
> >> +		/*
> >> +		 * unspecified address, choose a region of specified size
> >> +		 * can overlap with initrd (ignoring corruption when retained)
> >> +		 * ppc64 requires kernel and some stacks to be in first segemnt
> >> +		 */
> >> +		crashk_res.start = KDUMP_KERNELBASE;
> >> +	}
> >> +
> >> +	crash_base = PAGE_ALIGN(crashk_res.start);
> >> +	if (crash_base != crashk_res.start) {
> >> +		printk("Crash kernel base must be aligned to 0x%lx\n",
> >> +				PAGE_SIZE);
> >> +		crashk_res.start = crash_base;
> >> +	}
> >> +
> >>  #endif
> >>  	crash_size = PAGE_ALIGN(crash_size);
> >>  	crashk_res.end = crashk_res.start + crash_size - 1;
> >>
> >> +	/* The crash region must not overlap the current kernel */
> >> +	if (overlaps_crashkernel(__pa(_stext), _end - _stext)) {
> >> +		printk(KERN_WARNING
> >> +			"Crash kernel can not overlap current kernel\n");
> >> +		crashk_res.start = crashk_res.end = 0;
> >> +		return;
> >> +	}
> >
> > I think we can be smarter here. Why don't we adjust the crash kernel
> > region so that it doesn't overlap the first kernel? ie. move it up a
> > bit.
> 
> How much?   In addition to the size of the kernel, we have to allocate 
> (1) the emergeency stacks as we use them to bring up secondary cpus (2) 
> the irq stacks in the first segment.   While the second could be met 
> easier on systems with 1TB slbs we don't take advantage of that yet.

Hmm, we could try and work it out though. I guess we don't know how many
CPUs we have at that point, which makes it a little trickier.

So we have the emergency stack and the hard & soft irq stacks per cpu,
which is 48KB AFAICT. So for a 256-way system that would be 12MB.

I don't think I've seen an RMO smaller than 128MB, though I notice our
RPA note specifies 64M as the minimum we'll accept. That would probably
be a bit tight.

How about something like:

min_space = _end + 16MB		(16 to be safe?)

if min_space < rmo_size / 2:
	min_space = rmo_size / 2

if crash_base < min_space:
	crash_base = min_space

> > There's also the issue of the RMO, I'm not sure what we should do 
> > there,
> > but I think the kernel needs some smarts otherwise users are going to
> > shoot themselves in the foot.
> 
> I was looking at the code in kexec-tools for the rmo, and it seems 
> extremely broken (ie it sets rmo_top on every memory block instead of 
> the lowest; the clamp to 768M is the savior for systems with multiple 
> blocks).

Oh surprise.

> Do we care about loading a kernel below a relocated kernel (between the 
> interrupt vectors and the new kernel)?   I ignored that for now, 
> arguing that we always run the first kernel at 0.

No I don't think so.

> > We could ignore the @x setting and split the RMO between both kernels
> > somewhat intelligently.
> >
> > What might work is multiple crash regions, that way we could have some
> > space in the RMO for the second kernel (say 32MB?), but the rest 
> > outside
> > - leaving some RMO for the first kernel. But I think that would require
> > some serious surgery.
> >
> 
> Other archs have this, i guess because they read the memory out of 
> /proc/iomem.   The trick is knowing what has to be put in real space 
> and what can go abvoe the rmo.   Also, we have those horrible hard-code 
> rmo to 768M max because some platform (one of the cell ones?) didn't 
> make the device tree to show it.  Maybe we can track it down and add 
> linux,usable-mem-ranges to fix it up?

Dunno about the cell, but some of the early blades did have crufty
firmware.

> Does the generic code support loading into the split regions, or is it 
> just for giving the kernel room to run?

I don't think so. I don't see any logic that deals with gaps in the
crashk region.

> So while all of these are nice, what do you think about merging this as 
> an interm measure, especially for backporting to 2.6.28 stable (and any 
> distro that wants to pick up relocatable kdump)?

I guess. I'd rather do something smarter, like I suggested above.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[PATCH kexec-tools 1/5] ppc64: always check number of ranges when adding

[Milton Miller]

make the idom "always call realloc_memory_ranges when filling a range entry"

kexec was core dumping after using 5 exclude_range pairs when only 3
were allocated.

also delcare realloc_memory_ranges to take no arguments.

Signed-off-by: Milton Miller <miltonm@bga.com>

Index: kexec-tools/kexec/arch/ppc64/kexec-ppc64.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-ppc64.c	2009-01-02 02:08:58.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-ppc64.c	2009-01-02 02:09:08.000000000 -0600
@@ -96,7 +96,7 @@ err1:
 
 }
 
-static int realloc_memory_ranges()
+static int realloc_memory_ranges(void)
 {
 	size_t memory_range_len;
 
@@ -469,6 +469,8 @@ static int get_devtree_details(unsigned 
 				exclude_range[i].start = initrd_start;
 				exclude_range[i].end = initrd_end;
 				i++;
+				if (i >= max_memory_ranges)
+					realloc_memory_ranges();
 			}
 		} /* chosen */
 
@@ -581,6 +583,8 @@ static int get_devtree_details(unsigned 
 			exclude_range[i].start = tce_base;
 			exclude_range[i].end = tce_base + tce_size;
 			i++;
+			if (i >= max_memory_ranges)
+				realloc_memory_ranges();
 			if (kexec_flags & KEXEC_ON_CRASH)
 				add_usable_mem_rgns(tce_base, tce_size);
 			closedir(cdir);
@@ -634,6 +638,8 @@ int setup_memory_ranges(unsigned long ke
 				memory_range[j].end = exclude_range[i].start - 1;
 				memory_range[j].type = RANGE_RAM;
 				j++;
+				if (j >= max_memory_ranges)
+					realloc_memory_ranges();
 			}
 		} /* i == 0 */
 		/* If the last exclude range does not end at memory_max, include
@@ -646,6 +652,8 @@ int setup_memory_ranges(unsigned long ke
 				memory_range[j].end = memory_max;
 				memory_range[j].type = RANGE_RAM;
 				j++;
+				if (j >= max_memory_ranges)
+					realloc_memory_ranges();
 				/* Limit the end to rmo_top */
 				if (memory_range[j-1].start >= rmo_top) {
 					j--;
@@ -666,6 +674,8 @@ int setup_memory_ranges(unsigned long ke
 		memory_range[j].end = exclude_range[i+1].start - 1;
 		memory_range[j].type = RANGE_RAM;
 		j++;
+		if (i >= max_memory_ranges)
+			realloc_memory_ranges();
 		/* Limit range to rmo_top */
 		if (memory_range[j-1].start >= rmo_top) {
 			j--;

Re: [PATCH kexec-tools 1/5] ppc64: always check number of ranges when adding

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]

On Fri, 2009-01-02 at 15:04 -0600, Milton Miller wrote:
> make the idom "always call realloc_memory_ranges when filling a range entry"
> 
> kexec was core dumping after using 5 exclude_range pairs when only 3
> were allocated.
> 
> also delcare realloc_memory_ranges to take no arguments.
> 
> Signed-off-by: Milton Miller <miltonm@bga.com>
> 
> Index: kexec-tools/kexec/arch/ppc64/kexec-ppc64.c
> ===================================================================
> --- kexec-tools.orig/kexec/arch/ppc64/kexec-ppc64.c	2009-01-02 02:08:58.000000000 -0600
> +++ kexec-tools/kexec/arch/ppc64/kexec-ppc64.c	2009-01-02 02:09:08.000000000 -0600
> @@ -96,7 +96,7 @@ err1:
>  
>  }
>  
> -static int realloc_memory_ranges()
> +static int realloc_memory_ranges(void)
>  {
>  	size_t memory_range_len;
>  
> @@ -469,6 +469,8 @@ static int get_devtree_details(unsigned 
>  				exclude_range[i].start = initrd_start;
>  				exclude_range[i].end = initrd_end;
>  				i++;
> +				if (i >= max_memory_ranges)
> +					realloc_memory_ranges();
>  			}
>  		} /* chosen */
>  
> @@ -581,6 +583,8 @@ static int get_devtree_details(unsigned 
>  			exclude_range[i].start = tce_base;
>  			exclude_range[i].end = tce_base + tce_size;
>  			i++;
> +			if (i >= max_memory_ranges)
> +				realloc_memory_ranges();
>  			if (kexec_flags & KEXEC_ON_CRASH)
>  				add_usable_mem_rgns(tce_base, tce_size);
>  			closedir(cdir);
> @@ -634,6 +638,8 @@ int setup_memory_ranges(unsigned long ke
>  				memory_range[j].end = exclude_range[i].start - 1;
>  				memory_range[j].type = RANGE_RAM;
>  				j++;
> +				if (j >= max_memory_ranges)
> +					realloc_memory_ranges();
>  			}
>  		} /* i == 0 */
>  		/* If the last exclude range does not end at memory_max, include
> @@ -646,6 +652,8 @@ int setup_memory_ranges(unsigned long ke
>  				memory_range[j].end = memory_max;
>  				memory_range[j].type = RANGE_RAM;
>  				j++;
> +				if (j >= max_memory_ranges)
> +					realloc_memory_ranges();
>  				/* Limit the end to rmo_top */
>  				if (memory_range[j-1].start >= rmo_top) {
>  					j--;
> @@ -666,6 +674,8 @@ int setup_memory_ranges(unsigned long ke
>  		memory_range[j].end = exclude_range[i+1].start - 1;
>  		memory_range[j].type = RANGE_RAM;
>  		j++;
> +		if (i >= max_memory_ranges)
> +			realloc_memory_ranges();

Should this be checking against i or j?

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH kexec-tools 1/5] ppc64: always check number of ranges when adding

[Milton Miller]

On Jan 6, 2009, at 8:42 PM, Michael Ellerman wrote:
> On Fri, 2009-01-02 at 15:04 -0600, Milton Miller wrote:
>> make the idom "always call realloc_memory_ranges when filling a range 
>> entry"

>> @@ -666,6 +674,8 @@ int setup_memory_ranges(unsigned long ke
>>  		memory_range[j].end = exclude_range[i+1].start - 1;
>>  		memory_range[j].type = RANGE_RAM;
>>  		j++;
>> +		if (i >= max_memory_ranges)
>> +			realloc_memory_ranges();
>
> Should this be checking against i or j?
>

It does look like it should be against j.  I'll build test and respin 
later.

milton

[PATCH kexec-tools v2] ppc64: always check number of ranges when adding them

[Milton Miller]

make the idom "always call realloc_memory_ranges when filling a range entry"

kexec was core dumping after using 5 exclude_range pairs when only 3
were allocated.

also delcare realloc_memory_ranges to take void.

Signed-off-by: Milton Miller <miltonm@bga.com>
---
v2:  compare variable j not i in a spot noticed by  Michael Ellerman

Index: kexec-tools/kexec/arch/ppc64/kexec-ppc64.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-ppc64.c	2009-01-08 01:21:43.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-ppc64.c	2009-01-08 01:22:33.000000000 -0600
@@ -96,7 +96,7 @@ err1:
 
 }
 
-static int realloc_memory_ranges()
+static int realloc_memory_ranges(void)
 {
 	size_t memory_range_len;
 
@@ -469,6 +469,8 @@ static int get_devtree_details(unsigned 
 				exclude_range[i].start = initrd_start;
 				exclude_range[i].end = initrd_end;
 				i++;
+				if (i >= max_memory_ranges)
+					realloc_memory_ranges();
 			}
 		} /* chosen */
 
@@ -581,6 +583,8 @@ static int get_devtree_details(unsigned 
 			exclude_range[i].start = tce_base;
 			exclude_range[i].end = tce_base + tce_size;
 			i++;
+			if (i >= max_memory_ranges)
+				realloc_memory_ranges();
 			if (kexec_flags & KEXEC_ON_CRASH)
 				add_usable_mem_rgns(tce_base, tce_size);
 			closedir(cdir);
@@ -634,6 +638,8 @@ int setup_memory_ranges(unsigned long ke
 				memory_range[j].end = exclude_range[i].start - 1;
 				memory_range[j].type = RANGE_RAM;
 				j++;
+				if (j >= max_memory_ranges)
+					realloc_memory_ranges();
 			}
 		} /* i == 0 */
 		/* If the last exclude range does not end at memory_max, include
@@ -646,6 +652,8 @@ int setup_memory_ranges(unsigned long ke
 				memory_range[j].end = memory_max;
 				memory_range[j].type = RANGE_RAM;
 				j++;
+				if (j >= max_memory_ranges)
+					realloc_memory_ranges();
 				/* Limit the end to rmo_top */
 				if (memory_range[j-1].start >= rmo_top) {
 					j--;
@@ -666,6 +674,8 @@ int setup_memory_ranges(unsigned long ke
 		memory_range[j].end = exclude_range[i+1].start - 1;
 		memory_range[j].type = RANGE_RAM;
 		j++;
+		if (j >= max_memory_ranges)
+			realloc_memory_ranges();
 		/* Limit range to rmo_top */
 		if (memory_range[j-1].start >= rmo_top) {
 			j--;

[PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28 relocatable kernel

[Milton Miller]

The kernel updated its ABI to tell the relocatable kernel to run
where it was loaded.

We now need to set a flag in the kernel image.  Since we only have
the kernel image avialable as const data to kexec-tools c code, set
the flag in the copy we put in purgatory, and have it set the flag
in the kernel (after purgatory has run its checksum).  To simplfy
the purgatory code we can always copy the flag word back to the
kernel as the c code made a copy of the original flag value.

Signed-off-by: Milton Miller <miltonm@bga.com>
---
v3: 
purgatory now copies the flag to the kernel master entrypoint instead of
the kernel reading the value copied to 0 with the slave spinloop.

rename the local varable to my_run_at_load to be more consistent, and
change its type to uint32_t from unsigned int


Index: kexec-tools/purgatory/arch/ppc64/v2wrap.S
===================================================================
--- kexec-tools.orig/purgatory/arch/ppc64/v2wrap.S	2009-01-01 21:46:15.000000000 -0600
+++ kexec-tools/purgatory/arch/ppc64/v2wrap.S	2009-01-01 22:01:10.000000000 -0600
@@ -45,11 +45,14 @@
 	oris    rn,rn,name##@h;         \
 	ori     rn,rn,name##@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
+	.globl run_at_load
+run_at_load:
+	.long 0
+	.size run_at_load, . - run_at_load
 	.org purgatory_start + 0x60     # ABI: slaves start at 60 with r3=phys
 slave:	b $
 	.org purgatory_start + 0x100    # ABI: end of copied region
@@ -57,7 +60,7 @@ slave:	b $
 
 #
 # The above 0x100 bytes at purgatory_start are replaced with the
-# code from the kernel (or next stage) by kexec/arch/ppc64/kexec-ppc64.c
+# code from the kernel (or next stage) by kexec/arch/ppc64/kexec-elf-ppc64.c
 #
 
 master:
@@ -65,7 +68,6 @@ master:
 	isync
 	mr      17,3            # save cpu id to r17
 	mr      15,4            # save physical address in reg15
-	mr      18,6            # save kdump flag in reg18
 
 	LOADADDR(6,my_toc)
 	ld      2,0(6)          #setup toc
@@ -92,18 +94,13 @@ master:
 80:
 	LOADADDR(6,kernel)
 	ld      4,0(6)          # load the kernel address
+	LOADADDR(6,run_at_load) # the load flag
+	lwz	7,0(6)		# possibly patched by kexec-elf-ppc64
+	stw	7,0x5c(4)	# and patch it into the kernel
 	li	5,0		# r5 will be 0 for kernel
 	mtctr	4		# prepare branch too
 	mr      3,16            # restore dt address
 
-	LOADADDR(6,KDUMP_SIGNATURE)
-	cmpd	18,6
-	bne	regular
-	li	7,1
-	std	7,24(4)		# mark kdump flag at kernel
-regular:
-	lwz	7,0(4)		# get the first instruction that we stole
-	stw	7,0(0)		# and put it in the slave loop at 0
 				# skip cache flush, do we care?
 
 	bctr			# start kernel
Index: kexec-tools/kexec/arch/ppc64/crashdump-ppc64.h
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/crashdump-ppc64.h	2009-01-01 21:46:15.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/crashdump-ppc64.h	2009-01-01 21:46:24.000000000 -0600
@@ -23,6 +23,8 @@ void add_usable_mem_rgns(unsigned long l
 #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;
Index: kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-elf-ppc64.c	2009-01-01 21:46:15.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c	2009-01-01 21:46:24.000000000 -0600
@@ -92,6 +92,7 @@ int elf_ppc64_load(int argc, char **argv
 	unsigned int my_panic_kernel;
 	uint64_t my_stack, my_backup_start;
 	uint64_t toc_addr;
+	uint32_t my_run_at_load;
 	unsigned int slave_code[256/sizeof (unsigned int)], master_entry;
 
 #define OPT_APPEND     (OPT_ARCH_MAX+0)
@@ -307,6 +308,18 @@ int elf_ppc64_load(int argc, char **argv
 		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", &my_run_at_load,
+				sizeof(my_run_at_load));
+		if (my_run_at_load == KERNEL_RUN_AT_ZERO_MAGIC)
+			my_run_at_load = 1;
+			/* else it should be a fixed offset image */
+		elf_rel_set_symbol(&info->rhdr, "run_at_load", &my_run_at_load,
+				sizeof(my_run_at_load));
 	}
 
 	/* Set stack address */
@@ -325,10 +338,13 @@ int elf_ppc64_load(int argc, char **argv
 	my_backup_start = 0;
 	my_stack = 0;
 	toc_addr = 0;
+	my_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", &my_run_at_load,
+				sizeof(my_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
 	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", my_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);

[PATCH kexec-tools 4/5] ppc64: cleanups

[Milton Miller]

don't copy purgatory, as elf-load-rel does that for us (like x86_64).

move function declarations from c to h files

remove casts between void  * and various pointers

change some pointers between char and unsigned char *

change args to be vars of the right type instead of casting or
copying between types

Signed-off-by: Milton Miller <miltonm@bga.com>
---
we still need to cast purgatory or we get a signed-ness warning on the pointer


Index: kexec-tools/kexec/arch/ppc64/fs2dt.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/fs2dt.c	2009-01-02 02:16:17.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/fs2dt.c	2009-01-02 02:16:19.000000000 -0600
@@ -46,8 +46,6 @@ static unsigned long long mem_rsrv[2*MEM
 
 static int crash_param = 0;
 static char local_cmdline[COMMAND_LINE_SIZE] = { "" };
-static unsigned *dt_len; /* changed len of modified cmdline
-			    in flat device-tree */
 extern mem_rgns_t usablemem_rgns;
 static struct bootblock bb[1];
 
@@ -314,7 +312,6 @@ static void putprops(char *fn, struct di
 		len = statbuf.st_size;
 
 		*dt++ = 3;
-		dt_len = dt;
 		*dt++ = len;
 		*dt++ = propnum(fn);
 
@@ -509,12 +506,11 @@ static void putnode(void)
 	free(namelist);
 }
 
-int create_flatten_tree(struct kexec_info *info, unsigned char **bufp,
-			unsigned long *sizep, char *cmdline)
+int create_flatten_tree(char **bufp, off_t *sizep, char *cmdline)
 {
 	unsigned long len;
 	unsigned long tlen;
-	unsigned char *buf;
+	char *buf;
 	unsigned long me;
 
 	me = 0;
@@ -556,7 +552,7 @@ int create_flatten_tree(struct kexec_inf
 
 	reserve(me, bb->totalsize); /* patched later in kexec_load */
 
-	buf = (unsigned char *) malloc(bb->totalsize);
+	buf = malloc(bb->totalsize);
 	*bufp = buf;
 	memcpy(buf, bb, bb->off_mem_rsvmap);
 	tlen = bb->off_mem_rsvmap;
Index: kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-elf-ppc64.c	2009-01-02 02:16:17.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c	2009-01-02 02:16:19.000000000 -0600
@@ -42,10 +42,6 @@ uint64_t initrd_base, initrd_size;
 unsigned char reuse_initrd = 0;
 const char *ramdisk;
 
-int create_flatten_tree(struct kexec_info *, unsigned char **, unsigned long *,
-			char *);
-int my_r2(struct mem_ehdr *ehdr);
-
 int elf_ppc64_probe(const char *buf, off_t len)
 {
 	struct mem_ehdr ehdr;
@@ -80,7 +76,7 @@ int elf_ppc64_load(int argc, char **argv
 	const char *devicetreeblob;
 	int cmdline_len, modified_cmdline_len;
 	uint64_t max_addr, hole_addr;
-	unsigned char *seg_buf = NULL;
+	char *seg_buf = NULL;
 	off_t seg_size = 0;
 	struct mem_phdr *phdr;
 	size_t size;
@@ -187,8 +183,7 @@ int elf_ppc64_load(int argc, char **argv
 	if (size > phdr->p_memsz)
 		size = phdr->p_memsz;
 
-	my_kernel = hole_addr = (uint64_t)locate_hole(info, size, 0, 0,
-			max_addr, 1);
+	my_kernel = hole_addr = locate_hole(info, size, 0, 0, max_addr, 1);
 	ehdr.e_phdr[0].p_paddr = hole_addr;
 	result = elf_exec_load(&ehdr, info);
 	if (result < 0) {
@@ -210,16 +205,6 @@ int elf_ppc64_load(int argc, char **argv
 	}
 
 	/* Add v2wrap to the current image */
-	seg_buf = NULL;
-	seg_size = 0;
-
-	seg_buf = (unsigned char *) malloc(purgatory_size);
-	if (seg_buf == NULL) {
-		free_elf_info(&ehdr);
-		return -1;
-	}
-	memcpy(seg_buf, purgatory, purgatory_size);
-	seg_size = purgatory_size;
 	elf_rel_build_load(info, &info->rhdr, (const char *)purgatory,
 				purgatory_size, 0, max_addr, 1, 0);
 
@@ -232,7 +217,7 @@ int elf_ppc64_load(int argc, char **argv
 			"Can't use ramdisk with device tree blob input\n");
 			return -1;
 		}
-		seg_buf = (unsigned char *)slurp_file(ramdisk, &seg_size);
+		seg_buf = slurp_file(ramdisk, &seg_size);
 		hole_addr = add_buffer(info, seg_buf, seg_size, seg_size,
 			0, 0, max_addr, 1);
 		initrd_base = hole_addr;
@@ -240,21 +225,11 @@ int elf_ppc64_load(int argc, char **argv
 	} /* ramdisk */
 
 	if (devicetreeblob) {
-		unsigned char *blob_buf = NULL;
-		off_t blob_size = 0;
-
 		/* Grab device tree from buffer */
-		blob_buf =
-			(unsigned char *)slurp_file(devicetreeblob, &blob_size);
-
-		seg_buf = blob_buf;
-		seg_size = blob_size;
+		seg_buf = slurp_file(devicetreeblob, &seg_size);
 	} else {
 		/* create from fs2dt */
-		seg_buf = NULL;
-		seg_size = 0;
-		create_flatten_tree(info, (unsigned char **)&seg_buf,
-				(unsigned long *)&seg_size,cmdline);
+		create_flatten_tree(&seg_buf, &seg_size, cmdline);
 	}
 	my_dt_offset = add_buffer(info, seg_buf, seg_size, seg_size,
 				0, 0, max_addr, -1);
@@ -264,14 +239,13 @@ int elf_ppc64_load(int argc, char **argv
 	 * entry is before this one
 	 */
 	bb_ptr = (struct bootblock *)(seg_buf);
-	rsvmap_ptr = (uint64_t *)
-		(((char *)seg_buf) + bb_ptr->off_mem_rsvmap);
+	rsvmap_ptr = (uint64_t *)(seg_buf + bb_ptr->off_mem_rsvmap);
 	while (*rsvmap_ptr || *(rsvmap_ptr+1))
 		rsvmap_ptr += 2;
 	rsvmap_ptr -= 2;
 	*rsvmap_ptr = my_dt_offset;
 	rsvmap_ptr++;
-	*rsvmap_ptr = (uint64_t)bb_ptr->totalsize;
+	*rsvmap_ptr = bb_ptr->totalsize;
 
 	/* Set kernel */
 	elf_rel_set_symbol(&info->rhdr, "kernel", &my_kernel, sizeof(my_kernel));
@@ -319,7 +293,7 @@ int elf_ppc64_load(int argc, char **argv
 	elf_rel_set_symbol(&info->rhdr, "stack", &my_stack, sizeof(my_stack));
 
 	/* Set toc */
-	toc_addr = (unsigned long) my_r2(&info->rhdr);
+	toc_addr = my_r2(&info->rhdr);
 	elf_rel_set_symbol(&info->rhdr, "my_toc", &toc_addr, sizeof(toc_addr));
 
 #ifdef DEBUG
Index: kexec-tools/kexec/arch/ppc64/kexec-elf-rel-ppc64.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-elf-rel-ppc64.c	2009-01-02 02:16:17.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-elf-rel-ppc64.c	2009-01-02 02:16:19.000000000 -0600
@@ -3,6 +3,7 @@
 #include <string.h>
 #include "../../kexec.h"
 #include "../../kexec-elf.h"
+#include "kexec-ppc64.h"
 
 int machine_verify_elf_rel(struct mem_ehdr *ehdr)
 {
Index: kexec-tools/kexec/arch/ppc64/kexec-ppc64.h
===================================================================
--- kexec-tools.orig/kexec/arch/ppc64/kexec-ppc64.h	2009-01-02 02:16:17.000000000 -0600
+++ kexec-tools/kexec/arch/ppc64/kexec-ppc64.h	2009-01-02 02:16:19.000000000 -0600
@@ -14,6 +14,9 @@ int elf_ppc64_load(int argc, char **argv
 void elf_ppc64_usage(void);
 void reserve(unsigned long long where, unsigned long long length);
 
+int create_flatten_tree(char **, off_t *, char *);
+unsigned long my_r2(const struct mem_ehdr *ehdr);
+
 extern uint64_t initrd_base, initrd_size;
 extern int max_memory_ranges;
 extern unsigned char reuse_initrd;

[PATCH kexec-tools 5/5] entry wants to be void *

[Milton Miller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2272 bytes --]

The kexec info struct defines entry to be a void *, so pass around the
user supplied value as one.

This fixes the following warning:

gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include -I./util_lib/include -Iinclude/ -I./kexec/arch/ppc64/include  -c -MD -o kexec/kexec.o kexec/kexec.c
kexec/kexec.c: In function ‘my_load’:
kexec/kexec.c:773: warning: assignment makes pointer from integer without a cast

Signed-off-by: Milton Miller <miltonm@bga.com>
---

Index: kexec-tools/kexec/kexec.c
===================================================================
--- kexec-tools.orig/kexec/kexec.c	2009-01-02 02:54:37.000000000 -0600
+++ kexec-tools/kexec/kexec.c	2009-01-02 02:55:06.000000000 -0600
@@ -666,7 +666,7 @@ static void update_purgatory(struct kexe
  *	Load the new kernel
  */
 static int my_load(const char *type, int fileind, int argc, char **argv,
-		   unsigned long kexec_flags, unsigned long entry)
+		   unsigned long kexec_flags, void *entry)
 {
 	char *kernel;
 	char *kernel_buf;
@@ -846,23 +846,20 @@ static int my_exec(void)
 
 static int kexec_loaded(void);
 
-static int load_jump_back_helper_image(unsigned long kexec_flags,
-				       unsigned long entry)
+static int load_jump_back_helper_image(unsigned long kexec_flags, void *entry)
 {
 	int result;
 	struct kexec_segment seg;
 
 	memset(&seg, 0, sizeof(seg));
-	result = kexec_load((void *)entry, 1, &seg,
-			    kexec_flags);
+	result = kexec_load(entry, 1, &seg, kexec_flags);
 	return result;
 }
 
 /*
  *	Jump back to the original kernel
  */
-static int my_load_jump_back_helper(unsigned long kexec_flags,
-				    unsigned long entry)
+static int my_load_jump_back_helper(unsigned long kexec_flags, void *entry)
 {
 	int result;
 
@@ -1036,7 +1033,7 @@ int main(int argc, char *argv[])
 	int do_ifdown = 0;
 	int do_unload = 0;
 	int do_reuse_initrd = 0;
-	unsigned long entry = 0;
+	void *entry = 0;
 	char *type = 0;
 	char *endptr;
 	int opt;
@@ -1096,7 +1093,7 @@ int main(int argc, char *argv[])
 			kexec_flags = KEXEC_PRESERVE_CONTEXT;
 			break;
 		case OPT_ENTRY:
-			entry = strtoul(optarg, &endptr, 0);
+			entry = (void *)strtoul(optarg, &endptr, 0);
 			if (*endptr) {
 				fprintf(stderr,
 					"Bad option value in --load-jump-back-helper=%s\n",

Re: [PATCH 0/5 + 2] kexec updates

[Simon Horman]

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.

Milton, here are the Subjects, Dates and Message-Ids of what I have in my
queue.  If you could confirm this or repost that would be great.

#1
Subject: [PATCH kexec-tools v2] ppc64: always check number of ranges when adding them
Date: Thu, 08 Jan 2009 06:33:50 -0600
Message-ID: <1231418030_141769@mercury.realtime.net>

#2
Subject: [PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28 relocatable kernel
Date: Fri, 02 Jan 2009 15:04:42 -0600
Message-Id: <kexec-29-1-2r.miltonm@bga.com>

#3
Subject: [PATCH kexec-tools 3/5] ppc64: segments may be reordered
Date: Fri, 02 Jan 2009 15:04:45 -0600
Message-Id: <kexec-29-1-3r.miltonm@bga.com>

#4
Subject: [PATCH kexec-tools 4/5] ppc64: cleanups
Date: Fri, 02 Jan 2009 15:04:48 -0600
Message-Id: <kexec-29-1-4r.miltonm@bga.com>

#5
Subject: [PATCH kexec-tools 5/5] entry wants to be void *
Date: Fri, 02 Jan 2009 15:04:51 -0600
Message-Id: <kexec-29-1-5r.miltonm@bga.com>

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en

Re: [PATCH 0/5 + 2] kexec updates

[M. Mohan Kumar]

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

Re: [PATCH 0/5 + 2] kexec updates

[Milton Miller]

On Jan 12, 2009, at 12:24 AM, Simon Horman wrote:
> 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.
>

No problem, I figured as much.

> 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.
>
> Milton, here are the Subjects, Dates and Message-Ids of what I have in 
> my
> queue.  If you could confirm this or repost that would be great.
>
> #1
> Subject: [PATCH kexec-tools v2] ppc64: always check number of ranges 
> when adding them
> Date: Thu, 08 Jan 2009 06:33:50 -0600
> Message-ID: <1231418030_141769@mercury.realtime.net>
>
> #2
> Subject: [PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28 
> relocatable kernel
> Date: Fri, 02 Jan 2009 15:04:42 -0600
> Message-Id: <kexec-29-1-2r.miltonm@bga.com>
>
> #3
> Subject: [PATCH kexec-tools 3/5] ppc64: segments may be reordered
> Date: Fri, 02 Jan 2009 15:04:45 -0600
> Message-Id: <kexec-29-1-3r.miltonm@bga.com>
>
> #4
> Subject: [PATCH kexec-tools 4/5] ppc64: cleanups
> Date: Fri, 02 Jan 2009 15:04:48 -0600
> Message-Id: <kexec-29-1-4r.miltonm@bga.com>
>
> #5
> Subject: [PATCH kexec-tools 5/5] entry wants to be void *
> Date: Fri, 02 Jan 2009 15:04:51 -0600
> Message-Id: <kexec-29-1-5r.miltonm@bga.com>

Based on the subjects, yes, those are the lastest versions.

And I assume you saw Mohan's tested message.

Thanks,
milton

Re: [PATCH 0/5 + 2] kexec updates

[Simon Horman]

On Tue, Jan 13, 2009 at 09:59:08AM -0600, Milton Miller wrote:
> On Jan 12, 2009, at 12:24 AM, Simon Horman wrote:
>> 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.
>>
>
> No problem, I figured as much.
>
>> 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.
>>
>> Milton, here are the Subjects, Dates and Message-Ids of what I have in  
>> my
>> queue.  If you could confirm this or repost that would be great.
>>
>> #1
>> Subject: [PATCH kexec-tools v2] ppc64: always check number of ranges  
>> when adding them
>> Date: Thu, 08 Jan 2009 06:33:50 -0600
>> Message-ID: <1231418030_141769@mercury.realtime.net>
>>
>> #2
>> Subject: [PATCH kexec-tools 2/5] ppc64: update kdump for 2.6.28  
>> relocatable kernel
>> Date: Fri, 02 Jan 2009 15:04:42 -0600
>> Message-Id: <kexec-29-1-2r.miltonm@bga.com>
>>
>> #3
>> Subject: [PATCH kexec-tools 3/5] ppc64: segments may be reordered
>> Date: Fri, 02 Jan 2009 15:04:45 -0600
>> Message-Id: <kexec-29-1-3r.miltonm@bga.com>
>>
>> #4
>> Subject: [PATCH kexec-tools 4/5] ppc64: cleanups
>> Date: Fri, 02 Jan 2009 15:04:48 -0600
>> Message-Id: <kexec-29-1-4r.miltonm@bga.com>
>>
>> #5
>> Subject: [PATCH kexec-tools 5/5] entry wants to be void *
>> Date: Fri, 02 Jan 2009 15:04:51 -0600
>> Message-Id: <kexec-29-1-5r.miltonm@bga.com>
>
> Based on the subjects, yes, those are the lastest versions.
>
> And I assume you saw Mohan's tested message.

Thanks. I've added a "Tested-by: M. Mohan Kumar <mohan@in.ibm.com>" tag
to each of the five patches and applied them.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en