KAMEZAWA Hiroyuki wrote:
On Wed, 19 Aug 2009 10:41:13 +0800 Amerigo Wang <amwang@xxxxxxxxxx> wrote:KAMEZAWA Hiroyuki wrote:Hmm, yes, x86_64, but this code is arch-independent, I mean it should work or not work on all arch, no?On Tue, 18 Aug 2009 18:35:32 +0800 Amerigo Wang <amwang@xxxxxxxxxx> wrote:KAMEZAWA Hiroyuki wrote:Just FYI: calling ClearPageReserved() caused an oops: "Unable to handle paging request".On Tue, 18 Aug 2009 14:31:23 +0800 Amerigo Wang <amwang@xxxxxxxxxx> wrote:Not sure, but probably yes. It is reserved in setup_arch() which is before mm_init() which calls mem_init().It's hidden from the system before mem_init() ?Do you have any advice to free that reserved memory after boot? :)Let's see arch/x86/mm/init.c::free_initmem() Maybe it's all you want. - ClearPageReserved() - init_page_count() - free_page() - totalram_pages++I am trying to figure out why...Hmm...then....memmap is not there. pfn_valid() check will help you. What arch ? x86-64 ?So I am afraid we need to use other API to free it...The, problem is whether memmap is there or not. That's all. plz see init sequence and check there are memmap. If memory-for-crash is obtained via bootmem, Don't you try to free memory hole ?
Hi,It looks like that mem_map has 'struct page' for the reserved memory, I checked my "early_node_map[] active PFN ranges" output, the reserved memory area for crash kernel is right in one range. Am I missing something here?
I don't know why that oops comes out, maybe because of no PTE for thoese pages?
Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|