LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 4/8] pseries: phyp dump: register dump area.
From: Manish Ahuja @ 2008-02-12  7:14 UTC (permalink / raw)
  To: linuxppc-dev, paulus; +Cc: mahuja, linasvepstas
In-Reply-To: <47B13D2E.1070001@austin.ibm.com>


Set up the actual dump header, register it with the hypervisor.

Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>

------
 arch/powerpc/platforms/pseries/phyp_dump.c |  136 +++++++++++++++++++++++++++--
 1 file changed, 129 insertions(+), 7 deletions(-)

Index: 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/platforms/pseries/phyp_dump.c	2008-02-12 06:12:55.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c	2008-02-12 06:13:01.000000000 -0600
@@ -30,6 +30,117 @@ struct phyp_dump *phyp_dump_info = &phyp
 static int ibm_configure_kernel_dump;
 
 /* ------------------------------------------------- */
+/* RTAS interfaces to declare the dump regions */
+
+struct dump_section {
+	u32 dump_flags;
+	u16 source_type;
+	u16 error_flags;
+	u64 source_address;
+	u64 source_length;
+	u64 length_copied;
+	u64 destination_address;
+};
+
+struct phyp_dump_header {
+	u32 version;
+	u16 num_of_sections;
+	u16 status;
+
+	u32 first_offset_section;
+	u32 dump_disk_section;
+	u64 block_num_dd;
+	u64 num_of_blocks_dd;
+	u32 offset_dd;
+	u32 maxtime_to_auto;
+	/* No dump disk path string used */
+
+	struct dump_section cpu_data;
+	struct dump_section hpte_data;
+	struct dump_section kernel_data;
+};
+
+/* The dump header *must be* in low memory, so .bss it */
+static struct phyp_dump_header phdr;
+
+#define NUM_DUMP_SECTIONS 3
+#define DUMP_HEADER_VERSION 0x1
+#define DUMP_REQUEST_FLAG 0x1
+#define DUMP_SOURCE_CPU 0x0001
+#define DUMP_SOURCE_HPTE 0x0002
+#define DUMP_SOURCE_RMO  0x0011
+
+/**
+ * init_dump_header() - initialize the header declaring a dump
+ * Returns: length of dump save area.
+ *
+ * When the hypervisor saves crashed state, it needs to put
+ * it somewhere. The dump header tells the hypervisor where
+ * the data can be saved.
+ */
+static unsigned long init_dump_header(struct phyp_dump_header *ph)
+{
+	unsigned long addr_offset = 0;
+
+	/* Set up the dump header */
+	ph->version = DUMP_HEADER_VERSION;
+	ph->num_of_sections = NUM_DUMP_SECTIONS;
+	ph->status = 0;
+
+	ph->first_offset_section =
+		(u32)offsetof(struct phyp_dump_header, cpu_data);
+	ph->dump_disk_section = 0;
+	ph->block_num_dd = 0;
+	ph->num_of_blocks_dd = 0;
+	ph->offset_dd = 0;
+
+	ph->maxtime_to_auto = 0; /* disabled */
+
+	/* The first two sections are mandatory */
+	ph->cpu_data.dump_flags = DUMP_REQUEST_FLAG;
+	ph->cpu_data.source_type = DUMP_SOURCE_CPU;
+	ph->cpu_data.source_address = 0;
+	ph->cpu_data.source_length = phyp_dump_info->cpu_state_size;
+	ph->cpu_data.destination_address = addr_offset;
+	addr_offset += phyp_dump_info->cpu_state_size;
+
+	ph->hpte_data.dump_flags = DUMP_REQUEST_FLAG;
+	ph->hpte_data.source_type = DUMP_SOURCE_HPTE;
+	ph->hpte_data.source_address = 0;
+	ph->hpte_data.source_length = phyp_dump_info->hpte_region_size;
+	ph->hpte_data.destination_address = addr_offset;
+	addr_offset += phyp_dump_info->hpte_region_size;
+
+	/* This section describes the low kernel region */
+	ph->kernel_data.dump_flags = DUMP_REQUEST_FLAG;
+	ph->kernel_data.source_type = DUMP_SOURCE_RMO;
+	ph->kernel_data.source_address = PHYP_DUMP_RMR_START;
+	ph->kernel_data.source_length = PHYP_DUMP_RMR_END;
+	ph->kernel_data.destination_address = addr_offset;
+	addr_offset += ph->kernel_data.source_length;
+
+	return addr_offset;
+}
+
+static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
+{
+	int rc;
+	ph->cpu_data.destination_address += addr;
+	ph->hpte_data.destination_address += addr;
+	ph->kernel_data.destination_address += addr;
+
+	do {
+		rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
+		               1, ph, sizeof(struct phyp_dump_header));
+	} while (rtas_busy_delay(rc));
+
+	if (rc)
+	{
+		printk (KERN_ERR "phyp-dump: unexpected error (%d) on register\n", rc);
+	}
+}
+
+/* ------------------------------------------------- */
 /**
  * release_memory_range -- release memory previously lmb_reserved
  * @start_pfn: starting physical frame number
@@ -113,7 +224,9 @@ static struct subsys_attribute rr = __AT
 static int __init phyp_dump_setup(void)
 {
 	struct device_node *rtas;
-	const int *dump_header;
+	const struct phyp_dump_header *dump_header;
+	unsigned long dump_area_start;
+	unsigned long dump_area_length;
 	int header_len = 0;
 	int rc;
 
@@ -126,22 +239,31 @@ static int __init phyp_dump_setup(void)
 		return -ENOSYS;
 	}
 
-	/* Is there dump data waiting for us? */
+	/* Is there dump data waiting for us? If there isn't,
+	 * then register a new dump area, and release all of
+	 * the rest of the reserved ram.
+	 *
+	 * The /rtas/ibm,kernel-dump rtas node is present only
+	 * if there is dump data waiting for us.
+	 */
 	rtas = of_find_node_by_path("/rtas");
 	dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
