public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v26 0/7] arm64: add kdump support
Date: Tue, 4 Oct 2016 11:18:33 +0100	[thread overview]
Message-ID: <20161004101833.GB18083@leverpostej> (raw)
In-Reply-To: <1ae717d6-b2aa-105b-4f47-d879882ca5d3@caviumnetworks.com>

On Mon, Oct 03, 2016 at 06:11:40PM +0530, Manish Jaggi wrote:
> On 10/03/2016 04:34 PM, AKASHI Takahiro wrote:
> > On Mon, Oct 03, 2016 at 01:24:34PM +0530, Manish Jaggi wrote:
> >> Observations:
> >> 1.1. Dump capture kernel shows different memory map.
> >> ---------------------------------------------------
> >> In dump capture kernel /proc/meminfo and /proc/iomem differ
> >>
> >> root at arm64:/home/ubuntu/CODE/crash#
> >> MemTotal:       65882432 kB
> >> MemFree:        65507136 kB
> >> MemAvailable:   60373632 kB
> >> Buffers:           29248 kB
> >> Cached:            46720 kB
> >> SwapCached:            0 kB
> >> Active:            63872 kB
> >> Inactive:          19776 kB
> >> Active(anon):       8256 kB
> >> Inactive(anon):     7616 kB
> >>
> >> First kernel is booted with mem=2G crashkernel=1G command line option.
> >> While the system has 64G memory.
> >>
> >> root at arm64:/home/ubuntu/CODE/crash# cat /proc/iomem
> >> 41400000-fffeffff : System RAM
> >>   41480000-420cffff : Kernel code
> >>   42490000-4278ffff : Kernel data
> >> ffff0000-ffffffff : reserved
> >> 100000000-ffaa7ffff : System RAM
> >> ffaa80000-ffaabffff : reserved
> >> ffaac0000-fffa6ffff : System RAM
> >> fffa70000-fffacffff : reserved
> >> fffad0000-fffffffff : System RAM
> > 
> > Are you saying that "mem=..." doesn't have any effect?
> What I am saying it that If the first kernel is booted using mem= option and crashkernel= option
> the memory for second kernel has to be withing the crashkernel size.

Please don't try to use mem= to limit the kernel to a specific range of
memory. It's really only there as a tool to test handling of low-memory
situations. 

While it guarantees that at most, the amount requested will be used
(modulo a number of edge cases with reserved memory ranges), it does not
guarantee *which* memory will be used. It is *very* fragile.

Thanks,
Mark.

  parent reply	other threads:[~2016-10-04 10:18 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-07  4:29 [PATCH v26 0/7] arm64: add kdump support AKASHI Takahiro
2016-09-07  4:29 ` [PATCH v26 1/7] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2016-09-22 10:23   ` Matthias Bruger
2016-09-23  8:37     ` AKASHI Takahiro
2016-09-07  4:29 ` [PATCH v26 2/7] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2016-09-14 18:09   ` James Morse
2016-09-15  8:13     ` Marc Zyngier
2016-09-16  3:21     ` AKASHI Takahiro
2016-09-16 14:49       ` James Morse
2016-09-20  7:36         ` AKASHI Takahiro
2016-09-07  4:29 ` [PATCH v26 3/7] arm64: kdump: add kdump support AKASHI Takahiro
2016-09-16 14:50   ` James Morse
2016-09-20  7:46     ` AKASHI Takahiro
2016-09-22 15:50   ` Matthias Brugger
2016-09-07  4:29 ` [PATCH v26 4/7] arm64: kdump: add VMCOREINFO's for user-space coredump tools AKASHI Takahiro
2016-09-16 16:04   ` James Morse
2016-09-07  4:29 ` [PATCH v26 5/7] arm64: kdump: enable kdump in the arm64 defconfig AKASHI Takahiro
2016-09-07  4:29 ` [PATCH v26 6/7] arm64: kdump: update a kernel doc AKASHI Takahiro
2016-09-16 16:08   ` James Morse
2016-09-20  8:27     ` AKASHI Takahiro
2016-09-26 17:21     ` Matthias Brugger
2016-09-07  4:32 ` [PATCH v26 7/7] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
2016-09-16 13:03   ` Rob Herring
2016-09-07  4:37 ` [PATCH v26 0/7] arm64: add kdump support AKASHI Takahiro
2016-09-16 16:04 ` James Morse
2016-09-16 20:17   ` Ard Biesheuvel
2016-09-19 16:05     ` James Morse
2016-09-19 16:10       ` Ard Biesheuvel
2016-09-21  7:42       ` AKASHI Takahiro
2016-09-21  7:33   ` AKASHI Takahiro
2016-10-03  7:54 ` Manish Jaggi
2016-10-03 11:04   ` AKASHI Takahiro
2016-10-03 12:41     ` Manish Jaggi
2016-10-04  2:56       ` AKASHI Takahiro
2016-10-04  9:46       ` James Morse
2016-10-04 10:05         ` Manish Jaggi
2016-10-04 10:53           ` James Morse
2016-10-04 13:23             ` Manish Jaggi
2016-10-05  5:48               ` AKASHI Takahiro
2016-10-05  5:41         ` AKASHI Takahiro
2016-10-04 10:18       ` Mark Rutland [this message]
2016-10-17 15:41 ` Ruslan Bilovol
2016-10-18  6:26   ` AKASHI Takahiro
2016-11-01 12:19     ` Ruslan Bilovol

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=20161004101833.GB18083@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox