Hi I had the same problem with CONFIG_SPARSEMEM and if I do not remember wrong I added: machdep->max_physmem_bits = _MAX_PHYSMEM_BITS; machdep->section_size_bits = _SECTION_SIZE_BITS; to arm.c and: #define _SECTION_SIZE_BITS 22 #define _MAX_PHYSMEM_BITS 32 to defs.h in a section for ARM. I am not certain what these figures stand for but they seems to work for me. Jan Karlsson -----Original Message----- From: crash-utility-bounces@xxxxxxxxxx [mailto:crash-utility-bounces@xxxxxxxxxx] On Behalf Of takuo.koguchi.sw@xxxxxxxxxxx Sent: tisdag den 24 maj 2011 14:07 To: crash-utility@xxxxxxxxxx; amer4554@xxxxxxxxx Subject: Re: DD image Hello Dave, >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. I have chosen this way for my arm target. Though snap.c told me how to create an elf header, it is too difficult for me to modify it to support ELF32 of ARM in addition to existing ELF64 support. So I just prepend a fixed ELF header which generate_elf_header would create. (1) I tried "an ELF header with just one PT_LOAD segment" vmcore file as you suggested and got the following, --------------------- $ ./crash vmlinux vmcore crash 5.1.5 Copyright (C) 2002-2011 Red Hat, Inc. ... This program has absolutely no warranty. Enter "help warranty" for details. crash: vmcore: not a supported file format Usage: crash [OPTION]... NAMELIST MEMORY-IMAGE (dumpfile form) crash [OPTION]... [NAMELIST] (live system form) Enter "crash -h" for details. ---------------------- The following is information of the file got by readelf command. Is there something wrong? $ arm-eabi-readelf -a vmcore ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: CORE (Core file) Machine: ARM Version: 0x1 Entry point address: 0x0 Start of program headers: 52 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 1 Size of section headers: 0 (bytes) Number of section headers: 0 Section header string table index: 0 <corrupt: out of range> There are no sections in this file. There are no sections in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000054 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0 There is no dynamic section in this file. There are no relocations in this file. There are no unwind sections in this file. No version information found in this file. ------------------------------------------------ (2) Next I tried "an ELF header with an empty PT_NOTE segment and just one PT_LOAD segment" This time readelf command shows Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0 LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE 0 And I could use this file as a core file for "arm-eabi-gdb vmlinux vmcore" For example "show init_task" works normally. Is this an expected behavior? (3) Above vmcore file works for gdb, but it does not work for crash(5.1.5). I got the following message and the crash command just exited. crash: CONFIG_SPARSEMEM kernels not supported for this architecture Would you please tell me how to support CONFIG_SPARSEMEM? I tried to add "machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;" in arm.c and made some progress. But still I cannot reach the crash prompt. I will appreciate any suggestion. Best Regard, Takuo Koguchi > >----- Original Message ----- >> Hi Dave, >> >> Thanks for your feedback , actually what I meant by minimizing the >> footprint that to not preform any action which requires instillation >> for any tool in order to image the memory. that to preserve the >> volatile data and not to overwrite information in memory such as >> terminated and cached processes. snap.so is good solution for live >> system but it first requires the instillation of crash in the >> investigated system which is not forensic sound. dd is small tool that >> comes with the most modern Linux destructions and forensic toolkits as >> it does not require instillation. if crash supports dd image then >> crach utility will be not only debugger but also forensic tool. >> >> thanks, >> Amer > >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 > >-- >Crash-utility mailing list >Crash-utility@xxxxxxxxxx >https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