+	of_node_put(rtas);
+
+	dump_area_length = init_dump_header(&phdr);
+	dump_area_start = phyp_dump_info->init_reserve_start & PAGE_MASK; /* align down */
+
 	if (dump_header == NULL) {
-		release_all();
+		register_dump_area(&phdr, dump_area_start);
 		return 0;
 	}
 
 	/* Should we create a dump_subsys, analogous to s390/ipl.c ? */
 	rc = subsys_create_file(&kernel_subsys, &rr);
-	if (rc) {
+	if (rc)
 		printk (KERN_ERR "phyp-dump: unable to create sysfs file (%d)\n", rc);
-		release_all();
-		return 0;
-	}
 
+	/* ToDo: re-register the dump area, for next time. */
 	return 0;
 }
 subsys_initcall(phyp_dump_setup);

^ permalink raw reply

* [PATCH 5/8] pseries: phyp dump: debugging print routines.
From: Manish Ahuja @ 2008-02-12  7:16 UTC (permalink / raw)
  To: linuxppc-dev, paulus; +Cc: mahuja, linasvepstas
In-Reply-To: <47B13D2E.1070001@austin.ibm.com>


Provide some basic debugging support.

Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
Signed-off-by: Linas Vepsts <linas@austin.ibm.com>
-----

 arch/powerpc/platforms/pseries/phyp_dump.c |   64 +++++++++++++++++++++++++++--
 1 file changed, 60 insertions(+), 4 deletions(-)

Index: 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/platforms/pseries/phyp_dump.c	2008-02-12 06:13:01.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c	2008-02-12 06:13:06.000000000 -0600
@@ -2,7 +2,7 @@
  * Hypervisor-assisted dump
  *
  * Linas Vepstas, Manish Ahuja 2007
- * Copyrhgit (c) 2007 IBM Corp.
+ * Copyright (c) 2007 IBM Corp.
  *
  *      This program is free software; you can redistribute it and/or
  *      modify it under the terms of the GNU General Public License
@@ -122,6 +122,61 @@ static unsigned long init_dump_header(st
 	return addr_offset;
 }
 
+static void print_dump_header(const struct phyp_dump_header *ph)
+{
+#ifdef DEBUG
+	printk(KERN_INFO "dump header:\n");
+	/* setup some ph->sections required */
+	printk(KERN_INFO "version = %d\n", ph->version);
+	printk(KERN_INFO "Sections = %d\n", ph->num_of_sections);
+	printk(KERN_INFO "Status = 0x%x\n", ph->status);
+
+	/* No ph->disk, so all should be set to 0 */
+	printk(KERN_INFO "Offset to first section 0x%x\n",
+						ph->first_offset_section);
+	printk(KERN_INFO "dump disk sections should be zero\n");
+	printk(KERN_INFO "dump disk section = %d\n", ph->dump_disk_section);
+	printk(KERN_INFO "block num = %ld\n", ph->block_num_dd);
+	printk(KERN_INFO "number of blocks = %ld\n", ph->num_of_blocks_dd);
+	printk(KERN_INFO "dump disk offset = %d\n", ph->offset_dd);
+	printk(KERN_INFO "Max auto time= %d\n", ph->maxtime_to_auto);
+
+	/*set cpu state and hpte states as well scratch pad area */
+	printk(KERN_INFO " CPU AREA \n");
+	printk(KERN_INFO "cpu dump_flags =%d\n", ph->cpu_data.dump_flags);
+	printk(KERN_INFO "cpu source_type =%d\n", ph->cpu_data.source_type);
+	printk(KERN_INFO "cpu error_flags =%d\n", ph->cpu_data.error_flags);
+	printk(KERN_INFO "cpu source_address =%lx\n",
+						ph->cpu_data.source_address);
+	printk(KERN_INFO "cpu source_length =%lx\n",
+						ph->cpu_data.source_length);
+	printk(KERN_INFO "cpu length_copied =%lx\n",
+						ph->cpu_data.length_copied);
+
+	printk(KERN_INFO " HPTE AREA \n");
+	printk(KERN_INFO "HPTE dump_flags =%d\n", ph->hpte_data.dump_flags);
+	printk(KERN_INFO "HPTE source_type =%d\n", ph->hpte_data.source_type);
+	printk(KERN_INFO "HPTE error_flags =%d\n", ph->hpte_data.error_flags);
+	printk(KERN_INFO "HPTE source_address =%lx\n",
+						ph->hpte_data.source_address);
+	printk(KERN_INFO "HPTE source_length =%lx\n",
+						ph->hpte_data.source_length);
+	printk(KERN_INFO "HPTE length_copied =%lx\n",
+						ph->hpte_data.length_copied);
+
+	printk(KERN_INFO " SRSD AREA \n");
+	printk(KERN_INFO "SRSD dump_flags =%d\n", ph->kernel_data.dump_flags);
+	printk(KERN_INFO "SRSD source_type =%d\n", ph->kernel_data.source_type);
+	printk(KERN_INFO "SRSD error_flags =%d\n", ph->kernel_data.error_flags);
+	printk(KERN_INFO "SRSD source_address =%lx\n",
+						ph->kernel_data.source_address);
+	printk(KERN_INFO "SRSD source_length =%lx\n",
+						ph->kernel_data.source_length);
+	printk(KERN_INFO "SRSD length_copied =%lx\n",
+						ph->kernel_data.length_copied);
+#endif
+}
+
 static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
 {
 	int rc;
@@ -134,9 +189,9 @@ static void register_dump_area(struct ph
 		               1, ph, sizeof(struct phyp_dump_header));
 	} while (rtas_busy_delay(rc));
 
