Add second memory region for crash kernel
in [Kernel]
|
From: Cong Wang on 23 Apr 2010 01:20 Eric W. Biederman wrote: > Vivek Goyal <vgoyal(a)redhat.com> writes: > >> Vitaly, have you really run into cases where 2G upper limit is a concern. >> What is the configuration you have, how much memory it has and how much >> memory are you planning to reserve for kdump kernel? > > A good question. > We have observed that on a machine which has 66G memory, when we do crashkernel=1G(a)4G, kexec failed to load the crash kernel, but the memory reservation _did_ succeed. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 23 Apr 2010 01:50 Cong Wang <amwang(a)redhat.com> writes: > Eric W. Biederman wrote: >> Vivek Goyal <vgoyal(a)redhat.com> writes: >> >>> Vitaly, have you really run into cases where 2G upper limit is a concern. >>> What is the configuration you have, how much memory it has and how much >>> memory are you planning to reserve for kdump kernel? >> >> A good question. >> > > We have observed that on a machine which has 66G memory, when we do > crashkernel=1G(a)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. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Vitaly Mayatskikh on 23 Apr 2010 02:50 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(a)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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Vitaly Mayatskikh on 23 Apr 2010 03:10 At Thu, 22 Apr 2010 18:45:25 -0400, Vivek Goyal wrote: > Vitaly, have you really run into cases where 2G upper limit is a concern. > What is the configuration you have, how much memory it has and how much > memory are you planning to reserve for kdump kernel? I tried it on system with 96G of RAM. When I reserved 512M for kdump kernel, system stopped loading somewhere in user space. With larger reserved area /sbin/kexec can't load kernel (because of hardcoded limitation in /sbin/kexec). After removing this limitation kernel was loaded below 2G, but system even hasn't booted. Unfortunately, I don't remember exact details now and have no access to that machine temporarily. Will try to get access and come back with details. -- wbr, Vitaly -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Pages: 1 2 Prev: CONTACT ME VIA/WILLIAMWILCOX1943@HOTMAIL.COM Next: [GIT PATCH] USB fixes for 2.6.34-git |