All of lore.kernel.org
 help / color / mirror / Atom feed
* makedumpfile: Issue with aarch64 support
@ 2015-05-15  1:51 Pratyush Anand
  2015-05-15  7:00 ` Atsushi Kumagai
  0 siblings, 1 reply; 3+ messages in thread
From: Pratyush Anand @ 2015-05-15  1:51 UTC (permalink / raw)
  To: Atsushi Kumagai; +Cc: kexec, Baoquan He

Hi Atsushi,

* I am adding aarch64 support in makedumpfile. Preliminary patch is here 
[1]. I am having some issue with the dumpdisk created by makedumpfile. 
See, if you get any clue with following inputs.

* I used cp option in kdump.conf to have a good elf vmcore in 
/var/crash/..../vmcore.

* If I run crash over this elf vmcore, then everything goes fine.

* Now I use makedumpfile [1] for dumpdisk creation

  and compression just goes fine.
  # makedumpfile -l --message-level 1 -d 31 /var/crash/..../vmcore vmcore
  Copying data                       : [100.0 %] |

  But, crash does not like the vmcore
  # crash /lib/modules/.../build/vmlinux vmcore -d 31

<readmem: fffffe01ffde2000, KVADDR, "memory section", 32, (FOE),
a2c4eb0>
<read_diskdump: addr: fffffe01ffde2000 paddr: 41fffe2000 cnt: 32>
read_diskdump: SEEK_ERROR: paddr/pfn: 41fffe2000/41fffe max_mapnr:
414000
crash: seek error: kernel virtual address: fffffe01ffde2000  type:
"memory section"

* I tried by removing -d option in makedumpfile , still same issue.

* A print for vaddr in vaddr_to_paddr_arm64 does not show address
fffffe01ffde2000 being asked for translation by makedumpfile core. 
Infact all the vaddr printed are in the range of directly mapped kernel 
VAs, so I did not consider to add support for other memory section like 
vmalloc, vmemmap etc at this point.

Thanks in advance for your help.

~Pratyush

[1] 
https://github.com/pratyushanand/makedumpfile/commit/073bc204c3422d6cee72eed89edb47281ead1a2e

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: makedumpfile: Issue with aarch64 support
  2015-05-15  1:51 makedumpfile: Issue with aarch64 support Pratyush Anand
@ 2015-05-15  7:00 ` Atsushi Kumagai
  2015-05-15 18:16   ` Pratyush Anand
  0 siblings, 1 reply; 3+ messages in thread
From: Atsushi Kumagai @ 2015-05-15  7:00 UTC (permalink / raw)
  To: panand@redhat.com; +Cc: kexec@lists.infradead.org, bhe@redhat.com

Hello Pratyush,

>Hi Atsushi,
>
>* I am adding aarch64 support in makedumpfile. Preliminary patch is here
>[1]. I am having some issue with the dumpdisk created by makedumpfile.
>See, if you get any clue with following inputs.
>
>* I used cp option in kdump.conf to have a good elf vmcore in
>/var/crash/..../vmcore.
>
>* If I run crash over this elf vmcore, then everything goes fine.
>
>* Now I use makedumpfile [1] for dumpdisk creation
>
>  and compression just goes fine.
>  # makedumpfile -l --message-level 1 -d 31 /var/crash/..../vmcore vmcore
>  Copying data                       : [100.0 %] |
>
>  But, crash does not like the vmcore
>  # crash /lib/modules/.../build/vmlinux vmcore -d 31
>
><readmem: fffffe01ffde2000, KVADDR, "memory section", 32, (FOE),
>a2c4eb0>
><read_diskdump: addr: fffffe01ffde2000 paddr: 41fffe2000 cnt: 32>
>read_diskdump: SEEK_ERROR: paddr/pfn: 41fffe2000/41fffe max_mapnr:
>414000

According to this message, it seems that the max_mapnr in disk_dump_header
was calculated wrongly by makedumpfile. pfn:41fffe must be exist since
crash requires it, so max_mapnr must be shortened.
What is the actual maximum pfn of the original vmcore ? If the number is
correct, I have no ideas for now...


Thanks
Atsushi Kumagai

>crash: seek error: kernel virtual address: fffffe01ffde2000  type:
>"memory section"
>
>* I tried by removing -d option in makedumpfile , still same issue.
>
>* A print for vaddr in vaddr_to_paddr_arm64 does not show address
>fffffe01ffde2000 being asked for translation by makedumpfile core.
>Infact all the vaddr printed are in the range of directly mapped kernel
>VAs, so I did not consider to add support for other memory section like
>vmalloc, vmemmap etc at this point.
>
>Thanks in advance for your help.
>
>~Pratyush
>
>[1]
>https://github.com/pratyushanand/makedumpfile/commit/073bc204c3422d6cee72eed89edb47281ead1a2e
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: makedumpfile: Issue with aarch64 support
  2015-05-15  7:00 ` Atsushi Kumagai
@ 2015-05-15 18:16   ` Pratyush Anand
  0 siblings, 0 replies; 3+ messages in thread
From: Pratyush Anand @ 2015-05-15 18:16 UTC (permalink / raw)
  To: Atsushi Kumagai; +Cc: kexec@lists.infradead.org, bhe@redhat.com



On Friday 15 May 2015 12:30 PM, Atsushi Kumagai wrote:
>>   But, crash does not like the vmcore
>> >  # crash/lib/modules/.../build/vmlinux vmcore -d 31
>> >
>> ><readmem: fffffe01ffde2000, KVADDR, "memory section", 32, (FOE),
>> >a2c4eb0>
>> ><read_diskdump: addr: fffffe01ffde2000 paddr: 41fffe2000 cnt: 32>
>> >read_diskdump: SEEK_ERROR: paddr/pfn: 41fffe2000/41fffe max_mapnr:
>> >414000
> According to this message, it seems that the max_mapnr in disk_dump_header
> was calculated wrongly by makedumpfile. pfn:41fffe must be exist since
> crash requires it, so max_mapnr must be shortened.
> What is the actual maximum pfn of the original vmcore ? If the number is
> correct, I have no ideas for now...


Thanks a lot for the pointer. I was able to find error in my aarch64 
code after following your pointer.

Will send the patch for review.

~Pratyush

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-05-15 18:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-15  1:51 makedumpfile: Issue with aarch64 support Pratyush Anand
2015-05-15  7:00 ` Atsushi Kumagai
2015-05-15 18:16   ` Pratyush Anand

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.