----- Original Message ----- OK, so you *are* suggesting that the dumpfile would be created something like this: $ dd if=/dev/mem of=memory-image bs=<page-size> What architecture is this for? And can you confirm that the /dev/mem read_mem() function will proceed without any of its error scenarios occurring before the last page of physical memory is read? There are these possible failures: if (!valid_phys_addr_range(p, count)) return -EFAULT; if (!range_is_allowed(p >> PAGE_SHIFT, count)) return -EPERM; ptr = xlate_dev_mem_ptr(p); if (!ptr) return -EFAULT; remaining = copy_to_user(buf, ptr, sz); unxlate_dev_mem_ptr(p, ptr); if (remaining) return -EFAULT; First, the valid_phys_addr_range() restricts /dev/mem to high_memory, or 896MB maximum on 32-bit architectures. The crash utility will still initialize, but several commands will fail if memory over that 896MB threshold are required. But more importantly, the xlate_dev_mem_ptr() call is the one that could possibly trip you up if the architecture is x86 or x86_64. I don't have a machine on-hand to test that because RHEL/Fedora kernels apply CONFIG_STRICT_DEVMEM, so /dev/mem is useless for that purpose. In any case, if the output file is page-for-page copy of physical memory, then creating support for it would be fairly easy. But I really don't want to expend any effort creating support for such a file format given the potential problems with the use of /dev/mem. On the other hand, it would also be fairly easy to create a small utility function that simply pre-pends an ELF header to the dumpfile -- one which has a single PT_LOAD section that describes the physical memory as one large chunk. For this simple format, you could take the snap.c extension module's generate_elf_header() function, have it create a an ELF header with just one PT_LOAD segment, and fold it into a standalone program. It has support for x86, x86_64, ppc64 and ia64. Dave