-	if (rc)
-	{
-		printk (KERN_ERR "phyp-dump: unexpected error (%d) on register\n", rc);
+	if (rc) {
+		printk(KERN_ERR "phyp-dump: unexpected error (%d) on register\n", rc);
+		print_dump_header(ph);
 	}
 }
 
@@ -238,6 +293,7 @@ static int __init phyp_dump_setup(void)
 	if (!phyp_dump_info->phyp_dump_configured) {
 		return -ENOSYS;
 	}
+	print_dump_header(dump_header);
 
 	/* Is there dump data waiting for us? If there isn't,
 	 * then register a new dump area, and release all of

^ permalink raw reply

* [PATCH 6/8] pseries: phyp dump: Invalidate and print dump areas.
From: Manish Ahuja @ 2008-02-12  7:18 UTC (permalink / raw)
  To: linuxppc-dev, paulus; +Cc: mahuja, linasvepstas
In-Reply-To: <47B13D2E.1070001@austin.ibm.com>


Routines to 
a. invalidate dump 
b. Calculate region that is reserved and needs to be freed. This is 
   exported through sysfs interface.

Unregister has been removed for now as it wasn't being used.

Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
-----

---
 arch/powerpc/platforms/pseries/phyp_dump.c |   85 +++++++++++++++++++++++++----
 include/asm/phyp_dump.h                    |    6 +-
 2 files changed, 79 insertions(+), 12 deletions(-)

Index: 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/platforms/pseries/phyp_dump.c	2008-02-12 06:13:06.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c	2008-02-12 06:13:17.000000000 -0600
@@ -69,6 +69,10 @@ static struct phyp_dump_header phdr;
 #define DUMP_SOURCE_CPU 0x0001
 #define DUMP_SOURCE_HPTE 0x0002
 #define DUMP_SOURCE_RMO  0x0011
+#define DUMP_ERROR_FLAG 0x2000
+#define DUMP_TRIGGERED 0x4000
+#define DUMP_PERFORMED 0x8000
+
 
 /**
  * init_dump_header() - initialize the header declaring a dump
@@ -180,9 +184,15 @@ static void print_dump_header(const stru
 static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
 {
 	int rc;
-	ph->cpu_data.destination_address += addr;
-	ph->hpte_data.destination_address += addr;
-	ph->kernel_data.destination_address += addr;
+
+	/* Add addr value if not initialized before */
+	if (ph->cpu_data.destination_address == 0) {
+		ph->cpu_data.destination_address += addr;
+		ph->hpte_data.destination_address += addr;
+		ph->kernel_data.destination_address += addr;
+	}
+
+	/* ToDo Invalidate kdump and free memory range. */
 
 	do {
 		rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
@@ -195,6 +205,30 @@ static void register_dump_area(struct ph
 	}
 }
 
+static
+void invalidate_last_dump(struct phyp_dump_header *ph, unsigned long addr)
+{
+	int rc;
+
+	/* Add addr value if not initialized before */
+	if (ph->cpu_data.destination_address == 0) {
+		ph->cpu_data.destination_address += addr;
+		ph->hpte_data.destination_address += addr;
+		ph->kernel_data.destination_address += addr;
+	}
+
+	do {
+		rc = rtas_call(ibm_configure_kernel_dump, 3, 1, NULL,
+		               2, ph, sizeof(struct phyp_dump_header));
+	} while (rtas_busy_delay(rc));
+
+	if (rc) {
+		printk (KERN_ERR "phyp-dump: unexpected error (%d) "
+						"on invalidate\n", rc);
+		print_dump_header(ph);
+	}
+}
+
 /* ------------------------------------------------- */
 /**
  * release_memory_range -- release memory previously lmb_reserved
@@ -205,8 +239,8 @@ static void register_dump_area(struct ph
  * lmb_reserved in early boot. The released memory becomes
  * available for genreal use.
  */
