Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Lan <jlan@sgi.com>
To: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Cc: kexec@lists.infradead.org, Dave Anderson <anderson@redhat.com>,
	Hedi Berriche <hedi@sgi.com>
Subject: Re: the exiting makedumpfile is almost there... :)
Date: Wed, 24 Sep 2008 14:56:44 -0700	[thread overview]
Message-ID: <48DAB79C.9050601@sgi.com> (raw)
In-Reply-To: <48DA8738.2090207@sgi.com>

[-- Attachment #1: Type: text/plain, Size: 3304 bytes --]

Jay Lan wrote:
> Ken'ichi Ohmichi wrote:
>> Hi Dave, Jay,
>>
>> Dave Anderson wrote:
>>> 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;
>>>                  ...
>> Great, you are right.
>> Thank you for fixing it  :-) 
>>
>> Jay, could you try Dave's fixing like the attached patch ?
> 
> Yes. I applied your version of Dave's patch and tried again.
> It failed at a different pfn f600315:
> 
> 
> a4700rac:/mnt/sda9/diskdump # rm dump.cd31; /var/tmp/jlan/makedumpfile
> -cd31 -e 0xe0000f60031502f0 -x vmlinux.3 vmcore-cp.3 dump.cd31
> Excluding unnecessary pages        : [ 45 %]
> pfn=f600315 flags=3c000000001026c
> 
> PAGE(vaddr:e0000f60031502f0, pfn:f600315) is excluded as CACHE PAGE.
> 
> Copying data                       : [100 %]
> 
> The dumpfile is saved to dump.cd31.
> 
> makedumpfile Completed.
> 
> 
> Note the flags of pfn f600315. Crash checked on the pfn using the
> vmcore-cp.3 and showed different flags:
> 
> crash> kmem -p f60031502f0
>       PAGE         PHYSICAL      MAPPING       INDEX CNT FLAGS
> a07ffffc45d00498 f6003150000                0        0  1 3c0000000000400
> crash>
> 

I ran a testing on a 2-cpu  machine. The legitimate page got excluded
is:
   PAGE(vaddr:e00000300313fb70, pfn:300313) is excluded as CACHE PAGE

Values of some variables in the routine on processing that page are:
  pfn=300313 flags=3026c, page.flags=0
  page_cache=0x6000000000033f60, pcache=0x6000000000037b88

Hope these data help.

Thanks,
 - jay


>    
>>
>> Thanks
>> Ken'ichi Ohmichi
>>
> 



[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

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

  reply	other threads:[~2008-09-24 21:56 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
2008-09-24  1:09                 ` Ken'ichi Ohmichi
2008-09-24 18:30                   ` Jay Lan
2008-09-24 21:56                     ` Jay Lan [this message]
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=48DAB79C.9050601@sgi.com \
    --to=jlan@sgi.com \
    --cc=anderson@redhat.com \
    --cc=hedi@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