ramoops: use pstore interface

PATCH Superseded Kees Cook 3 participants 8 messages Nov 28, 2011 – Dec 3, 2011

Subsystems (2)

Documentation Char and misc drivers

lore

Share & tools

lore

Kees Cook

author

2011-11-28 20:11 UTC #0 lore raw

PATCH v2 1/1 ramoops: use pstore interface

Instead of using /dev/mem directly, use the common pstore infrastructure to handle Oops gathering and extraction.

Signed-off-by Kees Cook <[email protected]>

---
This depends on the pstore changes waiting for -next in:
http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next

---
 Documentation/ramoops.txt |    8 +-
 drivers/char/Kconfig      |    1 +
 drivers/char/ramoops.c    |  206 ++++++++++++++++++++++++++++++++++-----------
 3 files changed, 160 insertions(+), 55 deletions(-)

Documentation/ramoops.txt +4 -4

index 8fb1ba7..a0b9d8e 100644
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
 Sergiu Iordache <[email protected]>
 
-Updated: 8 August 2011
+Updated: 17 November 2011
 
 0. Introduction

@@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues with the actual data.
 
 4. Reading the data
 
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the data, can
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for these
+files is "dmesg-ramoops-N", where N is the record number in memory. To delete
+a stored record from RAM, simply unlink the respective pstore file.

drivers/char/Kconfig +1 -0

index 4364303..f166499 100644
@@ -603,6 +603,7 @@ source "drivers/s390/char/Kconfig"
 config RAMOOPS
 	tristate "Log panic/oops to a RAM buffer"
 	depends on HAS_IOMEM
+	depends on PSTORE
 	default n
 	help
 	  This enables panic and oops messages to be logged to a circular

drivers/char/ramoops.c +155 ~~-51~~

308 lines not on this page · raw message

Signature · 1 line

1.7.0.4

Chen Gong

2011-11-29 04:50 UTC #1 lore raw

Quoted 27 lines · Kees Cook

Instead of using /dev/mem directly, use the common pstore infrastructure to handle Oops gathering and extraction.
Signed-off-by Kees Cook<[email protected]>
---
This depends on the pstore changes waiting for -next in:
http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next
---
  Documentation/ramoops.txt |    8 +-
  drivers/char/Kconfig      |    1 +
  drivers/char/ramoops.c    |  206 ++++++++++++++++++++++++++++++++++-----------
  3 files changed, 160 insertions(+), 55 deletions(-)
Documentation/ramoops.txt +1 -1
index 8fb1ba7..a0b9d8e 100644
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
  Sergiu Iordache<[email protected]>
 
-Updated: 8 August 2011
+Updated: 17 November 2011
 
  0. Introduction
 

Documentation/ramoops.txt timestamp and a new line. The dump then continues with the actual data. · line 76

Quoted 9 lines

Documentation/ramoops.txt +3 -3

@@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues with the actual data.
 
  4. Reading the data
 
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the data, can
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for these
+files is "dmesg-ramoops-N", where N is the record number in memory. To delete
+a stored record from RAM, simply unlink the respective pstore file.

I think the definition of "mem_address" in the doc is not very clear. It is not a normal memory instead of a persistent RAM. I suggest adding more descriptions. It's better if there is a real example.

Quoted 113 lines

drivers/char/Kconfig +1 -0

index 4364303..f166499 100644
@@ -603,6 +603,7 @@ source "drivers/s390/char/Kconfig"
  config RAMOOPS
  	tristate "Log panic/oops to a RAM buffer"
  	depends on HAS_IOMEM
+	depends on PSTORE
  	default n
  	help
  	  This enables panic and oops messages to be logged to a circular

drivers/char/ramoops.c +53 ~~-16~~

index 7c7f42a..c544213 100644
@@ -2,6 +2,7 @@
   * RAM Oops/Panic logger
   *
   * Copyright (C) 2010 Marco Stornelli<[email protected]>
+ * Copyright (C) 2011 Kees Cook<[email protected]>
   *
   * This program is free software; you can redistribute it and/or
   * modify it under the terms of the GNU General Public License

@@ -24,7 +25,7 @@
  #include<linux/kernel.h>
  #include<linux/err.h>
  #include<linux/module.h>
-#include<linux/kmsg_dump.h>
+#include<linux/pstore.h>
  #include<linux/time.h>
  #include<linux/err.h>
  #include<linux/io.h>

@@ -56,74 +57,154 @@ module_param(dump_oops, int, 0600);
  MODULE_PARM_DESC(dump_oops,
  		"set to 1 to dump oopses, 0 to only dump panics (default 1)");
 
