From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WECJ2-0007Ck-3r for kexec@lists.infradead.org; Fri, 14 Feb 2014 06:31:25 +0000 Date: Fri, 14 Feb 2014 14:30:57 +0800 From: WANG Chao Subject: Re: [PATCH 2/4] x86: Store memory ranges globally used for crash kernel to boot into Message-ID: <20140214063057.GC18964@dhcp-17-89.nay.redhat.com> References: <1392297055-31934-1-git-send-email-chaowang@redhat.com> <1392297055-31934-3-git-send-email-chaowang@redhat.com> <20140213214619.GL30844@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140213214619.GL30844@redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Vivek Goyal Cc: kexec@lists.infradead.org, cpw@sgi.com, horms@verge.net.au, ebiederm@xmission.com, hpa@zytor.com, dyoung@redhat.com, trenn@suse.de On 02/13/14 at 04:46pm, Vivek Goyal wrote: > On Thu, Feb 13, 2014 at 09:10:53PM +0800, WANG Chao wrote: > > [..] > > @@ -230,6 +231,8 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges, > > /* Only Dumping memory of type System RAM. */ > > if (memcmp(str, "System RAM\n", 11) == 0) { > > type = RANGE_RAM; > > + } else if (memcmp(str, "reserved\n", 9) == 0) { > > + type = RANGE_RESERVED; > > Hi Chao, > > Can we take up the issue of passing reserved ranges to second kernel in > a separate patchset. I had noticed higher memory usage due to that and > it might have been something else. OK. That can be done later. > > It might be easier to handle one thing at a time. Let us first start > passing the memory range we pass on command line through bootparams and > once that gets merged and stablizes, write a patchset to start passing > reserved memory ranges if need be. Cliff once sent a patch to pass reserved range to 2nd kernel (reverted eventually due to its dependency on another patch which needed to revert). In the patch he mentioned that some devices (PCI>0) on UV2 would fail without passing reserved range: http://lists.infradead.org/pipermail/kexec/2013-February/007924.html I don't dive into this issue. However I think as long as these reserved ranges are provided by the firmware, it could be useful in 2nd kernel, at least potentially. Anyway this reserved ranges issue could be addressed later. I'll cut it out in next update. Thanks WANG Chao _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec