Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support
On Tue, Aug 23, 2016 at 01:34:21PM +0530, Pratyush Anand wrote:
> On 23/08/2016:02:29:03 PM, AKASHI Takahiro wrote:
> > Pratyush,
> >
> > On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> > > Hi Geoff and Takahiro,
> > >
> > > I am having some issues with kexec+kdump while working with Seattle
> > > platform. On
> > > top level, kernel crashes in copy_oldmem_page(), because it gets wrong
> > > offset
> > > for log_buf during vmcore-dmesg save.
> > >
> > > Here is the detail:
> > >
> > > (1) From /proc/iomem, these are the "System RAM" Components:
> > >
> > > 80-8001e7 : System RAM
> > > 8001e8-83ff17 : System RAM
> > > 800208-8002b3 : Kernel code
> > > 8002c4-800348 : Kernel data
> > > 807fe0-80ffdf : Crash kernel
> > > 83ff18-83ff1c : System RAM
> > > 83ff1d-83ff21 : System RAM
> > > 83ff22-83ffe4 : System RAM
> > > 83ffe5-83 : System RAM
> > >
> > > (2) From kexec-tools debug print I see following:
> > > elf_arm64_load: e_entry: fc000808 -> 0088
> > > elf_arm64_load: p_vaddr: fc000808 -> 0088
> > > elf_arm64_load: header_offset:
> > > elf_arm64_load: text_offset: 0008
> > > elf_arm64_load: image_size:0141
> > > elf_arm64_load: phys_offset: 0080
> > > elf_arm64_load: page_offset: fc000800
> > >
> > > I understand that "Kernel Code start physical address" 0x800208
> > > should map
> > > to e_entry vaddr which is 0xfc000808. However, kexec-tools debug
> > > print
> > > shows that e_entry vaddr maps to PA 88 which seems wrong.
> >
> > Who specifies the kernel load address, 0x800208 and why?
>
> May be I could not get the question. This load address is coming from the 1st
> kernel.
My question is why we need to use this value, 0x800208,
as the kernel load address.
I guess that, on Seattle platform, 0x80-0x8001e8 is
used for a specific purpose and the kernel must be loaded above
0x8001e8.
Since PHYS_OFFSET must be 2MB aligned, the lowest kernel load address
should be:
0x800200 + 0x8(default TEXT_OFFSET).
> >
> > Since image_arm64_load() also use
> > get_phys_offset() + arm64_mem.text_offset (== 0x88)
> > as the load address unconditionally, doesn't kexec fail on Seattle?
>
> Yes, had n't tried kexec with binary image. It fails.
> I think image_base should be virt_to_phys(get_kernel_sym("_text")) for
> !KEXEC_ON_CRASH.
So all what we expect from kexec-tools as a sort of boot loader,
we should be able to specify the command line like:
$ kexec --load vmlinux (or Image) --mem-min=0x8001e8 ...
(We could use get_kernel_sym("_text"), but don't have to.)
I'm going to modify our arm64 port in this way.
Thanks,
-Takahiro AKASHI
> ~Pratyush
>
> >
> > -Takahiro AKASHI
> >
> > > (3) further page_offset (or vp_offset in your new code) is calculated
> > > as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
> > >
> > > Current calcualtion of page_offset leads to wrong configuration of VA of
> > > alls
> > > PT_LOAD (see below). Ultimately, this is also leading to kernel crash
> > > during
> > > vmcore-dmesg and vmcore save operations, because we pass an offset to
> > > pread()
> > > system call which maps to wrong physical address.
> > >
> > > Elf header: p_type = 1, p_offset = 0x80 p_paddr = 0x80
> > > p_vaddr = 0xfc000800 p_filesz = 0x1e8 p_memsz = 0x1e8
> > > [0xfc000800 should be mapping to 0x800200 and not
> > > 0x80]
> > > Elf header: p_type = 1, p_offset = 0x8001e8 p_paddr = 0x8001e8
> > > p_vaddr = 0xfc0009e8 p_filesz = 0x7df8 p_memsz = 0x7df8
> > > Elf header: p_type = 1, p_offset = 0x80ffe0 p_paddr = 0x80ffe0
> > > p_vaddr = 0xfc0107e0 p_filesz = 0x2ff38 p_memsz = 0x2ff38
> > > Elf header: p_type = 1, p_offset = 0x83ff18 p_paddr = 0x83ff18
> > > p_vaddr = 0xfc040718 p_filesz = 0x5 p_memsz = 0x5
> > > Elf header: p_type = 1, p_offset = 0x83ff1d p_paddr = 0x83ff1d
> > > p_vaddr = 0xfc04071d p_filesz = 0x5 p_memsz = 0x5
> > > Elf header: p_type = 1, p_offset = 0x83ff22 p_paddr = 0x83ff22
> > > p_vaddr = 0xfc040722 p_filesz = 0xc3 p_memsz = 0xc3
> > > Elf header: p_type = 1, p_offset = 0x83ffe5 p_paddr = 0x83ffe5
> > > p_vaddr = 0xfc0407e5 p_filesz = 0x1b p_memsz = 0x1b
> > >
> > > May be following should be better.
> > > arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" +
> > > phys_offset.
> > >
> > > (4) Further more, vmcore must have first PT_LOAD segment as kernel text
> > > area.
> > > In this platform we have first "System RAM" area as 80-8001e7
> > > which
> > > is not matching to "Kernel code" area. Therefore, we should provide
> > >
Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support
On 22/08/2016:05:10:17 PM, AKASHI Takahiro wrote: > On Fri, Aug 19, 2016 at 03:44:23PM +0530, Pratyush Anand wrote: > > page_offset is the virtual address of phys_offset, right? > > > > ehdr.e_entry is the virtual address of "kernel Code Start PA", right? > > > > If yes, then why should n't above be correct for all linear regions. > > What I was thinking of is that we'd better fake arm64_mem.text_offset > instead of calculating a page_offset because text_offset is also used > in arm64_load_other_segments(). Here, if the first segment doesn't not > contain kernel text, image_base will be incorrect. IMHO, we should keep all definitions in kexec-tools as close as possible to that of corresponding definitions in kernel. This will help us to avoid any confusion in future. ~Pratyush ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support
On 23/08/2016:02:29:03 PM, AKASHI Takahiro wrote:
> Pratyush,
>
> On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> > Hi Geoff and Takahiro,
> >
> > I am having some issues with kexec+kdump while working with Seattle
> > platform. On
> > top level, kernel crashes in copy_oldmem_page(), because it gets wrong
> > offset
> > for log_buf during vmcore-dmesg save.
> >
> > Here is the detail:
> >
> > (1) From /proc/iomem, these are the "System RAM" Components:
> >
> > 80-8001e7 : System RAM
> > 8001e8-83ff17 : System RAM
> > 800208-8002b3 : Kernel code
> > 8002c4-800348 : Kernel data
> > 807fe0-80ffdf : Crash kernel
> > 83ff18-83ff1c : System RAM
> > 83ff1d-83ff21 : System RAM
> > 83ff22-83ffe4 : System RAM
> > 83ffe5-83 : System RAM
> >
> > (2) From kexec-tools debug print I see following:
> > elf_arm64_load: e_entry: fc000808 -> 0088
> > elf_arm64_load: p_vaddr: fc000808 -> 0088
> > elf_arm64_load: header_offset:
> > elf_arm64_load: text_offset: 0008
> > elf_arm64_load: image_size:0141
> > elf_arm64_load: phys_offset: 0080
> > elf_arm64_load: page_offset: fc000800
> >
> > I understand that "Kernel Code start physical address" 0x800208 should
> > map
> > to e_entry vaddr which is 0xfc000808. However, kexec-tools debug
> > print
> > shows that e_entry vaddr maps to PA 88 which seems wrong.
>
> Who specifies the kernel load address, 0x800208 and why?
May be I could not get the question. This load address is coming from the 1st
kernel.
>
> Since image_arm64_load() also use
> get_phys_offset() + arm64_mem.text_offset (== 0x88)
> as the load address unconditionally, doesn't kexec fail on Seattle?
Yes, had n't tried kexec with binary image. It fails.
I think image_base should be virt_to_phys(get_kernel_sym("_text")) for
!KEXEC_ON_CRASH.
~Pratyush
>
> -Takahiro AKASHI
>
> > (3) further page_offset (or vp_offset in your new code) is calculated
> > as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
> >
> > Current calcualtion of page_offset leads to wrong configuration of VA of
> > alls
> > PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
> > vmcore-dmesg and vmcore save operations, because we pass an offset to
> > pread()
> > system call which maps to wrong physical address.
> >
> > Elf header: p_type = 1, p_offset = 0x80 p_paddr = 0x80
> > p_vaddr = 0xfc000800 p_filesz = 0x1e8 p_memsz = 0x1e8
> > [0xfc000800 should be mapping to 0x800200 and not 0x80]
> > Elf header: p_type = 1, p_offset = 0x8001e8 p_paddr = 0x8001e8
> > p_vaddr = 0xfc0009e8 p_filesz = 0x7df8 p_memsz = 0x7df8
> > Elf header: p_type = 1, p_offset = 0x80ffe0 p_paddr = 0x80ffe0
> > p_vaddr = 0xfc0107e0 p_filesz = 0x2ff38 p_memsz = 0x2ff38
> > Elf header: p_type = 1, p_offset = 0x83ff18 p_paddr = 0x83ff18
> > p_vaddr = 0xfc040718 p_filesz = 0x5 p_memsz = 0x5
> > Elf header: p_type = 1, p_offset = 0x83ff1d p_paddr = 0x83ff1d
> > p_vaddr = 0xfc04071d p_filesz = 0x5 p_memsz = 0x5
> > Elf header: p_type = 1, p_offset = 0x83ff22 p_paddr = 0x83ff22
> > p_vaddr = 0xfc040722 p_filesz = 0xc3 p_memsz = 0xc3
> > Elf header: p_type = 1, p_offset = 0x83ffe5 p_paddr = 0x83ffe5
> > p_vaddr = 0xfc0407e5 p_filesz = 0x1b p_memsz = 0x1b
> >
> > May be following should be better.
> > arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.
> >
> > (4) Further more, vmcore must have first PT_LOAD segment as kernel text
> > area.
> > In this platform we have first "System RAM" area as 80-8001e7
> > which
> > is not matching to "Kernel code" area. Therefore, we should provide support
> > of
> > "kern_size" so that first PT_LOAD is kernel text area.
> >
> > ~Pratyush
> > On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> > > My kernel patches of kdump suport on arm64 are currently under reviews
> > > [1].
> > >
> > > This patchset is synced with them (v24) and provides necessary changes for
> > > kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > > v3[2] along with a bugfix[3].
> > >
> > > [1]
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> > > [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> > > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> > >
> > > Changes for v2:
> > > - Trim a temoprary buffer in setup_2nd_dtb()
> > > - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> > > - Update patch#7 from Pratyush
> > >(re-worked by akashi)
> > >
> > > AKASHI Takahiro (5):
>
Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support
Pratyush,
On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> Hi Geoff and Takahiro,
>
> I am having some issues with kexec+kdump while working with Seattle platform.
> On
> top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
> for log_buf during vmcore-dmesg save.
>
> Here is the detail:
>
> (1) From /proc/iomem, these are the "System RAM" Components:
>
> 80-8001e7 : System RAM
> 8001e8-83ff17 : System RAM
> 800208-8002b3 : Kernel code
> 8002c4-800348 : Kernel data
> 807fe0-80ffdf : Crash kernel
> 83ff18-83ff1c : System RAM
> 83ff1d-83ff21 : System RAM
> 83ff22-83ffe4 : System RAM
> 83ffe5-83 : System RAM
>
> (2) From kexec-tools debug print I see following:
> elf_arm64_load: e_entry: fc000808 -> 0088
> elf_arm64_load: p_vaddr: fc000808 -> 0088
> elf_arm64_load: header_offset:
> elf_arm64_load: text_offset: 0008
> elf_arm64_load: image_size:0141
> elf_arm64_load: phys_offset: 0080
> elf_arm64_load: page_offset: fc000800
>
> I understand that "Kernel Code start physical address" 0x800208 should map
> to e_entry vaddr which is 0xfc000808. However, kexec-tools debug print
> shows that e_entry vaddr maps to PA 88 which seems wrong.
Who specifies the kernel load address, 0x800208 and why?
Since image_arm64_load() also use
get_phys_offset() + arm64_mem.text_offset (== 0x88)
as the load address unconditionally, doesn't kexec fail on Seattle?
-Takahiro AKASHI
> (3) further page_offset (or vp_offset in your new code) is calculated
> as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
>
> Current calcualtion of page_offset leads to wrong configuration of VA of alls
> PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
> vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
> system call which maps to wrong physical address.
>
> Elf header: p_type = 1, p_offset = 0x80 p_paddr = 0x80
> p_vaddr = 0xfc000800 p_filesz = 0x1e8 p_memsz = 0x1e8
> [0xfc000800 should be mapping to 0x800200 and not 0x80]
> Elf header: p_type = 1, p_offset = 0x8001e8 p_paddr = 0x8001e8
> p_vaddr = 0xfc0009e8 p_filesz = 0x7df8 p_memsz = 0x7df8
> Elf header: p_type = 1, p_offset = 0x80ffe0 p_paddr = 0x80ffe0
> p_vaddr = 0xfc0107e0 p_filesz = 0x2ff38 p_memsz = 0x2ff38
> Elf header: p_type = 1, p_offset = 0x83ff18 p_paddr = 0x83ff18
> p_vaddr = 0xfc040718 p_filesz = 0x5 p_memsz = 0x5
> Elf header: p_type = 1, p_offset = 0x83ff1d p_paddr = 0x83ff1d
> p_vaddr = 0xfc04071d p_filesz = 0x5 p_memsz = 0x5
> Elf header: p_type = 1, p_offset = 0x83ff22 p_paddr = 0x83ff22
> p_vaddr = 0xfc040722 p_filesz = 0xc3 p_memsz = 0xc3
> Elf header: p_type = 1, p_offset = 0x83ffe5 p_paddr = 0x83ffe5
> p_vaddr = 0xfc0407e5 p_filesz = 0x1b p_memsz = 0x1b
>
> May be following should be better.
> arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.
>
> (4) Further more, vmcore must have first PT_LOAD segment as kernel text area.
> In this platform we have first "System RAM" area as 80-8001e7
> which
> is not matching to "Kernel code" area. Therefore, we should provide support of
> "kern_size" so that first PT_LOAD is kernel text area.
>
> ~Pratyush
> On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> > My kernel patches of kdump suport on arm64 are currently under reviews [1].
> >
> > This patchset is synced with them (v24) and provides necessary changes for
> > kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > v3[2] along with a bugfix[3].
> >
> > [1]
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> > [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> >
> > Changes for v2:
> > - Trim a temoprary buffer in setup_2nd_dtb()
> > - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> > - Update patch#7 from Pratyush
> >(re-worked by akashi)
> >
> > AKASHI Takahiro (5):
> > arm64: kdump: identify memory regions
> > arm64: kdump: add elf core header segment
> > arm64: kdump: set up kernel image segment
> > arm64: kdump: set up other segments
> > arm64: kdump: add DT properties to crash dump kernel's dtb
> >
> > Pratyush Anand (2):
> > kexec: generalize and rename get_kernel_stext_sym()
> > arm64: kdump: Add support for binary image files
> >
> > kexec/arch/arm/crashdump-arm.c | 40 +--
> > kexec/arch/arm64/Makefile | 2 +
> > kexec/arch/arm64/cras
Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support
On Fri, Aug 19, 2016 at 03:44:23PM +0530, Pratyush Anand wrote: > On 19/08/2016:04:19:31 PM, AKASHI Takahiro wrote: > > Pratyush, Geoff > > > > # If I had Seattle, I could debug easily :) > > > > On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote: > > > Hi Geoff and Takahiro, > > > > > > I am having some issues with kexec+kdump while working with Seattle > > > platform. On > > > top level, kernel crashes in copy_oldmem_page(), because it gets wrong > > > offset > > > for log_buf during vmcore-dmesg save. > > > > > > Here is the detail: > > > > > > (1) From /proc/iomem, these are the "System RAM" Components: > > > > > > 80-8001e7 : System RAM > > > 8001e8-83ff17 : System RAM > > > 800208-8002b3 : Kernel code > > > 8002c4-800348 : Kernel data > > > 807fe0-80ffdf : Crash kernel > > > 83ff18-83ff1c : System RAM > > > 83ff1d-83ff21 : System RAM > > > 83ff22-83ffe4 : System RAM > > > 83ffe5-83 : System RAM > > > > > > (2) From kexec-tools debug print I see following: > > > elf_arm64_load: e_entry: fc000808 -> 0088 > > > elf_arm64_load: p_vaddr: fc000808 -> 0088 > > > elf_arm64_load: header_offset: > > > elf_arm64_load: text_offset: 0008 > > > elf_arm64_load: image_size:0141 > > > elf_arm64_load: phys_offset: 0080 > > > elf_arm64_load: page_offset: fc000800 > > > > > > I understand that "Kernel Code start physical address" 0x800208 > > > should map > > > to e_entry vaddr which is 0xfc000808. However, kexec-tools debug > > > print > > > shows that e_entry vaddr maps to PA 88 which seems wrong. > > > > Obviously, virt_to_phys() is wrong. > > As you know, we have to calculate virt_to_phys() in a different way > > depending on whether the vaddr is greater than PAGE_OFFSET (linear mapping) > > or not (kernel image mapping). > > See the kernel's include/asm/memory.h. > > > > Geoff, please update this function. > > > > > (3) further page_offset (or vp_offset in your new code) is calculated > > > as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset; > > > > > > Current calcualtion of page_offset leads to wrong configuration of VA of > > > alls > > > PT_LOAD (see below). Ultimately, this is also leading to kernel crash > > > during > > > vmcore-dmesg and vmcore save operations, because we pass an offset to > > > pread() > > > system call which maps to wrong physical address. > > > > > > Elf header: p_type = 1, p_offset = 0x80 p_paddr = 0x80 > > > p_vaddr = 0xfc000800 p_filesz = 0x1e8 p_memsz = 0x1e8 > > > [0xfc000800 should be mapping to 0x800200 and not > > > 0x80] > > > > I think that your comment here is wrong. > > This program header indicates the first memory region in the 1st kernel, > > that is, > > 80-8001e7 : System RAM > > > > Is this region really part of "System RAM?" > > Can you show me the "Virtual kernel memory layout" in dmesg? > > [0.00] Virtual kernel memory layout: > [0.00] modules : 0xfc00 - 0xfc000800 ( > 128 MB) > [0.00] vmalloc : 0xfc000800 - 0xfdff5fff ( > 2045 GB) > [0.00] .text : 0xfc000808 - 0xfc00087d ( > 7488 KB) > [0.00] .rodata : 0xfc00087d - 0xfc0008b4 ( > 3520 KB) > [0.00] .init : 0xfc0008b4 - 0xfc0008c4 ( > 1024 KB) > [0.00] .data : 0xfc0008c4 - 0xfc0008d93e00 ( > 1360 KB) > [0.00].bss : 0xfc0008d93e00 - 0xfc0009438248 ( > 6802 KB) > [0.00] fixed : 0xfdff7e7d - 0xfdff7ec0 ( > 4288 KB) > [0.00] PCI I/O : 0xfdff7ee0 - 0xfdff7fe0 ( > 16 MB) > [0.00] vmemmap : 0xfdff8000 - 0xfe00 ( > 2 GB maximum) > [0.00] 0xfdff8000 - 0xfdff8100 ( > 16 MB actual) > [0.00] memory : 0xfe00 - 0xfe04 ( > 16384 MB) > > > > > > Elf header: p_type = 1, p_offset = 0x8001e8 p_paddr = 0x8001e8 > > > p_vaddr = 0xfc0009e8 p_filesz = 0x7df8 p_memsz = 0x7df8 > > > Elf header: p_type = 1, p_offset = 0x80ffe0 p_paddr = 0x80ffe0 > > > p_vaddr = 0xfc0107e0 p_filesz = 0x2ff38 p_memsz = 0x2ff38 > > > Elf header: p_type = 1, p_offset = 0x83ff18 p_paddr = 0x83ff18 > > > p_vaddr = 0xfc040718 p_filesz = 0x5 p_memsz = 0x5 > > > Elf header: p_type = 1, p_offset = 0x83ff1d p_paddr = 0x83ff1d > > > p_vaddr = 0xfc04071d p_filesz = 0x5 p_memsz = 0x5 > > > Elf header: p_type = 1, p_offset = 0x83ff22 p_paddr = 0x83ff22 > > > p_vaddr = 0xfc040722 p_filesz
Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support
On 19/08/2016:04:19:31 PM, AKASHI Takahiro wrote: > Pratyush, Geoff > > # If I had Seattle, I could debug easily :) > > On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote: > > Hi Geoff and Takahiro, > > > > I am having some issues with kexec+kdump while working with Seattle > > platform. On > > top level, kernel crashes in copy_oldmem_page(), because it gets wrong > > offset > > for log_buf during vmcore-dmesg save. > > > > Here is the detail: > > > > (1) From /proc/iomem, these are the "System RAM" Components: > > > > 80-8001e7 : System RAM > > 8001e8-83ff17 : System RAM > > 800208-8002b3 : Kernel code > > 8002c4-800348 : Kernel data > > 807fe0-80ffdf : Crash kernel > > 83ff18-83ff1c : System RAM > > 83ff1d-83ff21 : System RAM > > 83ff22-83ffe4 : System RAM > > 83ffe5-83 : System RAM > > > > (2) From kexec-tools debug print I see following: > > elf_arm64_load: e_entry: fc000808 -> 0088 > > elf_arm64_load: p_vaddr: fc000808 -> 0088 > > elf_arm64_load: header_offset: > > elf_arm64_load: text_offset: 0008 > > elf_arm64_load: image_size:0141 > > elf_arm64_load: phys_offset: 0080 > > elf_arm64_load: page_offset: fc000800 > > > > I understand that "Kernel Code start physical address" 0x800208 should > > map > > to e_entry vaddr which is 0xfc000808. However, kexec-tools debug > > print > > shows that e_entry vaddr maps to PA 88 which seems wrong. > > Obviously, virt_to_phys() is wrong. > As you know, we have to calculate virt_to_phys() in a different way > depending on whether the vaddr is greater than PAGE_OFFSET (linear mapping) > or not (kernel image mapping). > See the kernel's include/asm/memory.h. > > Geoff, please update this function. > > > (3) further page_offset (or vp_offset in your new code) is calculated > > as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset; > > > > Current calcualtion of page_offset leads to wrong configuration of VA of > > alls > > PT_LOAD (see below). Ultimately, this is also leading to kernel crash during > > vmcore-dmesg and vmcore save operations, because we pass an offset to > > pread() > > system call which maps to wrong physical address. > > > > Elf header: p_type = 1, p_offset = 0x80 p_paddr = 0x80 > > p_vaddr = 0xfc000800 p_filesz = 0x1e8 p_memsz = 0x1e8 > > [0xfc000800 should be mapping to 0x800200 and not 0x80] > > I think that your comment here is wrong. > This program header indicates the first memory region in the 1st kernel, > that is, > 80-8001e7 : System RAM > > Is this region really part of "System RAM?" > Can you show me the "Virtual kernel memory layout" in dmesg? [0.00] Virtual kernel memory layout: [0.00] modules : 0xfc00 - 0xfc000800 ( 128 MB) [0.00] vmalloc : 0xfc000800 - 0xfdff5fff ( 2045 GB) [0.00] .text : 0xfc000808 - 0xfc00087d ( 7488 KB) [0.00] .rodata : 0xfc00087d - 0xfc0008b4 ( 3520 KB) [0.00] .init : 0xfc0008b4 - 0xfc0008c4 ( 1024 KB) [0.00] .data : 0xfc0008c4 - 0xfc0008d93e00 ( 1360 KB) [0.00].bss : 0xfc0008d93e00 - 0xfc0009438248 ( 6802 KB) [0.00] fixed : 0xfdff7e7d - 0xfdff7ec0 ( 4288 KB) [0.00] PCI I/O : 0xfdff7ee0 - 0xfdff7fe0 (16 MB) [0.00] vmemmap : 0xfdff8000 - 0xfe00 ( 2 GB maximum) [0.00] 0xfdff8000 - 0xfdff8100 (16 MB actual) [0.00] memory : 0xfe00 - 0xfe04 ( 16384 MB) > > > Elf header: p_type = 1, p_offset = 0x8001e8 p_paddr = 0x8001e8 > > p_vaddr = 0xfc0009e8 p_filesz = 0x7df8 p_memsz = 0x7df8 > > Elf header: p_type = 1, p_offset = 0x80ffe0 p_paddr = 0x80ffe0 > > p_vaddr = 0xfc0107e0 p_filesz = 0x2ff38 p_memsz = 0x2ff38 > > Elf header: p_type = 1, p_offset = 0x83ff18 p_paddr = 0x83ff18 > > p_vaddr = 0xfc040718 p_filesz = 0x5 p_memsz = 0x5 > > Elf header: p_type = 1, p_offset = 0x83ff1d p_paddr = 0x83ff1d > > p_vaddr = 0xfc04071d p_filesz = 0x5 p_memsz = 0x5 > > Elf header: p_type = 1, p_offset = 0x83ff22 p_paddr = 0x83ff22 > > p_vaddr = 0xfc040722 p_filesz = 0xc3 p_memsz = 0xc3 > > Elf header: p_type = 1, p_offset = 0x83ffe5 p_paddr = 0x83ffe5 > > p_vaddr = 0xfc0407e5 p_filesz = 0x1b p_memsz = 0x1b > > > > May be following should be better. > > arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offs
Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support
Pratyush, Geoff
# If I had Seattle, I could debug easily :)
On Wed, Aug 10, 2016 at 11:26:48PM +0530, Pratyush Anand wrote:
> Hi Geoff and Takahiro,
>
> I am having some issues with kexec+kdump while working with Seattle platform.
> On
> top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
> for log_buf during vmcore-dmesg save.
>
> Here is the detail:
>
> (1) From /proc/iomem, these are the "System RAM" Components:
>
> 80-8001e7 : System RAM
> 8001e8-83ff17 : System RAM
> 800208-8002b3 : Kernel code
> 8002c4-800348 : Kernel data
> 807fe0-80ffdf : Crash kernel
> 83ff18-83ff1c : System RAM
> 83ff1d-83ff21 : System RAM
> 83ff22-83ffe4 : System RAM
> 83ffe5-83 : System RAM
>
> (2) From kexec-tools debug print I see following:
> elf_arm64_load: e_entry: fc000808 -> 0088
> elf_arm64_load: p_vaddr: fc000808 -> 0088
> elf_arm64_load: header_offset:
> elf_arm64_load: text_offset: 0008
> elf_arm64_load: image_size:0141
> elf_arm64_load: phys_offset: 0080
> elf_arm64_load: page_offset: fc000800
>
> I understand that "Kernel Code start physical address" 0x800208 should map
> to e_entry vaddr which is 0xfc000808. However, kexec-tools debug print
> shows that e_entry vaddr maps to PA 88 which seems wrong.
Obviously, virt_to_phys() is wrong.
As you know, we have to calculate virt_to_phys() in a different way
depending on whether the vaddr is greater than PAGE_OFFSET (linear mapping)
or not (kernel image mapping).
See the kernel's include/asm/memory.h.
Geoff, please update this function.
> (3) further page_offset (or vp_offset in your new code) is calculated
> as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
>
> Current calcualtion of page_offset leads to wrong configuration of VA of alls
> PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
> vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
> system call which maps to wrong physical address.
>
> Elf header: p_type = 1, p_offset = 0x80 p_paddr = 0x80
> p_vaddr = 0xfc000800 p_filesz = 0x1e8 p_memsz = 0x1e8
> [0xfc000800 should be mapping to 0x800200 and not 0x80]
I think that your comment here is wrong.
This program header indicates the first memory region in the 1st kernel,
that is,
80-8001e7 : System RAM
Is this region really part of "System RAM?"
Can you show me the "Virtual kernel memory layout" in dmesg?
> Elf header: p_type = 1, p_offset = 0x8001e8 p_paddr = 0x8001e8
> p_vaddr = 0xfc0009e8 p_filesz = 0x7df8 p_memsz = 0x7df8
> Elf header: p_type = 1, p_offset = 0x80ffe0 p_paddr = 0x80ffe0
> p_vaddr = 0xfc0107e0 p_filesz = 0x2ff38 p_memsz = 0x2ff38
> Elf header: p_type = 1, p_offset = 0x83ff18 p_paddr = 0x83ff18
> p_vaddr = 0xfc040718 p_filesz = 0x5 p_memsz = 0x5
> Elf header: p_type = 1, p_offset = 0x83ff1d p_paddr = 0x83ff1d
> p_vaddr = 0xfc04071d p_filesz = 0x5 p_memsz = 0x5
> Elf header: p_type = 1, p_offset = 0x83ff22 p_paddr = 0x83ff22
> p_vaddr = 0xfc040722 p_filesz = 0xc3 p_memsz = 0xc3
> Elf header: p_type = 1, p_offset = 0x83ffe5 p_paddr = 0x83ffe5
> p_vaddr = 0xfc0407e5 p_filesz = 0x1b p_memsz = 0x1b
>
> May be following should be better.
> arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.
Probably not.
> (4) Further more, vmcore must have first PT_LOAD segment as kernel text area.
Which part of the code do you think depends on this assumption?
Thanks,
-Takahiro AKASHI
> In this platform we have first "System RAM" area as 80-8001e7
> which
> is not matching to "Kernel code" area. Therefore, we should provide support of
> "kern_size" so that first PT_LOAD is kernel text area.
>
> ~Pratyush
> On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> > My kernel patches of kdump suport on arm64 are currently under reviews [1].
> >
> > This patchset is synced with them (v24) and provides necessary changes for
> > kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > v3[2] along with a bugfix[3].
> >
> > [1]
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> > [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> >
> > Changes for v2:
> > - Trim a temoprary buffer in setup_2nd_dtb()
> > - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> > - Update patch#7 from Pratyush
> >(re-worked by akashi)
> >
> > AKASHI Takahiro (5):
> > arm64: kdump: identify memory regions
> > arm64: kdump:
Re: [PATCH v2 0/7] (kexec-tools) arm64: add kdump support
Hi Geoff and Takahiro,
I am having some issues with kexec+kdump while working with Seattle platform. On
top level, kernel crashes in copy_oldmem_page(), because it gets wrong offset
for log_buf during vmcore-dmesg save.
Here is the detail:
(1) From /proc/iomem, these are the "System RAM" Components:
80-8001e7 : System RAM
8001e8-83ff17 : System RAM
800208-8002b3 : Kernel code
8002c4-800348 : Kernel data
807fe0-80ffdf : Crash kernel
83ff18-83ff1c : System RAM
83ff1d-83ff21 : System RAM
83ff22-83ffe4 : System RAM
83ffe5-83 : System RAM
(2) From kexec-tools debug print I see following:
elf_arm64_load: e_entry: fc000808 -> 0088
elf_arm64_load: p_vaddr: fc000808 -> 0088
elf_arm64_load: header_offset:
elf_arm64_load: text_offset: 0008
elf_arm64_load: image_size:0141
elf_arm64_load: phys_offset: 0080
elf_arm64_load: page_offset: fc000800
I understand that "Kernel Code start physical address" 0x800208 should map
to e_entry vaddr which is 0xfc000808. However, kexec-tools debug print
shows that e_entry vaddr maps to PA 88 which seems wrong.
(3) further page_offset (or vp_offset in your new code) is calculated
as:arm64_mem.page_offset = ehdr.e_entry - arm64_mem.text_offset;
Current calcualtion of page_offset leads to wrong configuration of VA of alls
PT_LOAD (see below). Ultimately, this is also leading to kernel crash during
vmcore-dmesg and vmcore save operations, because we pass an offset to pread()
system call which maps to wrong physical address.
Elf header: p_type = 1, p_offset = 0x80 p_paddr = 0x80
p_vaddr = 0xfc000800 p_filesz = 0x1e8 p_memsz = 0x1e8
[0xfc000800 should be mapping to 0x800200 and not 0x80]
Elf header: p_type = 1, p_offset = 0x8001e8 p_paddr = 0x8001e8
p_vaddr = 0xfc0009e8 p_filesz = 0x7df8 p_memsz = 0x7df8
Elf header: p_type = 1, p_offset = 0x80ffe0 p_paddr = 0x80ffe0
p_vaddr = 0xfc0107e0 p_filesz = 0x2ff38 p_memsz = 0x2ff38
Elf header: p_type = 1, p_offset = 0x83ff18 p_paddr = 0x83ff18
p_vaddr = 0xfc040718 p_filesz = 0x5 p_memsz = 0x5
Elf header: p_type = 1, p_offset = 0x83ff1d p_paddr = 0x83ff1d
p_vaddr = 0xfc04071d p_filesz = 0x5 p_memsz = 0x5
Elf header: p_type = 1, p_offset = 0x83ff22 p_paddr = 0x83ff22
p_vaddr = 0xfc040722 p_filesz = 0xc3 p_memsz = 0xc3
Elf header: p_type = 1, p_offset = 0x83ffe5 p_paddr = 0x83ffe5
p_vaddr = 0xfc0407e5 p_filesz = 0x1b p_memsz = 0x1b
May be following should be better.
arm64_mem.page_offset = ehdr.e_entry - "kernel Code Start PA" + phys_offset.
(4) Further more, vmcore must have first PT_LOAD segment as kernel text area.
In this platform we have first "System RAM" area as 80-8001e7 which
is not matching to "Kernel code" area. Therefore, we should provide support of
"kern_size" so that first PT_LOAD is kernel text area.
~Pratyush
On 09/08/2016:11:00:25 AM, AKASHI Takahiro wrote:
> My kernel patches of kdump suport on arm64 are currently under reviews [1].
>
> This patchset is synced with them (v24) and provides necessary changes for
> kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> v3[2] along with a bugfix[3].
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
> [2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
> [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
>
> Changes for v2:
> - Trim a temoprary buffer in setup_2nd_dtb()
> - Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
> - Update patch#7 from Pratyush
>(re-worked by akashi)
>
> AKASHI Takahiro (5):
> arm64: kdump: identify memory regions
> arm64: kdump: add elf core header segment
> arm64: kdump: set up kernel image segment
> arm64: kdump: set up other segments
> arm64: kdump: add DT properties to crash dump kernel's dtb
>
> Pratyush Anand (2):
> kexec: generalize and rename get_kernel_stext_sym()
> arm64: kdump: Add support for binary image files
>
> kexec/arch/arm/crashdump-arm.c | 40 +--
> kexec/arch/arm64/Makefile | 2 +
> kexec/arch/arm64/crashdump-arm64.c | 188
> +++-
> kexec/arch/arm64/crashdump-arm64.h | 18 ++-
> kexec/arch/arm64/include/arch/options.h | 8 +-
> kexec/arch/arm64/kexec-arm64.c | 91 ++--
> kexec/arch/arm64/kexec-elf-arm64.c | 23 +++-
> kexec/arch/arm64/kexec-image-arm64.c| 60 +-
> kexec/arch/i386/crashdump-x86.c | 32 +-
> kexec/crashdump.c | 37 +++
> kexec/crashdump.h | 1 +
> 11 files
[PATCH v2 0/7] (kexec-tools) arm64: add kdump support
My kernel patches of kdump suport on arm64 are currently under reviews [1].
This patchset is synced with them (v24) and provides necessary changes for
kexec-tools. It should be applied on top of Geoff's kexec-tools patches
v3[2] along with a bugfix[3].
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447597.html
[2] http://lists.infradead.org/pipermail/kexec/2016-August/016768.html
[3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
Changes for v2:
- Trim a temoprary buffer in setup_2nd_dtb()
- Add patch#6("kexec: generalize and rename get_kernel_stext_sym()")
- Update patch#7 from Pratyush
(re-worked by akashi)
AKASHI Takahiro (5):
arm64: kdump: identify memory regions
arm64: kdump: add elf core header segment
arm64: kdump: set up kernel image segment
arm64: kdump: set up other segments
arm64: kdump: add DT properties to crash dump kernel's dtb
Pratyush Anand (2):
kexec: generalize and rename get_kernel_stext_sym()
arm64: kdump: Add support for binary image files
kexec/arch/arm/crashdump-arm.c | 40 +--
kexec/arch/arm64/Makefile | 2 +
kexec/arch/arm64/crashdump-arm64.c | 188 +++-
kexec/arch/arm64/crashdump-arm64.h | 18 ++-
kexec/arch/arm64/include/arch/options.h | 8 +-
kexec/arch/arm64/kexec-arm64.c | 91 ++--
kexec/arch/arm64/kexec-elf-arm64.c | 23 +++-
kexec/arch/arm64/kexec-image-arm64.c| 60 +-
kexec/arch/i386/crashdump-x86.c | 32 +-
kexec/crashdump.c | 37 +++
kexec/crashdump.h | 1 +
11 files changed, 407 insertions(+), 93 deletions(-)
--
2.9.0
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