-static struct ramoops_context {
-	struct kmsg_dumper dump;
+struct ramoops_context {
  	void *virt_addr;
  	phys_addr_t phys_addr;
  	unsigned long size;
-	unsigned long record_size;
+	size_t record_size;
  	int dump_oops;
-	int count;
-	int max_count;
-} oops_cxt;
+	unsigned int count;
+	unsigned int max_count;
+	unsigned int read_count;
+	struct pstore_info pstore;
+};
 
  static struct platform_device *dummy;
  static struct ramoops_platform_data *dummy_data;
 
-static void ramoops_do_dump(struct kmsg_dumper *dumper,
-		enum kmsg_dump_reason reason, const char *s1, unsigned long l1,
-		const char *s2, unsigned long l2)
+static int ramoops_pstore_open(struct pstore_info *psi)
+{
+	struct ramoops_context *cxt = (struct ramoops_context *)psi->data;
+
+	cxt->read_count = 0;
+	return 0;
+}
+
+static ssize_t ramoops_pstore_read(u64 *id, enum pstore_type_id *type,
+				   struct timespec *time,
+				   char **buf,
+				   struct pstore_info *psi)
+{
+	ssize_t size;
+	char *rambuf;
+	struct ramoops_context *cxt = (struct ramoops_context *)psi->data;
+
+	if (cxt->read_count>= cxt->max_count)
+		return -EINVAL;
+	*id = cxt->read_count++;
+	/* Only supports dmesg output so far. */
+	*type = PSTORE_TYPE_DMESG;
+	/* TODO(kees): Bogus time for the moment. */
+	time->tv_sec = 0;
+	time->tv_nsec = 0;
+
+	rambuf = cxt->virt_addr + (*id * cxt->record_size);
+	size = strnlen(rambuf, cxt->record_size);
+	*buf = kmalloc(size, GFP_KERNEL);
+	if (*buf == NULL)
+		return -ENOMEM;
+	memcpy(*buf, rambuf, size);
+
+	return size;
+}
+
+static int ramoops_pstore_write(enum pstore_type_id type,
+				enum kmsg_dump_reason reason,
+				u64 *id,
+				unsigned int part,
+				size_t size, struct pstore_info *psi)
  {
-	struct ramoops_context *cxt = container_of(dumper,
-			struct ramoops_context, dump);
-	unsigned long s1_start, s2_start;
-	unsigned long l1_cpy, l2_cpy;
-	int res, hdr_size;
-	char *buf, *buf_orig;
+	char *buf;
+	size_t res;
  	struct timeval timestamp;
+	struct ramoops_context *cxt = (struct ramoops_context *)psi->data;

drivers/char/ramoops.c module_param(dump_oops, int, 0600); · line 130

Quoted 10 lines

drivers/char/ramoops.c +6 -0

+	size_t available = cxt->record_size;
 
+	/* Only store dmesg dumps. */
+	if (type != PSTORE_TYPE_DMESG)
+		return -EINVAL;
+
+	/* Only store crash dumps. */
  	if (reason != KMSG_DUMP_OOPS&&
  	reason != KMSG_DUMP_PANIC&&
  	reason != KMSG_DUMP_KEXEC)

As Andrew mentioned here (http://lkml.org/lkml/2011/11/28/495),
who should take this responsibility to fix this issue when conflicting

Kees Cook

author

2011-11-29 17:24 UTC #2 lore raw

Quoted 35 lines · Chen Gong

Quoted 34 lines · Kees Cook
Instead of using /dev/mem directly, use the common pstore infrastructure to handle Oops gathering and extraction.
Signed-off-by Kees Cook<[email protected]>
---
This depends on the pstore changes waiting for -next in:
http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next
---
Documentation/ramoops.txt | 8 +-
drivers/char/Kconfig | 1 +
drivers/char/ramoops.c | 206
++++++++++++++++++++++++++++++++++-----------
 3 files changed, 160 insertions(+), 55 deletions(-)
Documentation/ramoops.txt +0 -0
index 8fb1ba7..a0b9d8e 100644
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
Sergiu Iordache<[email protected]>
Documentation/ramoops.txt +1 -1
-Updated: 8 August 2011
+Updated: 17 November 2011
0. Introduction
Documentation/ramoops.txt +0 -0
@@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues with
the actual data.
4. Reading the data

Quoted 14 lines

Quoted 9 lines
Documentation/ramoops.txt +0 -2
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the
data, can
Documentation/ramoops.txt +1 -1
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for
these
+files is "dmesg-ramoops-N", where N is the record number in memory. To delete
+a stored record from RAM, simply unlink the respective pstore file.
I think the definition of "mem_address" in the doc is not very clear. It is not a normal memory instead of a persistent RAM. I suggest adding more descriptions.
It's better if there is a real example.

Okay. I'm not sure it's in the scope of this patch, but I can try.

Marco, do you have suggestions for how this could be enhanced?

Quoted 8 lines

...
Quoted 4 lines
+ /* Only store crash dumps. */
if (reason != KMSG_DUMP_OOPS&&
reason != KMSG_DUMP_PANIC&&
reason != KMSG_DUMP_KEXEC)
As Andrew mentioned here (http://lkml.org/lkml/2011/11/28/495),
who should take this responsibility to fix this issue when conflicting

Has the "remove KMSG_DUMP_KEXEC" patch been taken? I'm happy to drop it from the ramoops patch. It's trivial to do so.

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

Marco Stornelli

2011-12-01 10:37 UTC #3 lore raw

Il 29/11/2011 18:24, Kees Cook ha scritto:

Quoted 51 lines · Chen Gong

Quoted 35 lines
Quoted 34 lines · Kees Cook
Instead of using /dev/mem directly, use the common pstore infrastructure to handle Oops gathering and extraction.
Signed-off-by Kees Cook<[email protected]>
---
This depends on the pstore changes waiting for -next in:
http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next
---
  Documentation/ramoops.txt |    8 +-
  drivers/char/Kconfig      |    1 +
  drivers/char/ramoops.c    |  206
++++++++++++++++++++++++++++++++++-----------
  3 files changed, 160 insertions(+), 55 deletions(-)
Documentation/ramoops.txt +1 -1
index 8fb1ba7..a0b9d8e 100644
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
  Sergiu Iordache<[email protected]>
 
-Updated: 8 August 2011
+Updated: 17 November 2011
 
  0. Introduction
 
@@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues with
the actual data.
4. Reading the data
Quoted 14 lines
Quoted 9 lines
Documentation/ramoops.txt +0 -2
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the
data, can
Documentation/ramoops.txt +1 -1
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for
these
+files is "dmesg-ramoops-N", where N is the record number in memory. To delete
+a stored record from RAM, simply unlink the respective pstore file.
I think the definition of "mem_address" in the doc is not very clear. It is not a normal memory instead of a persistent RAM. I suggest adding more descriptions.
It's better if there is a real example.

Quoted 4 lines

Okay. I'm not sure it's in the scope of this patch, but I can try.
Marco, do you have suggestions for how this could be enhanced?

I don't know actually. It's not mandatory use a persistent memory. A simple piece of reserved RAM is ok. Obviously it will work only over reboot and not over power down. I define mem_address as a generic piece of reserved memory.

Marco

Chen Gong

2011-12-02 02:41 UTC #4 lore raw

Quoted 55 lines · Marco Stornelli

Il 29/11/2011 18:24, Kees Cook ha scritto:
Quoted 54 lines · Chen Gong
Quoted 36 lines
Quoted 35 lines · Kees Cook
Instead of using /dev/mem directly, use the common pstore infrastructure to handle Oops gathering and extraction.
Signed-off-by Kees Cook<[email protected]>
---
This depends on the pstore changes waiting for -next in:
http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next
---
Documentation/ramoops.txt | 8 +-
drivers/char/Kconfig | 1 +
drivers/char/ramoops.c | 206
++++++++++++++++++++++++++++++++++-----------
3 files changed, 160 insertions(+), 55 deletions(-)
Documentation/ramoops.txt +0 -0
index 8fb1ba7..a0b9d8e 100644
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
Sergiu Iordache<[email protected]>
Documentation/ramoops.txt +1 -1
-Updated: 8 August 2011
+Updated: 17 November 2011
0. Introduction
Documentation/ramoops.txt +0 -0
@@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues with
the actual data.
4. Reading the data
Quoted 14 lines
Quoted 9 lines
Documentation/ramoops.txt +0 -2
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the
data, can
Documentation/ramoops.txt +1 -1
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for
these
+files is "dmesg-ramoops-N", where N is the record number in memory. To delete
+a stored record from RAM, simply unlink the respective pstore file.
I think the definition of "mem_address" in the doc is not very clear. It is not a normal memory instead of a persistent RAM. I suggest adding more descriptions.
It's better if there is a real example.
Okay. I'm not sure it's in the scope of this patch, but I can try.

Quoted 8 lines

Quoted 2 lines
Marco, do you have suggestions for how this could be enhanced?
I don't know actually. It's not mandatory use a persistent memory. A simple piece of reserved RAM is ok. Obviously it will work only over reboot and not over power down. I define mem_address as a generic piece of reserved memory.
Marco

Anyway, we need a pratical exmaple to instruct us how to use this diver.

Marco Stornelli

2011-12-02 08:26 UTC #5 lore raw

Il 02/12/2011 03:40, Chen Gong ha scritto:

Quoted 73 lines

Quoted 72 lines · Marco Stornelli
Il 29/11/2011 18:24, Kees Cook ha scritto:
Quoted 59 lines
Quoted 48 lines · Chen Gong
Quoted 47 lines · Kees Cook
Instead of using /dev/mem directly, use the common pstore infrastructure
to handle Oops gathering and extraction.
Signed-off-by Kees Cook<[email protected]>
---
This depends on the pstore changes waiting for -next in:
http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next
---
Documentation/ramoops.txt | 8 +-
drivers/char/Kconfig | 1 +
drivers/char/ramoops.c | 206
++++++++++++++++++++++++++++++++++-----------
3 files changed, 160 insertions(+), 55 deletions(-)
Documentation/ramoops.txt +0 -0
index 8fb1ba7..a0b9d8e 100644
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
Sergiu Iordache<[email protected]>
Documentation/ramoops.txt +1 -1
-Updated: 8 August 2011
+Updated: 17 November 2011
0. Introduction
Documentation/ramoops.txt +0 -0
@@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues
with
the actual data.
4. Reading the data
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the data, can
Documentation/ramoops.txt +1 -1
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for
these
+files is "dmesg-ramoops-N", where N is the record number in memory. To
Quoted 8 lines
Quoted 2 lines
delete
+a stored record from RAM, simply unlink the respective pstore file.
I think the definition of "mem_address" in the doc is not very clear. It is
not a normal memory instead of a persistent RAM. I suggest adding more descriptions.
It's better if there is a real example.
Quoted 4 lines
Okay. I'm not sure it's in the scope of this patch, but I can try.
Marco, do you have suggestions for how this could be enhanced?
I don't know actually. It's not mandatory use a persistent memory. A simple
piece of reserved RAM is ok. Obviously it will work only over reboot and not
over power down. I define mem_address as a generic piece of reserved memory.

Quoted 5 lines

Quoted 1 line
Marco
Anyway, we need a pratical exmaple to instruct us how to use this diver.

For example we can use the mem parameter to reserve memory and use it as ramoops buffer, very simple.

Kees Cook

author

2011-12-02 19:19 UTC #6 lore raw

Quoted 80 lines · Marco Stornelli

Il 02/12/2011 03:40, Chen Gong ha scritto:
Quoted 78 lines
Quoted 76 lines · Marco Stornelli
Il 29/11/2011 18:24, Kees Cook ha scritto:
Quoted 64 lines
Quoted 52 lines · Chen Gong
Quoted 50 lines · Kees Cook
Instead of using /dev/mem directly, use the common pstore infrastructure
to handle Oops gathering and extraction.
Signed-off-by Kees Cook<[email protected]>
---
This depends on the pstore changes waiting for -next in:
http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next
---
Documentation/ramoops.txt | 8 +-
drivers/char/Kconfig | 1 +
drivers/char/ramoops.c | 206
++++++++++++++++++++++++++++++++++-----------
3 files changed, 160 insertions(+), 55 deletions(-)
Documentation/ramoops.txt +0 -0
index 8fb1ba7..a0b9d8e 100644
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
Sergiu Iordache<[email protected]>
Documentation/ramoops.txt +1 -1
-Updated: 8 August 2011
+Updated: 17 November 2011
0. Introduction
Documentation/ramoops.txt +0 -0
@@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues
with
the actual data.
4. Reading the data
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the data, can
Documentation/ramoops.txt +1 -1
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for
these
+files is "dmesg-ramoops-N", where N is the record number in memory. To
delete
Quoted 8 lines
Quoted 1 line
+a stored record from RAM, simply unlink the respective pstore file.
I think the definition of "mem_address" in the doc is not very clear. It is
not a normal memory instead of a persistent RAM. I suggest adding more descriptions.
It's better if there is a real example.
Quoted 3 lines
Okay. I'm not sure it's in the scope of this patch, but I can try.
Marco, do you have suggestions for how this could be enhanced?
I don't know actually. It's not mandatory use a persistent memory. A simple
piece of reserved RAM is ok. Obviously it will work only over reboot and not
over power down. I define mem_address as a generic piece of reserved memory.

Quoted 4 lines

Quoted 1 line
Anyway, we need a pratical exmaple to instruct us how to use this diver.
For example we can use the mem parameter to reserve memory and use it as ramoops buffer, very simple.

I tried both "mem" and "memmap":

mem=0x3f000000 ramoops.mem_address=0x3f000000 ramoops.mem_size=0x40000 ramoops.record_size=0x10000

memmap=256K$0x3f000000 ramoops.mem_address=0x3f000000 ramoops.mem_size=0x40000 ramoops.record_size=0x10000

Neither works for me (I end up triggering a panic via BUG in kfree). I wonder if it's some bad interaction between the cmdline and the memory tables? When I boot with mem=0x3f000000 and without ramoops, I see in /proc/iomem:

00100000-3effffff : System RAM
01000000-0137c35f : Kernel code
0137c360-0151e85f : Kernel data
01591000-01627fff : Kernel bss
3f000000-3fffcfff : RAM buffer

It seems like the system isn't ignoring the region? What's the right way to do this?

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

Marco Stornelli

2011-12-03 08:53 UTC #7 lore raw

Il 02/12/2011 20:19, Kees Cook ha scritto:

Quoted 106 lines

Quoted 80 lines · Marco Stornelli
Il 02/12/2011 03:40, Chen Gong ha scritto:
Quoted 78 lines
Quoted 76 lines · Marco Stornelli
Il 29/11/2011 18:24, Kees Cook ha scritto:
Quoted 64 lines
Quoted 52 lines · Chen Gong
Quoted 50 lines · Kees Cook
Instead of using /dev/mem directly, use the common pstore infrastructure
to handle Oops gathering and extraction.
Signed-off-by Kees Cook<[email protected]>
---
This depends on the pstore changes waiting for -next in:
http://git.kernel.org/?p=linux/kernel/git/aegl/linux.git;a=shortlog;h=refs/heads/next
---
Documentation/ramoops.txt | 8 +-
drivers/char/Kconfig | 1 +
drivers/char/ramoops.c | 206
++++++++++++++++++++++++++++++++++-----------
3 files changed, 160 insertions(+), 55 deletions(-)
Documentation/ramoops.txt +0 -0
index 8fb1ba7..a0b9d8e 100644
@@ -3,7 +3,7 @@ Ramoops oops/panic logger
 
Sergiu Iordache<[email protected]>
Documentation/ramoops.txt +1 -1
-Updated: 8 August 2011
+Updated: 17 November 2011
0. Introduction
Documentation/ramoops.txt +0 -0
@@ -71,6 +71,6 @@ timestamp and a new line. The dump then continues
with
the actual data.
4. Reading the data
-The dump data can be read from memory (through /dev/mem or other means).
-Getting the module parameters, which are needed in order to parse the data, can
Documentation/ramoops.txt +1 -1
-be done through /sys/module/ramoops/parameters/* .
+The dump data can be read from the pstore filesystem. The format for
these
+files is "dmesg-ramoops-N", where N is the record number in memory. To
delete
Quoted 8 lines
Quoted 1 line
+a stored record from RAM, simply unlink the respective pstore file.
I think the definition of "mem_address" in the doc is not very clear. It is
not a normal memory instead of a persistent RAM. I suggest adding more descriptions.
It's better if there is a real example.
Quoted 3 lines
Okay. I'm not sure it's in the scope of this patch, but I can try.
Marco, do you have suggestions for how this could be enhanced?
I don't know actually. It's not mandatory use a persistent memory. A simple
piece of reserved RAM is ok. Obviously it will work only over reboot and not
over power down. I define mem_address as a generic piece of reserved memory.
Quoted 4 lines
Quoted 1 line
Anyway, we need a pratical exmaple to instruct us how to use this diver.
For example we can use the mem parameter to reserve memory and use it as ramoops buffer, very simple.
I tried both "mem" and "memmap":
mem=0x3f000000 ramoops.mem_address=0x3f000000 ramoops.mem_size=0x40000 ramoops.record_size=0x10000
memmap=256K$0x3f000000 ramoops.mem_address=0x3f000000 ramoops.mem_size=0x40000 ramoops.record_size=0x10000
Neither works for me (I end up triggering a panic via BUG in kfree). I wonder if it's some bad interaction between the cmdline and the memory tables? When I boot with mem=0x3f000000 and without ramoops, I see in /proc/iomem:
00100000-3effffff : System RAM
01000000-0137c35f : Kernel code
0137c360-0151e85f : Kernel data
01591000-01627fff : Kernel bss
3f000000-3fffcfff : RAM buffer

Quoted 5 lines

It seems like the system isn't ignoring the region? What's the right way to do this?
-Kees

I don't know, however in that situation it's normal to have a crash, if you use the RAM buffer region, you should see "reserved" in iomem. It can be an other kind of problem.

Marco