Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "bhe@redhat.com" <bhe@redhat.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"vgoyal@redhat.com" <vgoyal@redhat.com>
Subject: Re: [Patch v3 7/7] add a new interface to show the memory usage of 1st kernel
Date: Tue, 26 Aug 2014 11:22:47 +0800	[thread overview]
Message-ID: <20140826032247.GA6230@dhcp-16-105.nay.redhat.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9724F9CA@BPXM01GP.gisp.nec.co.jp>

On 08/26/14 at 02:28am, Atsushi Kumagai wrote:
> >On 08/01/14 at 07:12am, Atsushi Kumagai wrote:
> >> >Page number of memory in different use
> >> >--------------------------------------------------
> >> >TYPE		PAGES			EXCLUDABLE	DESCRIPTION
> >> >ZERO		0               	yes		Pages filled with zero
> >>
> >> The number of zero pages is always 0 since it isn't counted during
> >> get_num_dumpable_cyclic(). To count it up, we have to read all of the
> >> pages like exclude_zero_pages(), so we need "exclude_zero_pages_cyclic()".
> >> My idea is to call it in get_num_dumpable_cyclic() like:
> >>
> >> 		for_each_cycle(0, info->max_mapnr, &cycle)
> >> 		{
> >> 				if (!exclude_unnecessary_pages_cyclic(&cycle))
> >> 					return FALSE;
> >>
> >> +				if (info->flag_mem_usage)
> >> +					exclude_zero_pages_cyclic(&cycle);
> >> +
> >> 				for(pfn=cycle.start_pfn; pfn<cycle.end_pfn; pfn++)
> >
> >
> >Hi Atsushi,
> >
> >I just introduced a new function exclude_zero_pages_cyclic as you
> >suggested. But it always exited with below message. I don't know what's
> >wrong with this function. Could you help have a look at it?
> >
> >"Program terminated with signal SIGKILL"
> 
> Umm, the code looks no problem and it works well at least on my
> machine (x86_64 on KVM), so I have no idea for now.
> 
> Can strace and audit help your investigation? They may provide
> some hints (e.g. Who send SIGKILL) for us.

It only happened on a AMD machine with Quad-Core AMD Opteron(tm)
Processor 1352. I tested on my other 2 intel machines, both of them are
OK.

Just now I used strace to check it, and found it's caused by a reading.
It's weird since that page should be inside the System RAM and can be
read. And before this handling hwpoison has been checked. I am wondering
why it happened.


[ ~]$ sudo readelf -l /proc/kcore                                                                                                                                        

Elf file type is CORE (Core file)
Entry point 0x0
There are 13 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
...

This is the load segment where the page reading error happened.
  LOAD           0x0000080080001000 0xffff880080000000
0x0000000000000000
                 0x000000004fee0000 0x000000004fee0000  RWE    1000
...

  LOAD           0x00006a0002001000 0xffffea0002000000
0x0000000000000000
                 0x00000000013fc000 0x00000000013fc000  RWE    1000
  LOAD           0x0000080100001000 0xffff880100000000
0x0000000000000000
                 0x0000000130000000 0x0000000130000000  RWE    1000

read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 8799351988224, SEEK_SET)       = 8799351988224
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 8799351992320, SEEK_SET)       = 8799351992320
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 8799351996416, SEEK_SET)       = 8799351996416
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 8799365541888, SEEK_SET)       = 8799365541888
read(3,
"\340\216\274\226f\177\0\0PCD\224f\177\0\0\265\0\0\0\0\0\0\0p\217\274\226f\177\0\0"...,
4096) = 4096
-----------------------------------------
Here it use lseek to position, then try to read, and then reading failed
and raised a SIGKILL.

lseek(3, 8799381360640, SEEK_SET)       = 8799381360640
read(3,  <unfinished ...>
+++ killed by SIGKILL +++
Killed
> 
> 
> Thanks
> Atsushi Kumagai
> 

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

  reply	other threads:[~2014-08-26  3:24 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-28  8:19 [Patch v3 0/7] add a new interface to show the memory usage of 1st kernel Baoquan He
2014-07-28  8:20 ` [Patch v3 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
2014-07-28  8:20 ` [Patch v3 2/7] functions to get crashkernel memory range Baoquan He
2014-08-01  7:32   ` Atsushi Kumagai
2014-08-12  9:25     ` bhe
2014-07-28  8:20 ` [Patch v3 3/7] preparation functions for parsing vmcoreinfo Baoquan He
2014-08-01  7:12   ` Atsushi Kumagai
2014-08-12  9:46     ` bhe
2014-08-12 10:01       ` bhe
2014-08-14  7:37         ` Atsushi Kumagai
2014-08-14  8:15           ` bhe
2014-07-28  8:20 ` [Patch v3 4/7] set vmcoreinfo for kcore Baoquan He
2014-08-01  7:12   ` Atsushi Kumagai
2014-08-12 10:08     ` bhe
2014-07-28  8:20 ` [Patch v3 5/7] prepare the dump loads for kcore analysis Baoquan He
2014-08-01  7:12   ` Atsushi Kumagai
2014-08-12 10:10     ` bhe
2014-07-28  8:20 ` [Patch v3 6/7] implement a function to print the memory usage Baoquan He
2014-07-28  8:20 ` [Patch v3 7/7] add a new interface to show the memory usage of 1st kernel Baoquan He
2014-07-29 12:43   ` Vivek Goyal
2014-07-31  2:32     ` Baoquan He
2014-08-01  7:12   ` Atsushi Kumagai
2014-08-12 10:14     ` bhe
2014-08-21 10:31     ` bhe
2014-08-26  2:28       ` Atsushi Kumagai
2014-08-26  3:22         ` bhe [this message]
2014-08-26  6:25           ` Petr Tesarik
2014-08-26 14:12             ` bhe
2014-09-02  6:20               ` Atsushi Kumagai

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=20140826032247.GA6230@dhcp-16-105.nay.redhat.com \
    --to=bhe@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=kumagai-atsushi@mxc.nes.nec.co.jp \
    --cc=vgoyal@redhat.com \
    /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