From: Dave Anderson <anderson@redhat.com>
To: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Cc: Jay Lan <jlan@sgi.com>,
kexec@lists.infradead.org, Hedi Berriche <hedi@sgi.com>
Subject: Re: the exiting makedumpfile is almost there... :)
Date: Tue, 23 Sep 2008 11:41:07 -0400 [thread overview]
Message-ID: <48D90E13.3040202@redhat.com> (raw)
In-Reply-To: <48D77E05.30504@mxs.nes.nec.co.jp>
[-- Attachment #1: Type: text/plain, Size: 7373 bytes --]
Hi Ken'ichi,
We just ran into a similar problem using an older version of makedumpfile,
but looking at the latest makedumpfile code, it's seems that you could
run into the same problem.
In exclude_unnecessary_pages(), if a physical page is in a memory
hole, then it skips the page and continues. In our case, that happened,
but when it started up again, the next legitimate pfn was well beyond
the previously-read cache of 512 pages. But since the new legit page
wasn't modulo-512, it didn't refresh the page cache, and it ended up
using stale page data (page->flags) and ended up excluding legitimate
pages:
for (; pfn < mmd->pfn_end;
pfn++, mem_map += SIZE(page),
paddr += info->page_size) {
/*
* Exclude the memory hole.
*/
if (!is_in_segs(paddr))
continue;
if ((pfn % PGMM_CACHED) == 0) {
if (pfn + PGMM_CACHED < mmd->pfn_end)
pfn_mm = PGMM_CACHED;
else
pfn_mm = mmd->pfn_end - pfn;
if (!readmem(VADDR, mem_map, page_cache,
SIZE(page) * pfn_mm))
goto out;
}
We fixed it by doing something like this:
if (!is_in_segs(paddr)) {
reset_cache = 1;
continue;
}
if (((pfn % PGMM_CACHED) == 0) || reset_cache) {
reset_cache = 0;
...
Dave
Ken'ichi Ohmichi wrote:
> Hi Jay,
>
> My IA64 linux-2.6.27-rc7 kernel could boot by your patches and its kdump
> succeeded, thanks. But I cannot reproduce this problem unfortunately.
> Could you send me your kernel .config file to reproduce it ?
>
> And could you please research the reason why the page of virtual address
> 0xe0000060031417a8 is excluded ? This patch is for researching it.
> Please apply it against makedumpfile-1.2.9, and create a dump file
> by makedumpfile with "-e 0xe0000060031417a8" option. The reason why
> excluding the page is printed like the following:
>
> # makedumpfile -cd31 -e 0xe000000062744000 -x vmlinux /proc/vmcore dump.cd31
> The kernel version is not supported.
> The created dumpfile may be incomplete.
> Excluding unnecessary pages : [100 %]
> PAGE(vaddr:e000000062744000, pfn:189d1) is excluded as FREE PAGE.
>
> Copying data : [100 %]
>
> The dumpfile is saved to dump.cd31.
>
> makedumpfile Completed.
> #
>
>
> Thanks
> Ken'ichi Ohmichi
>
> ---
> diff -puN backup/makedumpfile-1.2.9/makedumpfile.c makedumpfile/makedumpfile.c
> --- backup/makedumpfile-1.2.9/makedumpfile.c 2008-09-04 16:31:58.000000000 +0900
> +++ makedumpfile/makedumpfile.c 2008-09-22 20:15:37.000000000 +0900
> @@ -3360,6 +3360,9 @@ out:
> if (!get_mem_map())
> return FALSE;
>
> + if (info->vaddr_why_excluded)
> + info->pfn_why_excluded = (vaddr_to_paddr(info->vaddr_why_excluded) / info->page_size);
> +
> return TRUE;
> }
>
> @@ -3470,8 +3473,14 @@ clear_bit_on_1st_bitmap(unsigned long lo
> }
>
> int
> -clear_bit_on_2nd_bitmap(unsigned long long pfn)
> +clear_bit_on_2nd_bitmap(unsigned long long pfn, char *page_type)
> {
> + if (info->pfn_why_excluded == pfn) {
> + MSG("\n");
> + MSG("PAGE(vaddr:%lx, pfn:%llx) is excluded as %s.\n",
> + info->vaddr_why_excluded, info->pfn_why_excluded, page_type);
> + MSG("\n");
> + }
> return set_bitmap(info->bitmap2, pfn, 0);
> }
>
> @@ -3872,7 +3881,7 @@ reset_bitmap_of_free_pages(unsigned long
> }
> for (i = 0; i < (1<<order); i++) {
> pfn = start_pfn + i;
> - clear_bit_on_2nd_bitmap(pfn);
> + clear_bit_on_2nd_bitmap(pfn, "FREE PAGE");
> }
> found_free_pages += i;
>
> @@ -4114,7 +4123,7 @@ exclude_zero_pages(void)
> return FALSE;
>
> if (is_zero_page(buf, info->page_size)) {
> - clear_bit_on_2nd_bitmap(pfn);
> + clear_bit_on_2nd_bitmap(pfn, "ZERO PAGE");
> pfn_zero++;
> }
> }
> @@ -4186,7 +4195,7 @@ exclude_unnecessary_pages(void)
> if ((info->dump_level & DL_EXCLUDE_CACHE)
> && (isLRU(flags) || isSwapCache(flags))
> && !isPrivate(flags) && !isAnon(mapping)) {
> - clear_bit_on_2nd_bitmap(pfn);
> + clear_bit_on_2nd_bitmap(pfn, "CACHE PAGE");
> pfn_cache++;
> }
> /*
> @@ -4195,7 +4204,7 @@ exclude_unnecessary_pages(void)
> else if ((info->dump_level & DL_EXCLUDE_CACHE_PRI)
> && (isLRU(flags) || isSwapCache(flags))
> && !isAnon(mapping)) {
> - clear_bit_on_2nd_bitmap(pfn);
> + clear_bit_on_2nd_bitmap(pfn, "CACHE PRIVATE PAGE");
> pfn_cache_private++;
> }
> /*
> @@ -4203,7 +4212,7 @@ exclude_unnecessary_pages(void)
> */
> else if ((info->dump_level & DL_EXCLUDE_USER_DATA)
> && isAnon(mapping)) {
> - clear_bit_on_2nd_bitmap(pfn);
> + clear_bit_on_2nd_bitmap(pfn, "USER DATA PAGE");
> pfn_user++;
> }
> }
> @@ -5794,7 +5803,7 @@ exclude_xen_user_domain(void)
> size * info->num_load_memory);
>
> if (!allocated_in_map(pfn)) {
> - clear_bit_on_2nd_bitmap(pfn);
> + clear_bit_on_2nd_bitmap(pfn, "USER DOMAIN PAGE");
> continue;
> }
>
> @@ -5802,7 +5811,7 @@ exclude_xen_user_domain(void)
> if (!readmem(VADDR_XEN,
> page_info_addr + OFFSET(page_info.count_info),
> &count_info, sizeof(count_info))) {
> - clear_bit_on_2nd_bitmap(pfn);
> + clear_bit_on_2nd_bitmap(pfn, "USER DOMAIN PAGE");
> continue; /* page_info may not exist */
> }
> if (!readmem(VADDR_XEN,
> @@ -5823,7 +5832,7 @@ exclude_xen_user_domain(void)
> continue;
> if ((count_info & 0xffff) && is_select_domain(_domain))
> continue;
> - clear_bit_on_2nd_bitmap(pfn);
> + clear_bit_on_2nd_bitmap(pfn, "USER DOMAIN PAGE");
> }
> }
>
> @@ -6162,7 +6171,7 @@ main(int argc, char *argv[])
>
> info->block_order = DEFAULT_ORDER;
> message_level = DEFAULT_MSG_LEVEL;
> - while ((opt = getopt_long(argc, argv, "b:cDd:EFfg:hi:RVvXx:", longopts,
> + while ((opt = getopt_long(argc, argv, "b:cDd:Ee:Ffg:hi:RVvXx:", longopts,
> NULL)) != -1) {
> switch (opt) {
> case 'b':
> @@ -6180,6 +6189,9 @@ main(int argc, char *argv[])
> case 'E':
> info->flag_elf_dumpfile = 1;
> break;
> + case 'e':
> + info->vaddr_why_excluded = strtoul(optarg, NULL, 0);
> + break;
> case 'F':
> info->flag_flatten = 1;
> break;
> diff -puN backup/makedumpfile-1.2.9/makedumpfile.h makedumpfile/makedumpfile.h
> --- backup/makedumpfile-1.2.9/makedumpfile.h 2008-09-04 16:31:58.000000000 +0900
> +++ makedumpfile/makedumpfile.h 2008-09-22 18:41:16.000000000 +0900
> @@ -725,6 +725,8 @@ struct DumpInfo {
> int flag_force; /* overwrite existing stuff */
> int flag_exclude_xen_dom;/* exclude Domain-U from xen-kdump */
> unsigned long vaddr_for_vtop; /* virtual address for debugging */
> + unsigned long vaddr_why_excluded;
> + unsigned long long pfn_why_excluded;
> long page_size; /* size of page */
> long page_shift;
> unsigned long long max_mapnr; /* number of page descriptor */
>
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2008-09-23 15:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-10 23:28 the exiting makedumpfile is almost there... :) Jay Lan
2008-09-11 2:03 ` Ken'ichi Ohmichi
2008-09-11 8:21 ` Bernhard Walle
2008-09-11 2:31 ` Ken'ichi Ohmichi
2008-09-11 14:13 ` Dave Anderson
2008-09-11 14:32 ` Hedi Berriche
2008-09-12 2:21 ` Ken'ichi Ohmichi
2008-09-12 13:38 ` Jay Lan
2008-09-12 19:49 ` Jay Lan
2008-09-12 20:38 ` Dave Anderson
2008-09-12 22:21 ` Jay Lan
2008-09-15 15:24 ` Dave Anderson
2008-09-22 11:14 ` Ken'ichi Ohmichi
2008-09-23 15:41 ` Dave Anderson [this message]
2008-09-24 1:09 ` Ken'ichi Ohmichi
2008-09-24 18:30 ` Jay Lan
2008-09-24 21:56 ` Jay Lan
2008-09-25 6:38 ` Ken'ichi Ohmichi
2008-09-25 11:31 ` Ken'ichi Ohmichi
2008-09-25 19:22 ` Jay Lan
2008-09-26 0:17 ` Ken'ichi Ohmichi
2008-09-23 20:20 ` Jay Lan
2008-09-23 20:47 ` Dave Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48D90E13.3040202@redhat.com \
--to=anderson@redhat.com \
--cc=hedi@sgi.com \
--cc=jlan@sgi.com \
--cc=kexec@lists.infradead.org \
--cc=oomichi@mxs.nes.nec.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox