Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
by tachibana＠mxm.nes.nec.co.jp
Hi Hatayama-san,
On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
>
> >
> >
> > ----- Original Message -----
> >> Fujitsu has stand-alone dump mechanism based on firmware level
> >> functionality, which we call SADUMP, in short.
> >>
> >> We've maintained utility tools internally but now we're thinking that
> >> the best is crash utility and makedumpfile supports the sadump format
> >> for the viewpoint of both portability and maintainability.
> >>
> >> We'll be of course responsible for its maintainance in a continuous
> >> manner. The sadump dump format is very similar to diskdump format and
> >> so kdump (compressed) format, so we estimate patch set would be a
> >> relatively small size.
> >>
> >> Could you tell me whether crash utility and makedumpfile can support
> >> the sadump format? If OK, we'll start to make patchset.
I think it's not bad to support sadump by makedumpfile. However I have
several questions.
- Do you want to use makedumpfile to make an existing file that sadump has
dumped small?
- It isn't possible to support the same form as kdump-compressed format
now, is it?
- When the information that makedumpfile reads from a note of /proc/vmcore
(or a header of kdump-compressed format) is added by an extension of
makedumpfile, do you need to modify sadump?
Thanks
tachibana
> >
> > Sure, yes, the crash utility can always support another dumpfile format.
> >
>
> Thanks. It helps a lot.
>
> > It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
> > Does your internal version patch diskdump.c, or do you maintain your
> > own "sadump.c"? I ask because if your patchset is at all intrusive,
> > I'd prefer it be kept in its own file, primarily for maintainability,
> > but also because SADUMP is essentially a black-box to anybody outside
> > Fujitsu.
>
> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.
>
> On the other hand, there's a code to be placed at such specific
> area. sadump is triggered depending on kdump's progress and so
> register values to be contained in vmcore varies according to the
> progress: If crash_notes has been initialized when sadump is
> triggered, sadump packs the register values in crash_notes; if not
> yet, packs registers gathered by firmware. This is sadump specific
> processing, so I think putting it in specific sadump.c file is a
> natural and reasonable choise.
>
> Anyway, I have not made any patch set for this. I'll post a patch set
> when I complete.
>
> Again, thanks a lot for the positive answer.
>
> Thanks.
> HATAYAMA, Daisuke
>
>
> _______________________________________________
> kexec mailing list
> kexec(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
1 year
Re: [Crash-utility] non CONFIG_SMP support was: Re[2]: ARM supportfor CONFIG_
by takuo.koguchi.sw＠hitachi.com
Dave,
>With respect to the "runq" command, I tried this patch on my only
>UP ARM sample dumpfile:
I tried a similar modification and got a similar result.
It read
[no tasks queued]
for both RT and CFS
but there are some "RU" tasks shown by ps command, and there are some tasks with "on_rq = 1".
I have not figured out the reason.
Best Regards,
Takuo
>
>
>----- Original Message -----
>> Dave,
>>
>> Toshi's patch works fine for me.
>>
>> Apart from this, runq command does not work against my vmcore(non-SMP).
>>
>> runq fails with the following message.
>> I am afraid it might be another CONFIG_SMP related issue.
>>
>> crash> set debug 10
>> debug: 10
>> crash> runq
>> runq: per_cpu_symbol_search(per_cpu__runqueues): NULL
>> runq: per-cpu runqueues does not exist
>> crash>
>>
>> Takuo
>
>Hi Takuo,
>
>With respect to the "runq" command, I tried this patch on my only
>UP ARM sample dumpfile:
>
>--- task.c.orig 2011-06-27 10:33:51.000000000 -0400
>+++ task.c 2011-06-27 10:47:13.000000000 -0400
>@@ -6970,8 +6970,13 @@
> "prio");
> }
>
>- if (!(rq_sp = per_cpu_symbol_search("per_cpu__runqueues")))
>- error(FATAL, "per-cpu runqueues does not exist\n");
>+ if (!(rq_sp = per_cpu_symbol_search("per_cpu__runqueues"))) {
>+ if (!(kt->flags & SMP) && !(kt->flags & PER_CPU_OFF)) {
>+ if (!(rq_sp = symbol_search("runqueues")))
>+ error(FATAL, "runqueues does not exist\n");
>+ } else
>+ error(FATAL, "per-cpu runqueues does not exist\n");
>+ }
>
> runqbuf = GETBUF(SIZE(runqueue));
> if ((init_sp = per_cpu_symbol_search("per_cpu__init_cfs_rq")))
>
>and it shows:
>
> crash> runq
> CPU 0 RUNQUEUE: c0396c78
> CURRENT: PID: 0 TASK: c0388ee0 COMMAND: "swapper"
> RT PRIO_ARRAY: c0396d28
> [no tasks queued]
> CFS RB_ROOT: c0396d00
> [no tasks queued]
> crash>
>
>but a true test would have something other than an idle state with no
>other tasks queued.
>
>And the "timer" command will definitely require a bit more work.
>
>Dave
>
>--
>Crash-utility mailing list
>Crash-utility(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
13 years, 5 months
Re: [Crash-utility] timer command does not work for my ARM target
by takuo.koguchi.sw＠hitachi.com
Dave,
>----- Original Message -----
>You haven't mentioned your kernel version, but dump_timer_data_tvec_bases_v1()
>is applicable for much older kernels, certainly older than to 2.6.18.
>
>But it appears that, regardless of the kernel version, that the "timer"
>command may not work with more recent kernels that are not configured
>with CONFIG_SMP.
Though I have only vmlinux and vmcore, the crash uitlity told me that my kernel is 2.6.35.7.
Now I understand UP kernel support is not maintained very well.
When I make some progress, I will try to post patches.
Takuo
>
>
>----- Original Message -----
>> Dave,
>> There are a few commands that do not work for my ARM vmlinux/vmcore.
>>
>> One of those is "timer".
>> I get the following messages;
>>
>> crash> timer
>> timer: per_cpu_symbol_search(per_cpu__tvec_bases): NULL
>> GETBUF(128 -> 0)
>> GNU_GET_DATATYPE[tvec_root_s]: returned via gdb_error_hook (1 buffer
>> in use)
>> FREEBUF(0)
>> GETBUF(128 -> 0)
>> GNU_GET_DATATYPE[tvec_s]: returned via gdb_error_hook (1 buffer in
>> use)
>> FREEBUF(0)
>> timer: zero-size memory allocation! (called from 81191e6)
>> crash>
>>
>>
>> Both vec_root_size and vec_size are 0 at
>> dump_timer_data_tvec_bases_v1() in kernel.c
>>
>> vec_root_size = (i = ARRAY_LENGTH(tvec_root_s_vec)) ?
>> i : get_array_length("tvec_root_s.vec", NULL, SIZE(list_head));
>> vec_size = (i = ARRAY_LENGTH(tvec_s_vec)) ?
>> i : get_array_length("tvec_s.vec", NULL, SIZE(list_head));
>> vec = (ulong *)GETBUF(SIZE(list_head) * MAX(vec_root_size, vec_size));
>>
>> Do you have any suggestion?
>
>You haven't mentioned your kernel version, but dump_timer_data_tvec_bases_v1()
>is applicable for much older kernels, certainly older than to 2.6.18.
>
>But it appears that, regardless of the kernel version, that the "timer"
>command may not work with more recent kernels that are not configured
>with CONFIG_SMP.
>
>Dave
>
>
>--
>Crash-utility mailing list
>Crash-utility(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
13 years, 5 months
Unable to switch stack frames while using crash
by Shashidhara Shamaiah
Hi,
I was investigating a 64 bit linux kernel dump . I have following doubts
regarding usage of crash.
1) I wanted to access the intermediate kernel stack frames. To know the
status of the frame and the point of failure.
When I tried to access a stack frame I get an error message "crash:
prohibited gdb command: frame". Can you please let me know if there is
any other way of accessing the kernel stack frames using
crash.
2) When I run bt in crash, I get a stack trace. Another person from a
different team reported a slightly different stack trace to mine. Below
are the stack traces. The register contents are quite different between
the two
My stack trace
PID: 13366 TASK: ffff88031b60d580 CPU: 1 COMMAND: "telnet"
#0 [ffff88031ce759d0] machine_kexec at ffffffff81024486
#1 [ffff88031ce75a40] crash_kexec at ffffffff8107e230
#2 [ffff88031ce75b20] oops_end at ffffffff8100fa38
#3 [ffff88031ce75b50] no_context at ffffffff8102d801
#4 [ffff88031ce75ba0] __bad_area_nosemaphore at ffffffff8102d9c9
#5 [ffff88031ce75c70] bad_area at ffffffff8102da41
#6 [ffff88031ce75ca0] do_page_fault at ffffffff8102dd19
#7 [ffff88031ce75cf0] page_fault at ffffffff812d7425
#8 [ffff88031ce75d78] n_tty_read at ffffffff811f03b3
#9 [ffff88031ce75ec0] tty_read at ffffffff811ebf7e
#10 [ffff88031ce75f10] vfs_read at ffffffff810ebcc8
#11 [ffff88031ce75f40] sys_read at ffffffff810ebe48
#12 [ffff88031ce75f80] system_call_fastpath at ffffffff8100bbc2
RIP: 00007ffff716b9e0 RSP: 00007fffffffdfc0 RFLAGS: 00010212
RAX: 0000000000000000 RBX: ffffffff8100bbc2 RCX: 0000000000000000
RDX: 0000000000001ff6 RSI: 000000000061c02a RDI: 0000000000000000
RBP: 0000000000001ff6 R8: 0000000000000000 R9: 0000000000000000
R10: 0000000000616680 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000001 R14: 000000000061c02a R15: 00000000006178a0
ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b
Reported stack trace
PID: 13366 TASK: ffff88031b60d580 CPU: 1 COMMAND: "telnet"
#0 [ffff88031ce759d0] machine_kexec at ffffffff81024486
#1 [ffff88031ce75a40] crash_kexec at ffffffff8107e230
#2 [ffff88031ce75ad8] n_tty_read at ffffffff811f03b3
#3 [ffff88031ce75b20] oops_end at ffffffff8100fa38
#4 [ffff88031ce75b50] no_context at ffffffff8102d801
#5 [ffff88031ce75ba0] __bad_area_nosemaphore at ffffffff8102d9c9
#6 [ffff88031ce75c20] native_sched_clock at ffffffff810120aa
#7 [ffff88031ce75c70] bad_area at ffffffff8102da41
#8 [ffff88031ce75ca0] do_page_fault at ffffffff8102dd19
#9 [ffff88031ce75cf0] page_fault at ffffffff812d7425
[exception RIP: n_tty_read+1420]
RIP: ffffffff811f03b3 RSP: ffff88031ce75da8 RFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8802cbd54a68 RCX: 000000000061c044
RDX: 0000000000000005 RSI: ffff88031ce75e87 RDI: ffff8802cbd54d1c
RBP: ffff88031ce75eb8 R8: 0000000000000000 R9: 0000000000000000
R10: 0000000000616680 R11: 0000000000000246 R12: 000000000061c044
R13: ffff8802cbd54800 R14: 0000000000000000 R15: 7fffffffffffffff
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10
[ffff88031ce75ec0] tty_read at ffffffff811ebf7e
#11 [ffff88031ce75f10] vfs_read at ffffffff810ebcc8
#12 [ffff88031ce75f40] sys_read at ffffffff810ebe48
#13 [ffff88031ce75f80] system_call_fastpath at ffffffff8100bbc2
3) I want to retrieve the address of a data structure in the current
context. How can it be done? I tried using struct command, but it did
not help
4) When I run the command readelf -a vmcore, I get an error message
"readelf: Error: Not an ELF file - it has the wrong magic bytes at the
start."
Please help regarding the above queries.
Thanks and Regards
Shashidhara
Information transmitted by this e-mail is proprietary to MphasiS, its associated companies and/ or its customers and is intended
for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded
to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly
prohibited. In such cases, please notify us immediately at mailmaster(a)mphasis.com and delete this mail from your records.
13 years, 5 months
non CONFIG_SMP support was: Re[2]: ARM support for CONFIG_SPAR
by takuo.koguchi.sw＠hitachi.com
Dave,
Toshi's patch works fine for me.
Apart from this, runq command does not work against my vmcore(non-SMP).
runq fails with the following message.
I am afraid it might be another CONFIG_SMP related issue.
crash> set debug 10
debug: 10
crash> runq
runq: per_cpu_symbol_search(per_cpu__runqueues): NULL
runq: per-cpu runqueues does not exist
crash>
Takuo
>
>
>----- Original Message -----
>> >>>> But it only happens when I use KDUMP format instead of
>> >>>> NETDUMP_ELF32.
>> > I cannot reconfirm this. Please forget about it.
>> > I forgot to mention one thing. I had to remove the following line
>> > from symbol.c as my target is non-SMP
>> > 1413: lm->mod_percpu = ULONG(modbuf + OFFSET(module_percpu));
>> > I hope you will find a better way.
>> >
>> > Best Regards,
>> >
>> > Takuo
>>
>> I'm sorry about making trouble.
>> Attachment is my proposal fix.
>>
>> Thanks,
>> Toshi.
>
>Sorry -- I responded to your first message before seeing your
>similar patch. I will queue that for the next release.
>
>And checking the upstream module.h, I see now that they have
>encapulated module.percpu within CONFIG_SMP. Sorry for the
>confusion.
>
>Thanks,
> Dave
>
>--
>Crash-utility mailing list
>Crash-utility(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
13 years, 5 months
timer command does not work for my ARM target
by takuo.koguchi.sw＠hitachi.com
Dave,
There are a few commands that do not work for my ARM vmlinux/vmcore.
One of those is "timer".
I get the following messages;
crash> timer
timer: per_cpu_symbol_search(per_cpu__tvec_bases): NULL
GETBUF(128 -> 0)
GNU_GET_DATATYPE[tvec_root_s]: returned via gdb_error_hook (1 buffer in use)
FREEBUF(0)
GETBUF(128 -> 0)
GNU_GET_DATATYPE[tvec_s]: returned via gdb_error_hook (1 buffer in use)
FREEBUF(0)
timer: zero-size memory allocation! (called from 81191e6)
crash>
Both vec_root_size and vec_size are 0 at dump_timer_data_tvec_bases_v1() in kernel.c
vec_root_size = (i = ARRAY_LENGTH(tvec_root_s_vec)) ?
i : get_array_length("tvec_root_s.vec", NULL, SIZE(list_head));
vec_size = (i = ARRAY_LENGTH(tvec_s_vec)) ?
i : get_array_length("tvec_s.vec", NULL, SIZE(list_head));
vec = (ulong *)GETBUF(SIZE(list_head) * MAX(vec_root_size, vec_size));
Do you have any suggestion?
Best Regards,
Takuo
13 years, 5 months
Re: [Crash-utility] ARM support for CONFIG_SPARSEMEM:(wasRe:DDimage)
by takuo.koguchi.sw＠hitachi.com
>>>But it only happens when I use KDUMP format instead of NETDUMP_ELF32.
I cannot reconfirm this. Please forget about it.
I forgot to mention one thing. I had to remove the following line from symbol.c as my target is non-SMP
1413: lm->mod_percpu = ULONG(modbuf + OFFSET(module_percpu));
I hope you will find a better way.
Best Regards,
Takuo
>Thank you forc crash-5.1.6.
>
>>But I'm thinking that if the VTOP/PTOV issue is resolved, then you won't
>>see that readmem() error in FILL_PTBL(), because the address that was
>>failing was generated by PTOV():
>>
>> /*
>> * pte_offset_map(pmd, vaddr)
>> */
>> page_table = (ulong *)PTOV(pmd_page_addr(pmd_pte)) + PTE_OFFSET(vaddr);
>>
>> FILL_PTBL(PAGEBASE(page_table), KVADDR, PAGESIZE());
>
>
>With the modification of VTOP/PTOV, crash-5.1.6 recognizes "page table" of CONFIG_SPARSEMEM vmcore file and init_module_unwind_tables succeeds and backtrace command without -t option works now. But it only happens when I use KDUMP format instead of NETDUMP_ELF32. (please remember I created vmcore file from raw memory images).
>Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> NOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0
> LOAD 0x000094 0xc0000000 0x00200000 0xfe00000 0xfe00000 RWE 0
> LOAD 0xfe00094 0xd0000000 0x40000000 0x10000000 0x10000000 RWE 0
>I did not noticed that read_netdump() does not support multiple PT_LOADs for NETDUMP_ELF32 dump file format until yesterday.
>
>It seems to me that VTOP/PTOV calculation fomula can be obtained from vmcore file. Am I wrong?
>
>Best Regards,
>
>Takuo
>
>>
>>
>>----- Original Message -----
>>> Dave, Mika,
>>> memory.h I am using is probably the same as this,
>>> https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=arch...
>>>
>>> 19 /* physical offset of RAM */
>>> 20 #define PHYS_OFFSET UL(CONFIG_PHYS_OFFSET) <-- 0x00200000
>>> 21
>>> 22 #define MAX_PHYSMEM_BITS 32
>>> 23 #define SECTION_SIZE_BITS 28
>>> 24
>>> 25 /* Certain configurations of MSM7x30 have multiple memory banks.
>>> 26 * One or more of these banks can contain holes in the memory map as well.
>>> 27 * These macros define appropriate conversion routines between the physical
>>> 28 * and virtual address domains for supporting these configurations using
>>> 29 * SPARSEMEM and a 3G/1G VM split.
>>> 30 */
>>> 31
>>> 32 #if defined(CONFIG_ARCH_MSM7X30)
>>> 33
>>> 34 #define EBI0_PHYS_OFFSET PHYS_OFFSET
>>> 35 #define EBI0_PAGE_OFFSET PAGE_OFFSET
>>> 36 #define EBI0_SIZE 0x10000000
>>> 37
>>> 38 #define EBI1_PHYS_OFFSET 0x40000000
>>> 39 #define EBI1_PAGE_OFFSET (EBI0_PAGE_OFFSET + EBI0_SIZE)
>>> 40
>>> 41 #if (defined(CONFIG_SPARSEMEM) && defined(CONFIG_VMSPLIT_3G))
>>> 42
>>> 43 #define __phys_to_virt(phys) \
>>> 44 ((phys) >= EBI1_PHYS_OFFSET ? \
>>> 45 (phys) - EBI1_PHYS_OFFSET + EBI1_PAGE_OFFSET : \
>>> 46 (phys) - EBI0_PHYS_OFFSET + EBI0_PAGE_OFFSET)
>>> 47
>>> 48 #define __virt_to_phys(virt) \
>>> 49 ((virt) >= EBI1_PAGE_OFFSET ? \
>>> 50 (virt) - EBI1_PAGE_OFFSET + EBI1_PHYS_OFFSET : \
>>> 51 (virt) - EBI0_PAGE_OFFSET + EBI0_PHYS_OFFSET)
>>> 52
>>> 53 #endif
>>> 54
>>> 55 #endif
>>>
>>>
>>> So my previous description of actual memory mapping was not correct.
>>> The correct description is,
>>> Virtual 0xc0000000-0xcfdfffff -> Physical 0x00200000-0x0fffffff
>>> and
>>> Virtual 0xd0000000-0xdfffffff -> Physical 0x40000000-0x4fffffff
>>> Tomorrow I will check if vmcore with the following header is
>>> recognized by crash.
>>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>>> NOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0
>>> LOAD 0x000094 0xc0000000 0x00200000 0x0fe00000 0x0fe00000 RWE
>>> LOAD 0x0fe00094 0xc0000000 0x40000000 0x10000000 0x10000000 RWE
>>
>>Shouldn't the second PT_LOAD segment have a p_vaddr of 0xc0000000?
>>
>>Although, in the case of ARM, I believe that the p_vaddr field
>>is not used by the crash utility, as it is only interested in the
>>p_paddr and p_memsz/p_filesz fields. But I presume you meant
>>0xd0000000 for the second one.
>>
>>>
>>> And I guess VTOP/PTOV needs modification in accordance with
>>> __phys_to_virt and __virt_to_phys.
>>
>>Right...
>>
>>Ultimately it will be advisable to extract the ARM VTOP() and PTOV()
>>macros into machine-dependent functions, i.e., similar to the X86_64
>>and IA64 architectures. And in those functions, intelligence will
>>have to be applied to determine how to handle the various ARM types.
>>
>>>
>>> For your information,
>>> The vmcore file with the following header is recognized by crash and
>>> many commands works fine,
>>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>>> NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
>>> LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE
>>> if the patches for unwind_arm.c, arm.c and defs.h posted in this ML
>>> thread applied and readmem error_handle for FILL_PTBL is change to
>>> RETURN_ON_ERROR.
>>> Without the last modification above crash exits when readmem fails at
>>> FILL_PTBL before reaching the first prompt.
>>
>>But I'm thinking that if the VTOP/PTOV issue is resolved, then you won't
>>see that readmem() error in FILL_PTBL(), because the address that was
>>failing was generated by PTOV():
>>
>> /*
>> * pte_offset_map(pmd, vaddr)
>> */
>> page_table = (ulong *)PTOV(pmd_page_addr(pmd_pte)) + PTE_OFFSET(vaddr);
>>
>> FILL_PTBL(PAGEBASE(page_table), KVADDR, PAGESIZE());
>>
>>Dave
>>
>>
>>--
>>Crash-utility mailing list
>>Crash-utility(a)redhat.com
>>https://www.redhat.com/mailman/listinfo/crash-utility
>>
>
13 years, 5 months
Re: [Crash-utility] ARM support for CONFIG_SPARSEMEM:(wasRe:DDimage)
by takuo.koguchi.sw＠hitachi.com
Thank you forc crash-5.1.6.
>But I'm thinking that if the VTOP/PTOV issue is resolved, then you won't
>see that readmem() error in FILL_PTBL(), because the address that was
>failing was generated by PTOV():
>
> /*
> * pte_offset_map(pmd, vaddr)
> */
> page_table = (ulong *)PTOV(pmd_page_addr(pmd_pte)) + PTE_OFFSET(vaddr);
>
> FILL_PTBL(PAGEBASE(page_table), KVADDR, PAGESIZE());
With the modification of VTOP/PTOV, crash-5.1.6 recognizes "page table" of CONFIG_SPARSEMEM vmcore file and init_module_unwind_tables succeeds and backtrace command without -t option works now. But it only happens when I use KDUMP format instead of NETDUMP_ELF32. (please remember I created vmcore file from raw memory images).
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0
LOAD 0x000094 0xc0000000 0x00200000 0xfe00000 0xfe00000 RWE 0
LOAD 0xfe00094 0xd0000000 0x40000000 0x10000000 0x10000000 RWE 0
I did not noticed that read_netdump() does not support multiple PT_LOADs for NETDUMP_ELF32 dump file format until yesterday.
It seems to me that VTOP/PTOV calculation fomula can be obtained from vmcore file. Am I wrong?
Best Regards,
Takuo
>
>
>----- Original Message -----
>> Dave, Mika,
>> memory.h I am using is probably the same as this,
>> https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=arch...
>>
>> 19 /* physical offset of RAM */
>> 20 #define PHYS_OFFSET UL(CONFIG_PHYS_OFFSET) <-- 0x00200000
>> 21
>> 22 #define MAX_PHYSMEM_BITS 32
>> 23 #define SECTION_SIZE_BITS 28
>> 24
>> 25 /* Certain configurations of MSM7x30 have multiple memory banks.
>> 26 * One or more of these banks can contain holes in the memory map as well.
>> 27 * These macros define appropriate conversion routines between the physical
>> 28 * and virtual address domains for supporting these configurations using
>> 29 * SPARSEMEM and a 3G/1G VM split.
>> 30 */
>> 31
>> 32 #if defined(CONFIG_ARCH_MSM7X30)
>> 33
>> 34 #define EBI0_PHYS_OFFSET PHYS_OFFSET
>> 35 #define EBI0_PAGE_OFFSET PAGE_OFFSET
>> 36 #define EBI0_SIZE 0x10000000
>> 37
>> 38 #define EBI1_PHYS_OFFSET 0x40000000
>> 39 #define EBI1_PAGE_OFFSET (EBI0_PAGE_OFFSET + EBI0_SIZE)
>> 40
>> 41 #if (defined(CONFIG_SPARSEMEM) && defined(CONFIG_VMSPLIT_3G))
>> 42
>> 43 #define __phys_to_virt(phys) \
>> 44 ((phys) >= EBI1_PHYS_OFFSET ? \
>> 45 (phys) - EBI1_PHYS_OFFSET + EBI1_PAGE_OFFSET : \
>> 46 (phys) - EBI0_PHYS_OFFSET + EBI0_PAGE_OFFSET)
>> 47
>> 48 #define __virt_to_phys(virt) \
>> 49 ((virt) >= EBI1_PAGE_OFFSET ? \
>> 50 (virt) - EBI1_PAGE_OFFSET + EBI1_PHYS_OFFSET : \
>> 51 (virt) - EBI0_PAGE_OFFSET + EBI0_PHYS_OFFSET)
>> 52
>> 53 #endif
>> 54
>> 55 #endif
>>
>>
>> So my previous description of actual memory mapping was not correct.
>> The correct description is,
>> Virtual 0xc0000000-0xcfdfffff -> Physical 0x00200000-0x0fffffff
>> and
>> Virtual 0xd0000000-0xdfffffff -> Physical 0x40000000-0x4fffffff
>> Tomorrow I will check if vmcore with the following header is
>> recognized by crash.
>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>> NOTE 0x000094 0x00000000 0x00000000 0x00000 0x00000 0
>> LOAD 0x000094 0xc0000000 0x00200000 0x0fe00000 0x0fe00000 RWE
>> LOAD 0x0fe00094 0xc0000000 0x40000000 0x10000000 0x10000000 RWE
>
>Shouldn't the second PT_LOAD segment have a p_vaddr of 0xc0000000?
>
>Although, in the case of ARM, I believe that the p_vaddr field
>is not used by the crash utility, as it is only interested in the
>p_paddr and p_memsz/p_filesz fields. But I presume you meant
>0xd0000000 for the second one.
>
>>
>> And I guess VTOP/PTOV needs modification in accordance with
>> __phys_to_virt and __virt_to_phys.
>
>Right...
>
>Ultimately it will be advisable to extract the ARM VTOP() and PTOV()
>macros into machine-dependent functions, i.e., similar to the X86_64
>and IA64 architectures. And in those functions, intelligence will
>have to be applied to determine how to handle the various ARM types.
>
>>
>> For your information,
>> The vmcore file with the following header is recognized by crash and
>> many commands works fine,
>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
>> NOTE 0x000074 0x00000000 0x00000000 0x00000 0x00000 0
>> LOAD 0x000074 0xc0000000 0x00000000 0x20000000 0x20000000 RWE
>> if the patches for unwind_arm.c, arm.c and defs.h posted in this ML
>> thread applied and readmem error_handle for FILL_PTBL is change to
>> RETURN_ON_ERROR.
>> Without the last modification above crash exits when readmem fails at
>> FILL_PTBL before reaching the first prompt.
>
>But I'm thinking that if the VTOP/PTOV issue is resolved, then you won't
>see that readmem() error in FILL_PTBL(), because the address that was
>failing was generated by PTOV():
>
> /*
> * pte_offset_map(pmd, vaddr)
> */
> page_table = (ulong *)PTOV(pmd_page_addr(pmd_pte)) + PTE_OFFSET(vaddr);
>
> FILL_PTBL(PAGEBASE(page_table), KVADDR, PAGESIZE());
>
>Dave
>
>
>--
>Crash-utility mailing list
>Crash-utility(a)redhat.com
>https://www.redhat.com/mailman/listinfo/crash-utility
>
13 years, 5 months
[ANNOUNCE] crash version 5.1.6 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
Changelog:
- Fixed several typos in the updated crash.8 man page.
(bob.montgomery(a)hp.com)
- Created a new "rd -a" option that displays printable ASCII data only,
starting from the specified location. If a "count" argument is not
entered, the display stops upon encountering the first non-printable
character.
(anderson(a)redhat.com)
- Fix for the "search -k" option on X86 kernels whose first memmap page
structure does not map to physical address 0. Without the patch, the
identity-mapped region of the first memory node would not be searched.
(anderson(a)redhat.com)
- Fix for the "search -k" option in the highly unlikely case of kernels
that have multiple NUMA nodes that are not sequential with respect to
their node IDs and the physical memory they reference, have physical
memory holes between any of the nodes, and do not have memmap page
structures referencing the non-existent inter-node physical memory.
In that event, it is conceivable that a NUMA node would be skipped.
(anderson(a)redhat.com)
- If the "kmem <address>" argument is a virtual address inside a
kernel module, the first item displayed is the address, followed by
its symbol type, and its symbol-name-plus-offset string. This patch
appends the module name in brackets, similar to what is displayed if
"sym <address>" is entered.
(anderson(a)redhat.com)
- Fix for "kmem -s <address>" in kernels configured with CONFIG_SLUB
and CONFIG_PAGEFLAGS_EXTENDED if the address is contained in a page
other than the first page in a compound, multi-page, slab. Without
the patch, the command would fail with the message "kmem: address is
not allocated in slab subsystem: <address>".
(anderson(a)redhat.com)
- Created a new "rd -N" option that displays 16- and 32-bit data in
network byte order, performing byte-swapping if appropriate.
(makc(a)gmx.co.uk)
- Fix for a compiler warning when building with "make warn". Without
the patch, memory.c generates a message indicating "kernel.c: In
function ‘back_trace’:" followed by 17 messages indicating "kernel.c:
2187: warning: ‘btsave.<member>’ may be used uninitialized in this
function", where there is one message for each <member> of the
bt_info structure.
(anderson(a)redhat.com)
- Updated the #define of NR_SECTION_ROOTS to match its change upstream
that prevents its value from being calculated to be zero.
(takuo.koguchi.sw(a)hitachi.com, anderson(a)redhat.com)
- Fix for a double-free() in the unlikely event of a readmem() failure
in the ARM architecture's read_module_unwind_table() function.
(mika.westerberg(a)iki.fi)
- Updates to support CONFIG_SPARSEMEM for the ARM architecture.
(mika.westerberg(a)iki.fi)
- Extended the "mach" command to display the size and address of each
per-cpu IRQ stack and per-cpu exception stack, if they exist. This
extension is applicable to the x86_64 and ppc64 architectures, and
the x86 architecture if applicable. Prior to this patch, the values
were only accessible via "help -t" or "help -m".
(anderson(a)redhat.com)
- Created a new "kmem -o" option that dumps each cpu's offset value
that is added to per-cpu symbol values to translate them into kernel
virtual addresses. Prior to this patch, the values were only
accessible via "help -k".
(anderson(a)redhat.com)
- Removed the "kmem [-[l|L][a|i]]" options from being advertised by
the "kmem" help page; the options have been obsolete since the Linux
version 2.2 timeframe.
(anderson(a)redhat.com)
- Fix to support Linux 3.x version number change. Without the patch,
the crash session fails with kernel version 3.0 and later, displaying
the message "WARNING: kernel version inconsistency between vmlinux
and [live memory or dumpfile]", followed by the fatal error message
"crash: incompatible arguments: vmlinux is not SMP -- [live system or
dumpfile] is SMP".
(sebott(a)linux.vnet.ibm.com, anderson(a)redhat.com)
- Updates to the sial.c extension module to support the Linux 3.x
version number change.
(sebott(a)linux.vnet.ibm.com, Luc.Chouinard(a)trueposition.com)
- Created a new "kmem -g [flags]" option that displays the enumerator
value of bits in the page structure's "flags" field. With no "flags"
argument, the enumerator value of all bits are displayed; when a
hexadecimal "flags" option is added, just the bits in the value are
translated. This option only works with 2.6.26 and later kernels,
which contain the "enum pageflags".
(anderson(a)redhat.com)
13 years, 5 months