-static void
-release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
+static
+void release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
 {
 	struct page *rpage;
 	unsigned long end_pfn;
@@ -237,8 +271,8 @@ release_memory_range(unsigned long start
  *
  * will release 256MB starting at 1GB.
  */
-static ssize_t
-store_release_region(struct kset *kset, const char *buf, size_t count)
+static
+ssize_t store_release_region(struct kset *kset, const char *buf, size_t count)
 {
 	unsigned long start_addr, length, end_addr;
 	unsigned long start_pfn, nr_pages;
@@ -266,10 +300,23 @@ store_release_region(struct kset *kset, 
 	return count;
 }
 
-static ssize_t
-show_release_region(struct kset * kset, char *buf)
+static ssize_t show_release_region(struct kset * kset, char *buf)
 {
-	return sprintf(buf, "ola\n");
+	u64 second_addr_range;
+
+	/* total reserved size - start of scratch area */
+	second_addr_range = phyp_dump_info->init_reserve_size -
+				phyp_dump_info->reserved_scratch_size;
+	return sprintf(buf, "CPU:0x%lx-0x%lx: HPTE:0x%lx-0x%lx:"
+			    " DUMP:0x%lx-0x%lx, 0x%lx-0x%lx:\n",
+		phdr.cpu_data.destination_address,
+		phdr.cpu_data.length_copied,
+		phdr.hpte_data.destination_address,
+		phdr.hpte_data.length_copied,
+		phdr.kernel_data.destination_address,
+		phdr.kernel_data.length_copied,
+		phyp_dump_info->init_reserve_start,
+		second_addr_range);
 }
 
 static struct subsys_attribute rr = __ATTR(release_region, 0600,
@@ -293,7 +340,6 @@ static int __init phyp_dump_setup(void)
 	if (!phyp_dump_info->phyp_dump_configured) {
 		return -ENOSYS;
 	}
-	print_dump_header(dump_header);
 
 	/* Is there dump data waiting for us? If there isn't,
 	 * then register a new dump area, and release all of
@@ -305,6 +351,7 @@ static int __init phyp_dump_setup(void)
 	rtas = of_find_node_by_path("/rtas");
 	dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
 	of_node_put(rtas);
+	print_dump_header(dump_header);
 
 	dump_area_length = init_dump_header(&phdr);
 	dump_area_start = phyp_dump_info->init_reserve_start & PAGE_MASK; /* align down */
@@ -314,6 +361,22 @@ static int __init phyp_dump_setup(void)
 		return 0;
 	}
 
+	/* re-register the dump area, if old dump was invalid */
+	if ((dump_header) && (dump_header->status & DUMP_ERROR_FLAG)) {
+		invalidate_last_dump(&phdr, dump_area_start);
+		register_dump_area(&phdr, dump_area_start);
+		return 0;
+	}
+
+	if (dump_header) {
+		phyp_dump_info->reserved_scratch_addr =
+				dump_header->cpu_data.destination_address;
+		phyp_dump_info->reserved_scratch_size =
+				dump_header->cpu_data.source_length +
+				dump_header->hpte_data.source_length +
+				dump_header->kernel_data.source_length;
+	}
+
 	/* Should we create a dump_subsys, analogous to s390/ipl.c ? */
 	rc = subsys_create_file(&kernel_subsys, &rr);
 	if (rc)
Index: 2.6.24-rc5/include/asm/phyp_dump.h
===================================================================
--- 2.6.24-rc5.orig/include/asm/phyp_dump.h	2008-02-12 06:12:37.000000000 -0600
+++ 2.6.24-rc5/include/asm/phyp_dump.h	2008-02-12 06:13:17.000000000 -0600
@@ -18,7 +18,8 @@
 /* The RMR region will be saved for later dumping
  * whenever the kernel crashes. Set this to 256MB. */
 #define PHYP_DUMP_RMR_START 0x0
-#define PHYP_DUMP_RMR_END   (1UL<<28)
+/*#define PHYP_DUMP_RMR_END   (1UL<<28)*/
+#define PHYP_DUMP_RMR_END   (1UL<<27)
 
 struct phyp_dump {
 	/* Memory that is reserved during very early boot. */
@@ -30,6 +31,9 @@ struct phyp_dump {
 	/* store cpu & hpte size */
 	unsigned long cpu_state_size;
 	unsigned long hpte_region_size;
+	/* previous scratch area values */
+	unsigned long reserved_scratch_addr;
+	unsigned long reserved_scratch_size;
 };
 
 extern struct phyp_dump *phyp_dump_info;

^ permalink raw reply

* [PATCH 7/8] pseries: phyp dump: Tracking memory range freed.
From: Manish Ahuja @ 2008-02-12  7:20 UTC (permalink / raw)
  To: linuxppc-dev, paulus; +Cc: mahuja, linasvepstas
In-Reply-To: <47B13D2E.1070001@austin.ibm.com>

This patch tracks the size freed. For now it does a simple
rudimentary calculation of the ranges freed. The idea is
to keep it simple at the external shell script level and 
send in large chunks for now.

Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
-----

---
 arch/powerpc/platforms/pseries/phyp_dump.c |   35 +++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

Index: 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/platforms/pseries/phyp_dump.c	2008-02-12 06:13:17.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/platforms/pseries/phyp_dump.c	2008-02-12 06:13:21.000000000 -0600
@@ -259,6 +259,39 @@ void release_memory_range(unsigned long 
 	}
 }
 
+/**
+ * track_freed_range -- Counts the range being freed.
+ * Once the counter goes to zero, it re-registers dump for
+ * future use.
+ */
+static void
+track_freed_range(unsigned long addr, unsigned long length)
+{
+	static unsigned long scratch_area_size, reserved_area_size;
+
+	if (addr < phyp_dump_info->init_reserve_start)
+		return;
+
+	if ((addr >= phyp_dump_info->init_reserve_start) &&
+	    (addr <= phyp_dump_info->init_reserve_start +
+	     phyp_dump_info->init_reserve_size))
+		reserved_area_size += length;
+
+	if ((addr >= phyp_dump_info->reserved_scratch_addr) &&
+	    (addr <= phyp_dump_info->reserved_scratch_addr +
+	     phyp_dump_info->reserved_scratch_size))
+		scratch_area_size += length;
+
+	if ((reserved_area_size == phyp_dump_info->init_reserve_size) &&
+	    (scratch_area_size == phyp_dump_info->reserved_scratch_size)) {
+
+		invalidate_last_dump(&phdr,
+				phyp_dump_info->reserved_scratch_addr);
+		register_dump_area (&phdr,
+				phyp_dump_info->reserved_scratch_addr);
+	}
+}
+
 /* ------------------------------------------------- */
 /**
  * sysfs_release_region -- sysfs interface to release memory range.
@@ -282,6 +315,8 @@ ssize_t store_release_region(struct kset
 	if (ret != 2)
 		return -EINVAL;
 
+	track_freed_range(start_addr, length);
+
 	/* Range-check - don't free any reserved memory that
 	 * wasn't reserved for phyp-dump */
 	if (start_addr < phyp_dump_info->init_reserve_start)

^ permalink raw reply

* [PATCH 8/8] pseries: phyp dump: config file
From: Manish Ahuja @ 2008-02-12  7:21 UTC (permalink / raw)
  To: linuxppc-dev, paulus; +Cc: mahuja, linasvepstas, lkessler, strosake
In-Reply-To: <47B13D2E.1070001@austin.ibm.com>


Add hypervisor-assisted dump to kernel config

Signed-off-by: Linas Vepstas <linas@austin.ibm.com>

-----
 arch/powerpc/Kconfig |   11 +++++++++++
 1 file changed, 11 insertions(+)

Index: 2.6.24-rc5/arch/powerpc/Kconfig
===================================================================
--- 2.6.24-rc5.orig/arch/powerpc/Kconfig	2008-02-12 06:12:08.000000000 -0600
+++ 2.6.24-rc5/arch/powerpc/Kconfig	2008-02-12 06:13:24.000000000 -0600
@@ -266,6 +266,17 @@ config CRASH_DUMP
 
 	  Don't change this unless you know what you are doing.
 
+config PHYP_DUMP
+	bool "Hypervisor-assisted dump (EXPERIMENTAL)"
+	depends on PPC_PSERIES && EXPERIMENTAL
+	default y
+	help
+	  Hypervisor-assisted dump is meant to be a kdump replacement
+	  offering robustness and speed not possible without system
+	  hypervisor assistence.
+
+	  If unsure, say "Y"
+
 config PPCBUG_NVRAM
 	bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
 	default y if PPC_PREP

^ permalink raw reply

* Re: [BUG] 2.6.25-rc1-git1 softlockup while bootup on powerpc
From: Ingo Molnar @ 2008-02-12  7:58 UTC (permalink / raw)
  To: Kamalesh Babulal
  Cc: Dhaval Giani, Jens Axboe, Srivatsa Vaddagiri, LKML, linuxppc-dev,
	Balbir Singh
In-Reply-To: <47B1463E.1070809@linux.vnet.ibm.com>


* Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:

> While booting with the 2.6.25-rc1-git1 kernel on the powerbox the 
> softlockup is seen, with following trace.

> BUG: soft lockup - CPU#1 stuck for 61s! [insmod:377]
> TASK = c00000077cb2f0e0[377] 'insmod' THREAD: c00000077cb28000 CPU: 1
> NIP [c0000000001b172c] .radix_tree_gang_lookup+0xdc/0x1e4
> LR [c0000000001a6f00] .call_for_each_cic+0x50/0x10c
> Call Trace:
> [c00000077cb2bb20] [c0000000001a6f60] .call_for_each_cic+0xb0/0x10c (unreliable)
> [c00000077cb2bc60] [c00000000019ecd8] .exit_io_context+0xf0/0x110
> [c00000077cb2bcf0] [c00000000006254c] .do_exit+0x820/0x850
> [c00000077cb2bda0] [c000000000062648] .do_group_exit+0xcc/0xe8
> [c00000077cb2be30] [c00000000000872c] syscall_exit+0x0/0x40

this call_for_each_cic/radix_tree_gang_lookup locked up, and all other 
CPUs deadlocked in stopmachine, due to this one.

call_for_each_cic is in ./block/cfq-iosched.c uses RCU, but you've got 
classic-RCU:

  CONFIG_CLASSIC_RCU=y
  # CONFIG_PREEMPT_RCU is not set

so it's not related to the preempt-RCU changes either.

It is this part that locks up:

        do {
...
                nr = radix_tree_gang_lookup(&ioc->radix_root, (void **) cics,
                                                index, CIC_GANG_NR);
...
        } while (nr == CIC_GANG_NR);
...

it seems the radix tree will yield new entries again and again. Either 
it got corrupted, or some other CPU is filling it faster than we can 
deplete it [unlikely i think].

	Ingo

^ permalink raw reply

* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Michael Ellerman @ 2008-02-12  8:48 UTC (permalink / raw)
  To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47B145E9.9020907@austin.ibm.com>

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


On Tue, 2008-02-12 at 01:08 -0600, Manish Ahuja wrote:
> Initial patch for reserving memory in early boot, and freeing it later.
> If the previous boot had ended with a crash, the reserved memory would contain
> a copy of the crashed kernel data.
> 
> Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> 
> ----
>  arch/powerpc/kernel/prom.c                 |   50 ++++++++++++++++++++
>  arch/powerpc/kernel/rtas.c                 |   32 +++++++++++++
>  arch/powerpc/platforms/pseries/Makefile    |    1 
>  arch/powerpc/platforms/pseries/phyp_dump.c |   71 +++++++++++++++++++++++++++++
>  include/asm-powerpc/phyp_dump.h            |   38 +++++++++++++++
>  include/asm/rtas.h                         |    3 +
   ^^^^^^^^^^^^^^^^^^

asm/rtas.h doesn't exist. You need to clean your tree, and patch
asm-powerpc/rtas.h instead.

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: 189 bytes --]

^ permalink raw reply

* populate_rootfs fail
From: jay_chen @ 2008-02-12  8:53 UTC (permalink / raw)
  To: linuxppc-embedded

Hello all:

I am using mpc8548, kernel 2.6.14.5, and uboot as boot loader.
When I upgrade ram from 512MB to 2G, my kernel can't boot anymore.
(I pass mem=2048M to kernel in uboot now)

It always dies in exec sys_write( ) in populate_rootfs( ).
I did more tests about this and I found that sys_write( ) could write only
about 4MB in 2G ram case.
(My initrd is about 19MB, initrd_start  : 0xCE7C7000, initrd_end  :
0xCFAAF289, initrd_end - initrd_start  : 0x012E8289 ==> about 19MB)
Could anybody give me some hints?
Is this issue related to the location of  "/initrd.image"? Could I control
it?
Is there any size limit in ppc arch about ramdisk/initrd?

Thanks for help.

                  Jay...

void __init populate_rootfs(void)
{
	char *err;
               ...
#ifdef CONFIG_BLK_DEV_INITRD
	if (initrd_start) {
                                 ...
		printk("it isn't (%s); looks like an initrd\n", err);
		fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
		if (fd >= 0) {
			sys_write(fd, (char *)initrd_start,
					initrd_end - initrd_start);
			sys_close(fd);
			free_initrd();
		}
	}
#endif
}

^ permalink raw reply

* RE: [Spam Mail] populate_rootfs fail (This message should be blocked: ctfkl59804)
From: jay_chen @ 2008-02-12  9:36 UTC (permalink / raw)
  To: linuxppc-embedded-bounces+jay_chen=alphanetworks.com,
	linuxppc-embedded
In-Reply-To: <OF66FDCEB1.DBBF4F1E-ON482573ED.0030E325@alphanetworks.com>

One more thing:
I had changed default ramdisk size to about 80MB in kernel config.
(CONFIG_BLK_DEV_RAM_SIZE) 

I am so curious about the size limit and location in ram of "/initrd.image".
Which c file/document should I read?

                                         Jay...

-----Original Message-----
From: linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org] 
Sent: Tuesday, February 12, 2008 4:54 PM
To: linuxppc-embedded@ozlabs.org
Subject: [Spam Mail] populate_rootfs fail (This message should be blocked:
ctfkl59804)

Hello all:

I am using mpc8548, kernel 2.6.14.5, and uboot as boot loader.
When I upgrade ram from 512MB to 2G, my kernel can't boot anymore.
(I pass mem=2048M to kernel in uboot now)

It always dies in exec sys_write( ) in populate_rootfs( ).
I did more tests about this and I found that sys_write( ) could write only
about 4MB in 2G ram case.
(My initrd is about 19MB, initrd_start  : 0xCE7C7000, initrd_end  :
0xCFAAF289, initrd_end - initrd_start  : 0x012E8289 ==> about 19MB) Could
anybody give me some hints?
Is this issue related to the location of  "/initrd.image"? Could I control
it?
Is there any size limit in ppc arch about ramdisk/initrd?

Thanks for help.

                  Jay...

void __init populate_rootfs(void)
{
	char *err;
               ...
#ifdef CONFIG_BLK_DEV_INITRD
	if (initrd_start) {
                                 ...
		printk("it isn't (%s); looks like an initrd\n", err);
		fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
		if (fd >= 0) {
			sys_write(fd, (char *)initrd_start,
					initrd_end - initrd_start);
			sys_close(fd);
			free_initrd();
		}
	}
#endif
}

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
From: Stephen Rothwell @ 2008-02-12 10:08 UTC (permalink / raw)
  To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47B146BE.5010807@austin.ibm.com>

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

Hi Manish,

Just a small comment.

On Tue, 12 Feb 2008 01:11:58 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
> +	/* Is there dump data waiting for us? */
> +	rtas = of_find_node_by_path("/rtas");
> +	dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);

