Re: [PATCH] makedumpfile: Support ARM64

[sgoel@codeaurora.org]

Hi Pratyush,

I made the following changes to the code:

KVBASE was being mapped to page_offset, so the mem_map that I saw using
the kmem command in crash did not seem to audit with the data generated by
make dumpfile. I changed this to vmalloc_start.

After making the above change the mem_map was getting generated fine. But
still I am always failing in:
================================
ptea = pte_offset(&pmdv, vaddr);
		/* 64k page */
		if (!readmem(VADDR, (unsigned long long)ptea, &ptev, sizeof(ptev))) {
			ERRMSG("Can't read pte\n");
			return NOT_PADDR;
		}
=================================


The KERN_STRUCT_PAGE_SIZE evaluates to 56 and not 64. I changed the
required value and the arch info is now valid.

I am still failing in the page translation. I will highly appreciate any
help with this.

Thanks,
Sameer

> Adding Sameer as he has a few questions on kvbase.
>
>> Hi Pratyush,
>>
>> I was able to run makedumpfile with "-d 31" but the dumpfile was
>> approximately the same size as that of vmcore (~16GB).
>>
>> Answers inline.
>>
>>> Hi Azriel,
>>>
>>> On 01/07/2015:06:42:46 PM, Azriel Samson wrote:
>>>> Hi Pratyush,
>>>>
>>>> I am working with Timur and we are testing your version of
>>>> makedumpfile.
>>>
>>> Thanks for testing.
>>>
>>>> The tool is unable to get the kernel version and quits from
>>>> check_release().
>>>
>>> Couple of questions:
>>>
>>> 1. Can you please let me know VA_BITS configured in your case?
>> VA_BITS=39
>>> 2. Do you expect any regions other than vmalloc, vmemmap or modules,
>>> which are not directly mapped and their physical address need to be
>>> found from swapper_pg_dir?
>> No
>>> In my vmcore, I did not had any address where
>>> is_vtop_from_page_table_arm64 would be true. So, vtop_arm64 function
>>> has been only cross checked logically. So,
>>> a) Please put a print in vtop_arm64 and check if control goes there?
>>> b) if yes, then please print vaddr and paddr at the end of vtop_arm64
>>> and see if that is correct. If not we need to debug vtop_arm64.
>> I still need to try this. Will get back when I do.
>>> ~Pratyush
>>>
>>>>
>>>> I tried to debug the vmcore file with gdb but the file looks corrupt.
>>>>
>>>> Let me know if you have any ideas on what could be wrong?
>>>>
>>>> > Hi Timur,
>>>> >
>>>> > On 23/06/2015:10:36:03 PM, Timur Tabi wrote:
>>>> >> Pratyush Anand wrote:
>>>> >> >I can try to find out some time in weekend to refactor arm64 code
>>>> >> >and then add 3 level, 4K support. May be I will need a Tested-by.
>>>> >>
>>>> >> We'd be more than happy to test any code from you promptly.  We're
>>>> eager
>>>> >> to
>>>> >> get this to work.
>>>> >
>>>> > I have done the changes, hopefully it should work, but have not
>>>> > tested. Let me know, if it works will send them as formal patches
>>>> > to upstream.
>>>> >
>>>> > https://github.com/pratyushanand/makedumpfile.git : arm64_support
>>>> > (9b95423bcea0)
>>>> >
>>>> > ~Pratyush
>>>> >
>>>>
>>>> --
>>>> Thanks,
>>>> Azriel Samson
>>>> Qualcomm Innovation Center, Inc.
>>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>>>> Forum, 
>>>> a Linux Foundation Collaborative Project
>>>
>>
>>
>> --
>> Thanks,
>> Azriel Samson
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> Forum, 
>> a Linux Foundation Collaborative Project
>>
>
>
> --
> Thanks,
> Azriel Samson
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum, 
> a Linux Foundation Collaborative Project
>
>



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