Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755875Ab0DWGnW (ORCPT ); Fri, 23 Apr 2010 02:43:22 -0400 Received: from ey-out-2122.google.com ([74.125.78.26]:45670 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750820Ab0DWGnV convert rfc822-to-8bit (ORCPT ); Fri, 23 Apr 2010 02:43:21 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding; b=KJcJYdIy2E3ID/NS1khvrnrj/I3AL12pFnzZghRCmBWEQ6lFO/39awjPob45Mzu7p/ 2NOZcATGb1UHRlOsS2uvc5ff27MDPACXHSZ6X4CyQpG8if+sAIAjHEryuHRre1UjGgch jKPVAL2KlPd//QyNYsJ8bBERXK/FzP+y4WiXM= Date: Fri, 23 Apr 2010 08:43:17 +0200 Message-ID: <87zl0u654q.wl%vmayatsk@redhat.com> From: Vitaly Mayatskikh To: ebiederm@xmission.com (Eric W. Biederman) Cc: Cong Wang , Vivek Goyal , Vitaly Mayatskikh , linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Haren Myneni , Neil Horman , kexec@lists.infradead.org Subject: Re: [PATCH 0/5] Add second memory region for crash kernel In-Reply-To: References: <1271953392-6324-1-git-send-email-v.mayatskih@gmail.com> <20100422224525.GJ3228@redhat.com> <4BD12E48.3080400@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/23.1 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 956 Lines: 27 At Thu, 22 Apr 2010 22:42:25 -0700, Eric W. Biederman wrote: > > We have observed that on a machine which has 66G memory, when we do > > crashkernel=1G@4G, kexec failed to load the crash kernel, but the memory > > reservation _did_ succeed. > > Did you try loading vmlinux? If not this sounds like the fact that > /sbin/kexec doesn't realize it can boot a 64bit bzImage in 64bit > mode. /sbin/kexec currently has hardcoded limitations for bzImage and initrd: include/x86/x86-linux.h: #define DEFAULT_INITRD_ADDR_MAX 0x37FFFFFF #define DEFAULT_BZIMAGE_ADDR_MAX 0x37FFFFFF This is easy to override. However, purgatory code still wants to see kernel below 2 Gb (32-bit signed relocations). -- wbr, Vitaly -- 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/