From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756812Ab3BUSWE (ORCPT ); Thu, 21 Feb 2013 13:22:04 -0500 Received: from mail-vb0-f42.google.com ([209.85.212.42]:37464 "EHLO mail-vb0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755908Ab3BUSVs (ORCPT ); Thu, 21 Feb 2013 13:21:48 -0500 MIME-Version: 1.0 In-Reply-To: <51242908.2050308@huawei.com> References: <51074786.5030007@huawei.com> <1359995565.7515.178.camel@mfleming-mobl1.ger.corp.intel.com> <51131248.3080203@huawei.com> <5113450C.1080109@huawei.com> <51242908.2050308@huawei.com> Date: Thu, 21 Feb 2013 10:21:46 -0800 Message-ID: Subject: Re: [PATCH V3] ia64/mm: fix a bad_page bug when crash kernel booting From: Tony Luck To: Xishi Qiu Cc: Matt Fleming , fenghua.yu@intel.com, Liujiang , Andrew Morton , linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, Hanjun Guo , WuJianguo , linux-arch@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 19, 2013 at 5:38 PM, Xishi Qiu wrote: > Seems like a good idea, should we modify "\linux\Documentation\kernel-parameters.txt"? Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry in kernel-parameters.txt points at). The ia64 section of kdump.txt notes that the start address will be rounded up to a GRANULE boundary, but doesn't talk about restrictions on the size. I wonder if any other architectures have alignment restrictions on the addresses in "crashkernel" parameters? Does x86 like them to be 2MB aligned? Second question is whether we should check and warn in parse_crashkernel_mem()? I think the answer is "yes" (since the consequences of getting this wrong don't show up till much later, and the errors aren't all that obviously connected back to the original mistake). Perhaps each architecture that cares could provide defines: #define ARCH_CRASH_KERNEL_START_ALIGN (... arch value here ...) #define ARCH_CRASH_KERNEL_SIZE_ALIGN (... arch value here ...) [Suggestion provided mostly to provoke somebody to provide a more elegant solution] -Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Luck Subject: Re: [PATCH V3] ia64/mm: fix a bad_page bug when crash kernel booting Date: Thu, 21 Feb 2013 10:21:46 -0800 Message-ID: References: <51074786.5030007@huawei.com> <1359995565.7515.178.camel@mfleming-mobl1.ger.corp.intel.com> <51131248.3080203@huawei.com> <5113450C.1080109@huawei.com> <51242908.2050308@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: In-Reply-To: <51242908.2050308@huawei.com> Sender: owner-linux-mm@kvack.org To: Xishi Qiu Cc: Matt Fleming , fenghua.yu@intel.com, Liujiang , Andrew Morton , linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, Hanjun Guo , WuJianguo , linux-arch@vger.kernel.org List-Id: linux-efi@vger.kernel.org On Tue, Feb 19, 2013 at 5:38 PM, Xishi Qiu wrote: > Seems like a good idea, should we modify "\linux\Documentation\kernel-parameters.txt"? Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry in kernel-parameters.txt points at). The ia64 section of kdump.txt notes that the start address will be rounded up to a GRANULE boundary, but doesn't talk about restrictions on the size. I wonder if any other architectures have alignment restrictions on the addresses in "crashkernel" parameters? Does x86 like them to be 2MB aligned? Second question is whether we should check and warn in parse_crashkernel_mem()? I think the answer is "yes" (since the consequences of getting this wrong don't show up till much later, and the errors aren't all that obviously connected back to the original mistake). Perhaps each architecture that cares could provide defines: #define ARCH_CRASH_KERNEL_START_ALIGN (... arch value here ...) #define ARCH_CRASH_KERNEL_SIZE_ALIGN (... arch value here ...) [Suggestion provided mostly to provoke somebody to provide a more elegant solution] -Tony -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Luck Date: Thu, 21 Feb 2013 18:21:46 +0000 Subject: Re: [PATCH V3] ia64/mm: fix a bad_page bug when crash kernel booting Message-Id: List-Id: References: <51074786.5030007@huawei.com> <1359995565.7515.178.camel@mfleming-mobl1.ger.corp.intel.com> <51131248.3080203@huawei.com> <5113450C.1080109@huawei.com> <51242908.2050308@huawei.com> In-Reply-To: <51242908.2050308@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Xishi Qiu Cc: Matt Fleming , fenghua.yu@intel.com, Liujiang , Andrew Morton , linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, Hanjun Guo , WuJianguo , linux-arch@vger.kernel.org On Tue, Feb 19, 2013 at 5:38 PM, Xishi Qiu wrote: > Seems like a good idea, should we modify "\linux\Documentation\kernel-parameters.txt"? Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry in kernel-parameters.txt points at). The ia64 section of kdump.txt notes that the start address will be rounded up to a GRANULE boundary, but doesn't talk about restrictions on the size. I wonder if any other architectures have alignment restrictions on the addresses in "crashkernel" parameters? Does x86 like them to be 2MB aligned? Second question is whether we should check and warn in parse_crashkernel_mem()? I think the answer is "yes" (since the consequences of getting this wrong don't show up till much later, and the errors aren't all that obviously connected back to the original mistake). Perhaps each architecture that cares could provide defines: #define ARCH_CRASH_KERNEL_START_ALIGN (... arch value here ...) #define ARCH_CRASH_KERNEL_SIZE_ALIGN (... arch value here ...) [Suggestion provided mostly to provoke somebody to provide a more elegant solution] -Tony