All of lore.kernel.org
 help / color / mirror / Atom feed
From: Louis Bouchard <louis.bouchard@canonical.com>
To: Atsushi Kumagai <ats-kumagai@wm.jp.nec.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: makedumpfile issues many readpage_elf: Attempt to read non-existent page
Date: Thu, 29 Sep 2016 15:34:53 +0200	[thread overview]
Message-ID: <57ED187D.3040007@canonical.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9701E6B42E@BPXM01GP.gisp.nec.co.jp>

Hello,

Le 23/09/2016 14:04, Atsushi Kumagai a écrit :
>> Does someone have an idea of where this could come from ?
> 
> Thanks for your report, but I'm afraid that I'm going on
> vacation till Oct 2.
> I hope someone helps you until I'm back.
> 
> 
> Regards,
> Atsushi Kumagai
> 

As a follow up to my question, I've been investigating the issue. The source of
the problem seems to come from readpage_elf() which tries to read to an
inexistant page :

readpage_elf: Attempt to read non-existent page at 0x1a7b7fff5000.

The error happens when readpage_elf() is called from section_mem_map_addr with
pgaddr, which is derived from paddr. This one comes from :

   paddr = vaddr_to_paddr(addr)

When tracing vaddr_to_paddr, I see a difference in the calculation. on a 4.4
kernel :

  info->phys_base = 0

On 4.8 :
  info->phys_base = 0xffffffffe3800000

So the paddr values used to define pgaddr are :

for 4.4 kernels : 0x3fff4000
for 4.8 kernels : 0x1a7b7fff5000

Running makedumpfile --dump-dmesg in debug mode leads to :

4.4 kernel :

sadump: does not have partition header
sadump: read dump device as unknown format
sadump: unknown format
LOAD (0)
  phys_start : 1000000
  phys_end   : 2224000
  virt_start : ffffffff81000000
  virt_end   : ffffffff82224000
LOAD (1)
  phys_start : 1000
  phys_end   : 9fc00
  virt_start : ffff880000001000
  virt_end   : ffff88000009fc00
LOAD (2)
  phys_start : 100000
  phys_end   : 2b000000
  virt_start : ffff880000100000
  virt_end   : ffff88002b000000
LOAD (3)
  phys_start : 33000000
  phys_end   : 3fffe000
  virt_start : ffff880033000000
  virt_end   : ffff88003fffe000
Linux kdump
page_size    : 4096

max_mapnr    : 3fffe

Buffer size for the cyclic mode: 65535

num of NODEs : 1


Memory type  : SPARSEMEM_EX

mem_map (0)
  mem_map    : ffffea0000000000
  pfn_start  : 0
  pfn_end    : 8000
mem_map (1)
  mem_map    : ffffea0000200000
  pfn_start  : 8000
  pfn_end    : 10000
mem_map (2)
  mem_map    : ffffea0000400000
  pfn_start  : 10000
  pfn_end    : 18000
mem_map (3)
  mem_map    : ffffea0000600000
  pfn_start  : 18000
  pfn_end    : 20000
mem_map (4)
  mem_map    : ffffea0000800000
  pfn_start  : 20000
  pfn_end    : 28000
mem_map (5)
  mem_map    : ffffea0000a00000
  pfn_start  : 28000
  pfn_end    : 30000
mem_map (6)
  mem_map    : ffffea0000c00000
  pfn_start  : 30000
  pfn_end    : 38000
mem_map (7)
  mem_map    : ffffea0000e00000
  pfn_start  : 38000
  pfn_end    : 3fffe
mmap() is available on the kernel.

log_buf       : ffffffff8210521c
log_end       : 0
log_buf_len   : 262144
log_first_idx : 0
log_next_idx  : 141176

The dmesg log is saved to /tmp/titi.

makedumpfile Completed.


For 4.8 kernels :
sadump: does not have partition header
sadump: read dump device as unknown format
sadump: unknown format
LOAD (0)
  phys_start : 7200000
  phys_end   : 847d000
  virt_start : ffffffffa3a00000
  virt_end   : ffffffffa4c7d000
LOAD (1)
  phys_start : 1000
  phys_end   : 9fc00
  virt_start : ffff880000001000
  virt_end   : ffff88000009fc00
LOAD (2)
  phys_start : 100000
  phys_end   : 2b000000
  virt_start : ffff880000100000
  virt_end   : ffff88002b000000
LOAD (3)
  phys_start : 33000000
  phys_end   : 3fffe000
  virt_start : ffff880033000000
  virt_end   : ffff88003fffe000
Linux kdump
page_size    : 4096

max_mapnr    : 3fffe

Buffer size for the cyclic mode: 65535
The kernel version is not supported.
The makedumpfile operation may be incomplete.

num of NODEs : 1


Memory type  : SPARSEMEM_EX

mem_map (0)
  mem_map    : 0
  pfn_start  : 0
  pfn_end    : 8000
mem_map (1)
  mem_map    : 0
  pfn_start  : 8000
  pfn_end    : 10000
mem_map (2)
  mem_map    : 0
  pfn_start  : 10000
  pfn_end    : 18000
mem_map (3)
  mem_map    : 0
  pfn_start  : 18000
  pfn_end    : 20000
mem_map (4)
  mem_map    : 0
  pfn_start  : 20000
  pfn_end    : 28000
mem_map (5)
  mem_map    : 0
  pfn_start  : 28000
  pfn_end    : 30000
mem_map (6)
  mem_map    : 0
  pfn_start  : 30000
  pfn_end    : 38000
mem_map (7)
  mem_map    : 0
  pfn_start  : 38000
  pfn_end    : 3fffe
mmap() is available on the kernel.

log_buf       : ffffffffa4b3c19c
log_end       : 0
log_buf_len   : 262144
log_first_idx : 0
log_next_idx  : 43160

The dmesg log is saved to /tmp/toto.

makedumpfile Completed.


I don't know if it is to be expected with kernels 4.8 to have all mem_map
addresses set to 0, unlike with k4.4 :

mem_map (0)
mem_map : 0
pfn_start : 0
pfn_end : 8000

Any comment appreciated while I continue to investigate.

Kind regards,

...Louis

-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer                       Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

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

  reply	other threads:[~2016-09-29 13:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-22 13:30 makedumpfile issues many readpage_elf: Attempt to read non-existent page Louis Bouchard
2016-09-23 12:04 ` Atsushi Kumagai
2016-09-29 13:34   ` Louis Bouchard [this message]
2016-10-24 14:54     ` Louis Bouchard
2016-10-25  8:59       ` Louis Bouchard
2016-10-25  9:19         ` 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=57ED187D.3040007@canonical.com \
    --to=louis.bouchard@canonical.com \
    --cc=ats-kumagai@wm.jp.nec.com \
    --cc=kexec@lists.infradead.org \
    /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.