Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261625AbVASHy4 (ORCPT ); Wed, 19 Jan 2005 02:54:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261650AbVASHxu (ORCPT ); Wed, 19 Jan 2005 02:53:50 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:51391 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S261625AbVASHdT (ORCPT ); Wed, 19 Jan 2005 02:33:19 -0500 From: "Eric W. Biederman" To: Andrew Morton Cc: , Subject: [PATCH 20/29] x86_64-crashkernel Date: Wed, 19 Jan 2005 0:31:37 -0700 Message-ID: X-Mailer: patch-bomb.pl@ebiederm.dsl.xmission.com In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3322 Lines: 99 This is the x86_64 implementation of the crashkernel option. It reserves a window of memory very early in the bootup process, so we never use it for anything but the kernel to switch to when the running kernel panics. In addition to reserving this memory a resource structure is registered so looking at /proc/iomem it is clear what happened to that memory. ISSUES: Is it possible to implement this in a architecture generic way? What should be done with architectures that always use an iommu and thus don't report their RAM memory resources in /proc/iomem? Signed-off-by: Eric Biederman --- e820.c | 4 ++++ setup.c | 27 +++++++++++++++++++++++++++ 2 files changed, 31 insertions(+) diff -uNr linux-2.6.11-rc1-mm1-nokexec-x86_64-kexec/arch/x86_64/kernel/e820.c linux-2.6.11-rc1-mm1-nokexec-x86_64-crashkernel/arch/x86_64/kernel/e820.c --- linux-2.6.11-rc1-mm1-nokexec-x86_64-kexec/arch/x86_64/kernel/e820.c Tue Jan 18 22:44:10 2005 +++ linux-2.6.11-rc1-mm1-nokexec-x86_64-crashkernel/arch/x86_64/kernel/e820.c Tue Jan 18 23:14:34 2005 @@ -10,6 +10,7 @@ #include #include #include +#include #include #include #include @@ -204,6 +205,9 @@ */ request_resource(res, &code_resource); request_resource(res, &data_resource); +#ifdef CONFIG_KEXEC + request_resource(res, &crashk_res); +#endif } } } diff -uNr linux-2.6.11-rc1-mm1-nokexec-x86_64-kexec/arch/x86_64/kernel/setup.c linux-2.6.11-rc1-mm1-nokexec-x86_64-crashkernel/arch/x86_64/kernel/setup.c --- linux-2.6.11-rc1-mm1-nokexec-x86_64-kexec/arch/x86_64/kernel/setup.c Fri Jan 14 04:32:23 2005 +++ linux-2.6.11-rc1-mm1-nokexec-x86_64-crashkernel/arch/x86_64/kernel/setup.c Tue Jan 18 23:14:34 2005 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -321,6 +322,27 @@ if (!memcmp(from, "noexec=", 7)) nonx_setup(from + 7); +#ifdef CONFIG_KEXEC + /* crashkernel=size@addr specifies the location to reserve for + * a crash kernel. By reserving this memory we guarantee + * that linux never set's it up as a DMA target. + * Useful for holding code to do something appropriate + * after a kernel panic. + */ + else if (!memcmp(from, "crashkernel=", 12)) { + unsigned long size, base; + size = memparse(from+12, &from); + if (*from == '@') { + base = memparse(from+1, &from); + /* FIXME: Do I want a sanity check + * to validate the memory range? + */ + crashk_res.start = base; + crashk_res.end = base + size - 1; + } + } +#endif + next_char: c = *(from++); if (!c) @@ -574,6 +596,11 @@ (unsigned long)(end_pfn << PAGE_SHIFT)); initrd_start = 0; } + } +#endif +#ifdef CONFIG_KEXEC + if (crashk_res.start != crashk_res.end) { + reserve_bootmem(crashk_res.start, crashk_res.end - crashk_res.start + 1); } #endif paging_init(); - 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/