7:07 a.m.
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(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
7:24 a.m.
New subject: DD image
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(a)redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf
Of takuo.koguchi.sw(a)hitachi.com
Sent: tisdag den 24 maj 2011 14:07
To: crash-utility(a)redhat.com; amer4554(a)gmail.com
Subject: Re: [Crash-utility] 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(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
8:46 a.m.
New subject: DD image
----- Original Message -----
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
There seems to be some discussion about future support for SPARSEMEM
on ARM, although like I mentioned before, it doesn't appear to be
in the latest upstream kernel as of yet.
In any case, for it to apply to the crash utility, it should be a
matter of supplying the _MAX_PHYSMEM_BITS and _SECTION_SIZE_BITS
#define's that match the kernel's MAX_PHYSMEM_BITS and SECTION_SIZE_BITS.
And then in arm_init(), they should be initialized as you've shown
above.
Dave
8:58 a.m.
New subject: ARM support for CONFIG_SPARSEMEM: (was Re: DD image)
----- Original Message -----
----- Original Message -----
> 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
>
There seems to be some discussion about future support for SPARSEMEM
on ARM, although like I mentioned before, it doesn't appear to be
in the latest upstream kernel as of yet.
In any case, for it to apply to the crash utility, it should be a
matter of supplying the _MAX_PHYSMEM_BITS and _SECTION_SIZE_BITS
#define's that match the kernel's MAX_PHYSMEM_BITS and SECTION_SIZE_BITS.
And then in arm_init(), they should be initialized as you've shown
above.
Dave
BTW, I await any patches from the ARM folks to set these bits
appropriately. Currently there is this for ARM in defs.h:
#ifdef ARM
... [ cut ] ...
#define _SECTION_SIZE_BITS 28
#define _MAX_PHYSMEM_BITS 32
#endif /* ARM */
Yet you state above that you're using 22 for _SECTION_SIZE_BITS.
So let me know what you guys want.
Thanks,
Dave
1:53 p.m.
New subject: ARM support for CONFIG_SPARSEMEM: (was Re: DD image)
[ dropped my Nokia address from the CC list, since I'm not working for Nokia
anymore ]
On Tue, May 24, 2011 at 09:58:48AM -0400, Dave Anderson wrote:
BTW, I await any patches from the ARM folks to set these bits
appropriately. Currently there is this for ARM in defs.h:
#ifdef ARM
... [ cut ] ...
#define _SECTION_SIZE_BITS 28
#define _MAX_PHYSMEM_BITS 32
#endif /* ARM */
Yet you state above that you're using 22 for _SECTION_SIZE_BITS.
This varies between different SoCs and it is not used by others. Since it is
not stored in a crashdump IIRC, we really cannot set that value dynamically.
So I see two options:
1) leave it as is and make crash to complain when it detects such
situation or
2) guess the values and try to do the right thing (TM)
My preference goes with 2) provided that we can get it working on majority of
the ARM SoCs.
We could try to stick with _SECTION_SIZE_BITS=28, as it seems to be largest
currently used section size amongst different ARM SoCs, and hope that it works
with others where this is smaller.
Jan, Takuo: maybe you could try whether following patch works? I don't have
any hardware which use SPARSEMEM so I'm unable to test it.
Regards,
MW
diff --git a/arm.c b/arm.c
index 0347166..9d4afcc 100644
--- a/arm.c
+++ b/arm.c
@@ -260,6 +260,9 @@ arm_init(int when)
STRUCT_EXISTS("pteval_t"))
machdep->flags |= PGTABLE_V2;
+ machdep->section_size_bits = _SECTION_SIZE_BITS;
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+
if (symbol_exists("irq_desc"))
ARRAY_LENGTH_INIT(machdep->nr_irqs, irq_desc,
"irq_desc", NULL, 0);
12:07 a.m.
New subject: ARM support for CONFIG_SPARSEMEM: (was Re: DDimage)
Thanks Dave, MW, Jan,
I tried the patch which set machdep->section_size_bits and
machdep->max_physmem_bits.
When _SECTION_SIZE_BITS is 28, I got the following error, and failed in sparse_mem_init()
PAGESIZE=4096
mem_section_size = 0
NR_SECTION_ROOTS = 0
NR_MEM_SECTIONS = 16
SECTIONS_PER_ROOT = 512
SECTION_ROOT_MASK = 0x1ff
PAGES_PER_SECTION = 65536
crash: invalid size request: 0 type: "memory section root table"
And when _SECTION_SIZE_BITS is 22, I got the following and sparse_mem_init() returns with
out error.
PAGESIZE=4096
mem_section_size = 8
NR_SECTION_ROOTS = 2
NR_MEM_SECTIONS = 1024
SECTIONS_PER_ROOT = 512
SECTION_ROOT_MASK = 0x1ff
PAGES_PER_SECTION = 1024
... But I got another error later, which I will report later.
In memory.c:sparse_mem_init(),
vt->mem_sec is malloced as mem_section_size bytes block and readmem is called.
I suppose the mem_section_size should not be zero. I do not know _SECTION_SIZE_BITS 22 is
correct or not,
but the following caliculation of NR_SECTION_ROOTS() looks suspicious to me.
#define NR_SECTION_ROOTS() (NR_MEM_SECTIONS() / SECTIONS_PER_ROOT())
Something like (((NR_MEM_SECTIONS() - 1)/ SECTIONS_PER_ROOT()) + 1) ?
Best Regard,
Takuo
[ dropped my Nokia address from the CC list, since I'm not working
for Nokia
anymore ]
On Tue, May 24, 2011 at 09:58:48AM -0400, Dave Anderson wrote:
>
> BTW, I await any patches from the ARM folks to set these bits
> appropriately. Currently there is this for ARM in defs.h:
>
> #ifdef ARM
> ... [ cut ] ...
>
> #define _SECTION_SIZE_BITS 28
> #define _MAX_PHYSMEM_BITS 32
>
> #endif /* ARM */
>
> Yet you state above that you're using 22 for _SECTION_SIZE_BITS.
This varies between different SoCs and it is not used by others. Since it is
not stored in a crashdump IIRC, we really cannot set that value dynamically.
So I see two options:
1) leave it as is and make crash to complain when it detects such
situation or
2) guess the values and try to do the right thing (TM)
My preference goes with 2) provided that we can get it working on majority of
the ARM SoCs.
We could try to stick with _SECTION_SIZE_BITS=28, as it seems to be largest
currently used section size amongst different ARM SoCs, and hope that it works
with others where this is smaller.
Jan, Takuo: maybe you could try whether following patch works? I don't have
any hardware which use SPARSEMEM so I'm unable to test it.
Regards,
MW
diff --git a/arm.c b/arm.c
index 0347166..9d4afcc 100644
--- a/arm.c
+++ b/arm.c
@@ -260,6 +260,9 @@ arm_init(int when)
STRUCT_EXISTS("pteval_t"))
machdep->flags |= PGTABLE_V2;
+ machdep->section_size_bits = _SECTION_SIZE_BITS;
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+
if (symbol_exists("irq_desc"))
ARRAY_LENGTH_INIT(machdep->nr_irqs, irq_desc,
"irq_desc", NULL, 0);
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
1:47 a.m.
New subject: ARM support for CONFIG_SPARSEMEM: (was Re: DDimage)
On Wed, May 25, 2011 at 8:07 AM, <takuo.koguchi.sw(a)hitachi.com> wrote:
Thanks Dave, MW, Jan,
I tried the patch which set machdep->section_size_bits and
machdep->max_physmem_bits.
When _SECTION_SIZE_BITS is 28, I got the following error, and failed in
sparse_mem_init()
PAGESIZE=4096
mem_section_size = 0
NR_SECTION_ROOTS = 0
NR_MEM_SECTIONS = 16
SECTIONS_PER_ROOT = 512
SECTION_ROOT_MASK = 0x1ff
PAGES_PER_SECTION = 65536
crash: invalid size request: 0 type: "memory section root table"
And when _SECTION_SIZE_BITS is 22, I got the following and sparse_mem_init() returns with
out error.
PAGESIZE=4096
mem_section_size = 8
NR_SECTION_ROOTS = 2
NR_MEM_SECTIONS = 1024
SECTIONS_PER_ROOT = 512
SECTION_ROOT_MASK = 0x1ff
PAGES_PER_SECTION = 1024
... But I got another error later, which I will report later.
Is it possible to provide me a sample vmlinux/vmcore pair which I
could use for testing?
3:18 a.m.
New subject: ARM support for CONFIG_SPARSEMEM: (was Re:DDimage)
Mika,
Is it possible to provide me a sample vmlinux/vmcore pair which I
could use for testing?
I am very sorry, but probably I cannot do that...
Takuo
>On Wed, May 25, 2011 at 8:07 AM, <takuo.koguchi.sw(a)hitachi.com> wrote:
>> Thanks Dave, MW, Jan,
>>
>> I tried the patch which set machdep->section_size_bits and
machdep->max_physmem_bits.
>>
>> When _SECTION_SIZE_BITS is 28, I got the following error, and failed in
sparse_mem_init()
>> PAGESIZE=4096
>> mem_section_size = 0
>> NR_SECTION_ROOTS = 0
>> NR_MEM_SECTIONS = 16
>> SECTIONS_PER_ROOT = 512
>> SECTION_ROOT_MASK = 0x1ff
>> PAGES_PER_SECTION = 65536
>> crash: invalid size request: 0 type: "memory section root table"
>>
>>
>> And when _SECTION_SIZE_BITS is 22, I got the following and sparse_mem_init()
returns with out error.
>>
>> PAGESIZE=4096
>> mem_section_size = 8
>> NR_SECTION_ROOTS = 2
>> NR_MEM_SECTIONS = 1024
>> SECTIONS_PER_ROOT = 512
>> SECTION_ROOT_MASK = 0x1ff
>> PAGES_PER_SECTION = 1024
>>
>> ... But I got another error later, which I will report later.
>>
>
Is it possible to provide me a sample vmlinux/vmcore pair which I
could use for testing?
>
>--
>Crash-utility mailing list
>Crash-utility(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
1:07 a.m.
New subject: ARM support for CONFIG_SPARSEMEM: (was Re: DD image)
Hi Mika,
The patch you give below is equal to the code I have been running for the last half year.
I did not supply this as a patch, as I did not know how to set _MAX_PHYSMEM_BITS. I just
tried a few values until everything seemed to work.
Jan
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf
Of Mika Westerberg
Sent: tisdag den 24 maj 2011 20:54
To: Discussion list for crash utility usage, maintenance and development
Cc: amer4554(a)gmail.com
Subject: Re: [Crash-utility] ARM support for CONFIG_SPARSEMEM: (was Re: DD image)
[ dropped my Nokia address from the CC list, since I'm not working for Nokia
anymore ]
On Tue, May 24, 2011 at 09:58:48AM -0400, Dave Anderson wrote:
BTW, I await any patches from the ARM folks to set these bits
appropriately. Currently there is this for ARM in defs.h:
#ifdef ARM
... [ cut ] ...
#define _SECTION_SIZE_BITS 28
#define _MAX_PHYSMEM_BITS 32
#endif /* ARM */
Yet you state above that you're using 22 for _SECTION_SIZE_BITS.
This varies between different SoCs and it is not used by others. Since it is
not stored in a crashdump IIRC, we really cannot set that value dynamically.
So I see two options:
1) leave it as is and make crash to complain when it detects such
situation or
2) guess the values and try to do the right thing (TM)
My preference goes with 2) provided that we can get it working on majority of
the ARM SoCs.
We could try to stick with _SECTION_SIZE_BITS=28, as it seems to be largest
currently used section size amongst different ARM SoCs, and hope that it works
with others where this is smaller.
Jan, Takuo: maybe you could try whether following patch works? I don't have
any hardware which use SPARSEMEM so I'm unable to test it.
Regards,
MW
diff --git a/arm.c b/arm.c
index 0347166..9d4afcc 100644
--- a/arm.c
+++ b/arm.c
@@ -260,6 +260,9 @@ arm_init(int when)
STRUCT_EXISTS("pteval_t"))
machdep->flags |= PGTABLE_V2;
+ machdep->section_size_bits = _SECTION_SIZE_BITS;
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+
if (symbol_exists("irq_desc"))
ARRAY_LENGTH_INIT(machdep->nr_irqs, irq_desc,
"irq_desc", NULL, 0);
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
8:31 a.m.
New subject: DD image
----- Original Message -----
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
That's what you need -- it is presumed that there will be a minimum
of two program header sections:
(1) at least one PT_NOTE section (typically an NT_PRSTATUS note w/registers)
(2) at least one PT_LOAD section (which you have)
so without the empty PT_NOTE, it was failing here in is_netdump():
if ((elf32->e_ident[EI_CLASS] == ELFCLASS32) &&
(swap16(elf32->e_type, swap) == ET_CORE) &&
(swap32(elf32->e_version, swap) == EV_CURRENT) &&
(swap16(elf32->e_phnum, swap) >= 2)) {
because your elf32->e_phnum was 1:
Number of program headers: 1
So, yes, adding an empty PT_NOTE should be OK to get by that error.
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.
As far as the CONFIG_SPARSEMEM failure, I'm not exactly sure why that's
happening.
Looking at the latest upstream kernel, CONFIG_SPARSEMEM is not supported
by the ARM architecture. This is "arch/arm/include/asm/sparsemem.h":
#ifndef ASMARM_SPARSEMEM_H
#define ASMARM_SPARSEMEM_H
#include <asm/memory.h>
/*
* Two definitions are required for sparsemem:
*
* MAX_PHYSMEM_BITS: The number of physical address bits required
* to address the last byte of memory.
*
* SECTION_SIZE_BITS: The number of physical address bits to cover
* the maximum amount of memory in a section.
*
* Eg, if you have 2 banks of up to 64MB at 0x80000000, 0x84000000,
* then MAX_PHYSMEM_BITS is 32, SECTION_SIZE_BITS is 26.
*
* Define these in your mach/memory.h.
*/
#if !defined(SECTION_SIZE_BITS) || !defined(MAX_PHYSMEM_BITS)
#error Sparsemem is not supported on this platform
#endif
#endif
And "arch/arm/include/asm/memory.h" does not define either
SECTION_SIZE_BITS or MAX_PHYSMEM_BITS.
In any case, the "CONFIG_SPARSEMEM kernels not supported..."
error message is printed in sparse_mem_init(). But that function
should return immediately because IS_SPARSEMEM() should be FALSE
because the SPARSEMEM bit should not be set:
#define IS_SPARSEMEM() (vt->flags & SPARSEMEM)
void
sparse_mem_init(void)
{
ulong addr;
ulong mem_section_size;
int dimension;
if (!IS_SPARSEMEM())
return;
... [ cut ] ...
if (!MAX_PHYSMEM_BITS())
error(FATAL,
"CONFIG_SPARSEMEM kernels not supported for this
architecture\n");
In your case, IS_SPARSEMEM() is returning TRUE because
the SPARSEMEM bit in vt->flags is getting set here:
if (kernel_symbol_exists("mem_section"))
vt->flags |= SPARSEMEM;
... [ cut ] ...
sparse_mem_init();
I have 3 sample ARM dumpfiles, versions 2.6.35-rc3, 2.6.36-rc6, and
2.6.38-rc2, and none of them have a "mem_section" variable, so it
does not make it to the "if (!MAX_PHYSMEM_BITS())" check above.
The kernel's "mem_section" variable is declared in mm/sparse.c:
#ifdef CONFIG_SPARSEMEM_EXTREME
struct mem_section *mem_section[NR_SECTION_ROOTS]
____cacheline_internodealigned_in_smp;
#else
struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]
____cacheline_internodealigned_in_smp;
#endif
EXPORT_SYMBOL(mem_section);
But the mm/Makefile only builds sparse.c into the kernel if
CONFIG_SPARSEMEM is turned on:
obj-$(CONFIG_SPARSEMEM) += sparse.o
So I don't understand how your kernel could have (and compile with)
a "mem_section" variable, since it needs MAX_PHYSMEM_BITS?
Dave
4854
days inactive
4855
days old
devel@lists.crash-utility.osci.io
9 comments
4 participants
participants (4)
-
Dave Anderson -
Karlsson, Jan -
Mika Westerberg -
takuo.koguchi.sw＠hitachi.com