Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754530AbYHYPM0 (ORCPT ); Mon, 25 Aug 2008 11:12:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752931AbYHYPMQ (ORCPT ); Mon, 25 Aug 2008 11:12:16 -0400 Received: from mx1.redhat.com ([66.187.233.31]:56994 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752740AbYHYPMQ (ORCPT ); Mon, 25 Aug 2008 11:12:16 -0400 Date: Mon, 25 Aug 2008 10:19:01 -0400 From: Vivek Goyal To: Yinghai Lu Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , linux-kernel@vger.kernel.org, Bernhard Walle , "Eric W. Biederman" Subject: Re: [PATCH] x86: only put e820 ram entries in resource tree Message-ID: <20080825141901.GE18914@redhat.com> References: <1219617897-9870-1-git-send-email-yhlu.kernel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1219617897-9870-1-git-send-email-yhlu.kernel@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1614 Lines: 42 On Sun, Aug 24, 2008 at 03:44:57PM -0700, Yinghai Lu wrote: > may need user to have new kexec tools that could create e820 table > from /sys/firmware/memmap instead of /proc/iomem for second kernel > > Signed-off-by: Yinghai Lu > Cc: Bernhard Walle > Cc: Vivek Goyal > Cc: "Eric W. Biederman" > > Index: linux-2.6/arch/x86/kernel/e820.c > =================================================================== > --- linux-2.6.orig/arch/x86/kernel/e820.c > +++ linux-2.6/arch/x86/kernel/e820.c > @@ -1279,6 +1279,10 @@ void __init e820_reserve_resources(void) > > res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map); > for (i = 0; i < e820.nr_map; i++) { > + if (e820.map[i].type != E820_RAM) { > + res++; > + continue; > + } > end = e820.map[i].addr + e820.map[i].size - 1; > #ifndef CONFIG_RESOURCES_64BIT > if (end > 0x100000000ULL) { I think this will wipe out ACPI related entries also from /proc/iomem and kdump will be broken as second kernel needs to know about the ACPI areas. Though, if all these entries are available in /sys/firmware/memap then probably one can modify kexec-tools to grep RAM entries from /proc/iomem and rest of the entries from /sys/firmware/memmap. I would not prefer doing that it makes the logic twisted. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/