You need an of_node_put(rtas) here.

> +	if (dump_header == NULL) {
> +		release_all();
> +		return 0;
> +	}

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: [PATCH 4/8] pseries: phyp dump: register dump area.
From: Stephen Rothwell @ 2008-02-12 10:11 UTC (permalink / raw)
  To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47B14760.2030001@austin.ibm.com>

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

Hi Manish,

> -	/* Is there dump data waiting for us? */
> +	/* Is there dump data waiting for us? If there isn't,
> +	 * then register a new dump area, and release all of
> +	 * the rest of the reserved ram.
> +	 *
> +	 * The /rtas/ibm,kernel-dump rtas node is present only
> +	 * if there is dump data waiting for us.
> +	 */
>  	rtas = of_find_node_by_path("/rtas");
>  	dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
> +	of_node_put(rtas);

Oh, here is the of_node_put() - you should move that to patch 3.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: [PATCH 6/8] pseries: phyp dump: Invalidate and print dump areas.
From: Stephen Rothwell @ 2008-02-12 10:18 UTC (permalink / raw)
  To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47B1483E.8040303@austin.ibm.com>

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

Hi Manish,

On Tue, 12 Feb 2008 01:18:22 -0600 Manish Ahuja <ahuja@austin.ibm.com> wrote:
>
> -static void
> -release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
> +static
> +void release_memory_range(unsigned long start_pfn, unsigned long nr_pages)

