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 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.