Cosmetic changes like this should normally be put in separate patch as
they just distract from a real review (which this isn't :-))

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Writing drivers for external IP cores
From: A. Nolson @ 2008-02-12 11:54 UTC (permalink / raw)
  To: linuxppc-embedded

Hi ,

 I am going to start developing some IP cores for my virtex fx12 (ML403) 
and I need to control them through my embedded Linux ( it is already 
working in the ppc405 ).  I am a bit lost and I need some references for 
developing drivers. In principle, I will start with something like a 
GPIO. I think an example like a driver for controlling the push buttons 
of my Ml403 will be enough. An example IP core for that will also be 
also very helpful.

 Any suggestion?
 
 Thanks in advance

 /A

^ permalink raw reply

* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Gabriel Paubert @ 2008-02-12 11:49 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <1202460043.7079.157.camel@pasglop>

On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
> 
> On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > - couple of fixes and preparatory patches
> > 
> > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> >   [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> 
> Interesting... I was thinking about doing a full remove of the device at
> a higher level instead but I suppose what you propose is easier.

Well, I have serious problem on a Pegasos which appeared some time
between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of 

hdb: empty DMA table?

I'm trying to bisect it right now.

	Gabriel


> 
> I'll have a look & test next week hopefully.
> 
> Ben.
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Gabriel Paubert @ 2008-02-12 12:30 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20080212114905.GA9940@iram.es>

On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote:
> On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
> > 
> > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > - couple of fixes and preparatory patches
> > > 
> > > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > >   [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> > 
> > Interesting... I was thinking about doing a full remove of the device at
> > a higher level instead but I suppose what you propose is easier.
> 
> Well, I have serious problem on a Pegasos which appeared some time
> between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of 
> 
> hdb: empty DMA table?
> 
> I'm trying to bisect it right now.

Argh, the first bisect point ended up with timeouts on hdb...

Flagged as bad, to try to see when the problems started, but 
I suspect that there are several.

	Gabriel

^ permalink raw reply

* Re: Writing drivers for external IP cores
From: Marco Stornelli @ 2008-02-12 12:35 UTC (permalink / raw)
  To: A. Nolson; +Cc: linuxppc-embedded
In-Reply-To: <47B188F5.60607@gmail.com>

A. Nolson ha scritto:
> Hi ,
> 
>  I am going to start developing some IP cores for my virtex fx12 (ML403) 
> and I need to control them through my embedded Linux ( it is already 
> working in the ppc405 ).  I am a bit lost and I need some references for 
> developing drivers. In principle, I will start with something like a 
> GPIO. I think an example like a driver for controlling the push buttons 
> of my Ml403 will be enough. An example IP core for that will also be 
> also very helpful.
> 
>  Any suggestion?
>  
>  Thanks in advance
> 
>  /A
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
A good book to write device drivers is "Linux device drivers" 3rd
edition, it's free and you can download it freely from Internet

^ permalink raw reply

* Re: populate_rootfs fail
From: Marco Stornelli @ 2008-02-12 12:46 UTC (permalink / raw)
  To: jay_chen; +Cc: linuxppc-embedded
In-Reply-To: <OF66FDCEB1.DBBF4F1E-ON482573ED.0030E325@alphanetworks.com>

jay_chen ha scritto:
> Hello all:
> 
> I am using mpc8548, kernel 2.6.14.5, and uboot as boot loader.
> When I upgrade ram from 512MB to 2G, my kernel can't boot anymore.
> (I pass mem=2048M to kernel in uboot now)
> 
> It always dies in exec sys_write( ) in populate_rootfs( ).
> I did more tests about this and I found that sys_write( ) could write only
> about 4MB in 2G ram case.
> (My initrd is about 19MB, initrd_start  : 0xCE7C7000, initrd_end  :
> 0xCFAAF289, initrd_end - initrd_start  : 0x012E8289 ==> about 19MB)
> Could anybody give me some hints?
> Is this issue related to the location of  "/initrd.image"? Could I control
> it?
> Is there any size limit in ppc arch about ramdisk/initrd?
> 
> Thanks for help.
> 
>                   Jay...
> 
> void __init populate_rootfs(void)
> {
> 	char *err;
>                ...
> #ifdef CONFIG_BLK_DEV_INITRD
> 	if (initrd_start) {
>                                  ...
> 		printk("it isn't (%s); looks like an initrd\n", err);
> 		fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
> 		if (fd >= 0) {
> 			sys_write(fd, (char *)initrd_start,
> 					initrd_end - initrd_start);
> 			sys_close(fd);
> 			free_initrd();
> 		}
> 	}
> #endif
> }
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
I think can be a problem with the u-boot initrd_high option. Have you
been enabled the highmem support to use 2G of ram, right? You can try to
set this option to 0x30000000.

Marco

^ permalink raw reply

* Re: Writing drivers for external IP cores
From: Grant Likely @ 2008-02-12 14:56 UTC (permalink / raw)
  To: A. Nolson; +Cc: linuxppc-embedded
In-Reply-To: <47B188F5.60607@gmail.com>

On Feb 12, 2008 4:54 AM, A. Nolson <alohanono@gmail.com> wrote:
> Hi ,
>
>  I am going to start developing some IP cores for my virtex fx12 (ML403)
> and I need to control them through my embedded Linux ( it is already
> working in the ppc405 ).  I am a bit lost and I need some references for
> developing drivers. In principle, I will start with something like a
> GPIO. I think an example like a driver for controlling the push buttons
> of my Ml403 will be enough. An example IP core for that will also be
> also very helpful.

After you've got through the examples in Linux Device Drivers v3, you
can take a look at drivers/video/xilinxfb.c for an example of a driver
that works with an FPGA ip core.  Unfortunately there isn't a simple
xilinx GPIO driver in the mainline kernel at the moment, otherwise I'd
point you there.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: libfdt: Add and use a node iteration helper function.
From: Jon Loeliger @ 2008-02-12 15:15 UTC (permalink / raw)
  To: David Gibson; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080212005831.GH18348@localhost.localdomain>

So, like, the other day David Gibson mumbled:
> This patch adds an fdt_next_node() function which can be used to
> iterate through nodes of the tree while keeping track of depth.  This
> function is used to simplify the iteration code in a lot of other
> functions, and is also exported for use by library users.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> 
> ---
> 
> I think we're ready to go with this one.  I'm still thinking about
> suitable for_each_* macros, but in the mean time I'm happy with the
> exported interface here, and it's a code-reducing patch.

Applied.

Thanks,
jdl

^ permalink raw reply

* RE: [Virtex 4 PPC] Problem mountin rootfs via NFS
From: IngoM @ 2008-02-12 15:39 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <EE63F03D9E04774997AEBCD21FC77F25190363@ccomm-ex1.ccomm.com>


Hi,


Sugathan, Rupesh wrote:
> 
> <snip>
>  
> Do you have a 'console' device file set up in your NFS rootfilesystem? 
> 
> Thanks
> --
> Rupesh Sugathan
> 

you are right. 
I'm adding the device and can login via console.

But some trouble is left:
connected the board via a swich to the PC I loss packets, connectet directly
there are no packets lost.

Any hints?

Best Regards,

Ingo
-- 
View this message in context: http://www.nabble.com/-Virtex-4-PPC--Problem-mountin-rootfs-via-NFS-tp15355858p15434487.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Re: Could the DTS experts look at this?
From: Timur Tabi @ 2008-02-12 15:44 UTC (permalink / raw)
  To: Arnd Bergmann, David Gibson; +Cc: linuxppc-dev
In-Reply-To: <200802120121.45349.arnd@arndb.de>

Arnd Bergmann wrote:

> On Tuesday 12 February 2008, David Gibson wrote:
>> Or to expand.  It's relatively easy now to just include multiple nodes
>> in the tree and either delete or nop some of them out conditionally
>> using libfdt.  

Yes, but what better place to store the conditions than in the device tree 
itself?  How would libfdt know where the conditions are?  Do you want to have 
two binary blobs?

>> But the conditional logic should be in the manipulating
>> agent (u-boot or bootwrapper or whatever), there's no way we're going
>> to require a conditional expression parser to interpret the device
>> tree blob itself.

I think it's a great feature that solves a lot of problems, and it does so in an 
elegant and efficient manner.  I look forward to trying to change your mind when 
I get around to implementing it.

> How about making the logic to nop out nodes a little more generic
> without changes to the binary format?
> E.g. you could have a "linux,conditional-node" property in the device
> tree whose value is compared to a HW configuration specific string.

The problem with this is that if you use a version of libfdt that does not 
understand "linux,conditional-node", then your device tree will be wrong, 
because it could contain nodes that don't belong.  We would need a new, 
incompatible version number for the device tree to make sure that this doesn't 
happen, even though nothing has changed in the binary layout of the tree.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* DTS question - MPC5200b
From: Nick @ 2008-02-12 17:37 UTC (permalink / raw)
  To: linuxppc-dev

Hi,

I need some help.  I am trying to access timer 7 on the MPC5200B 
processor.  I have the DTS file setup like this

        gpt@670 {    // General Purpose Timer
          device_type = "gpt";
            compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
            cell-index = <7>;
            reg = <670 10>;
            interrupts = <1 10 0>;
            interrupt-parent = <&mpc5200_pic>;
        };

I have timers 0 to 6 defined the same way except the cell-index reflects 
the timer number.

In my platform file where I am doing my board setup, I tried the  following.

timer7 = mpc52xx_find_and_map ("mpc5200b-gpt");

How do I specify the timer based on the cell-index?

Thanks

Nick

^ permalink raw reply

* Re: [PATCH 4/8] pseries: phyp dump: register dump area.
From: Manish Ahuja @ 2008-02-12 16:31 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <20080212211154.f641abac.sfr@canb.auug.org.au>

For now, if we can leave this patch as is, that will be great. That move requires me 
to work all remaining patches as they apply uncleanly after that.

I will bunch those two together functionally next time onwards.

Thanks,
Manish


Stephen Rothwell wrote:
> Hi Manish,
> 
>> -	/* Is there dump data waiting for us? */
>> +	/* Is there dump data waiting for us? If there isn't,
>> +	 * then register a new dump area, and release all of
>> +	 * the rest of the reserved ram.
>> +	 *
>> +	 * The /rtas/ibm,kernel-dump rtas node is present only
>> +	 * if there is dump data waiting for us.
>> +	 */
>>  	rtas = of_find_node_by_path("/rtas");
>>  	dump_header = of_get_property(rtas, "ibm,kernel-dump", &header_len);
>> +	of_node_put(rtas);
> 
> Oh, here is the of_node_put() - you should move that to patch 3.
> 

^ permalink raw reply

* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-12 18:04 UTC (permalink / raw)
  To: Jan-Bernd Themann
  Cc: Themann, Jan-Bernd, netdev, linux-kernel, Thomas Klein, linux-ppc,
	Christoph Raisch, Greg KH
In-Reply-To: <200802111724.12416.ossthema@de.ibm.com>

On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to 
> update their internal DMA memory map when memory is added
> to or removed from the system.
> 
> Patch for eHEA memory hotplug support that uses these functions:
> http://www.spinics.net/lists/netdev/msg54484.html

This driver is broken pretty horribly.  It won't even compile for a
plain ppc64 kernel:

http://sr71.net/~dave/linux/ehea-is-broken.config

I know it's used for very specific hardware, but this is the symptom of
it not using the proper abstracted interfaces to the VM.

In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_main.c:42:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
  CC      drivers/net/mii.o
make[4]: *** [drivers/net/ehea/ehea_main.o] Error 1
make[4]: *** Waiting for unfinished jobs....
  CC      drivers/net/ixgb/ixgb_param.o
In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:32:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_create_busmap':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: 'NR_MEM_SECTIONS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: (Each undeclared identifier is reported only once
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: for each function it appears in.)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:575: error: implicit declaration of function 'valid_section_nr'
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_map_vaddr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:606: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_reg_kernel_mr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:655: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)

-- Dave

^ permalink raw reply

* Re: DTS question - MPC5200b
From: Grant Likely @ 2008-02-12 18:28 UTC (permalink / raw)
  To: Nick; +Cc: linuxppc-dev
In-Reply-To: <47B1D943.6020708@rogers.com>

On Feb 12, 2008 10:37 AM, Nick <ndroogh@rogers.com> wrote:
> Hi,
>
> I need some help.  I am trying to access timer 7 on the MPC5200B
> processor.  I have the DTS file setup like this
>
>         gpt@670 {    // General Purpose Timer
>           device_type = "gpt";
>             compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>             cell-index = <7>;
>             reg = <670 10>;
>             interrupts = <1 10 0>;
>             interrupt-parent = <&mpc5200_pic>;
>         };
>
> I have timers 0 to 6 defined the same way except the cell-index reflects
> the timer number.
>
> In my platform file where I am doing my board setup, I tried the  following.
>
> timer7 = mpc52xx_find_and_map ("mpc5200b-gpt");

Don't use find_and_map; it was a stupid API that I never should have written.

Instead, use for_each_compatible_node() or for_each_matching_node() to
iterate over them until you find the one with the correct reg address.

Then you can use of_iomap() to map the device registers.

> How do I specify the timer based on the cell-index?

Match on the reg property instead of cell-index; I'll probably be
dropping the cell-index property from future 5200 device trees because
it just ends up duplicating information already provided by reg.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox