From: ebiederm@xmission.com (Eric W. Biederman)
To: Cliff Wickman <cpw@sgi.com>
Cc: kexec@lists.infradead.org
Subject: Re: 896MB address limit
Date: Tue, 25 Sep 2012 08:10:04 -0700 [thread overview]
Message-ID: <871uhqnnoz.fsf@xmission.com> (raw)
In-Reply-To: <20120925141834.GA6184@sgi.com> (Cliff Wickman's message of "Tue, 25 Sep 2012 09:18:34 -0500")
Cliff Wickman <cpw@sgi.com> writes:
> Hi Eric, and all,
>
> On Mon, Sep 24, 2012 at 08:11:12PM -0700, Eric W. Biederman wrote:
>> Cliff Wickman <cpw@sgi.com> writes:
>>
>> > Gentlemen,
>> >
>> > In dumping very large memories we are running up against the 896MB
>> > limit in SLES11SP2 (3.0.38 kernel).
>>
>> Odd. That limit should be the maximum address in memory to load the
>> crash kernel. Tha limit should have nothing to do with the dump process
>> itself.
>>
>> Are you saying you need more that 512MiB reserved for the crash kernel
>> to be able to dump all of the memory in your system?
>>
>> Eric
>
> As I noted to Eric privately, yes we need to bump up to crashkernel=1G
> or more for some very large memories.
>
> As an experiment I bumped
> +++ linux/arch/x86/kernel/setup.c
> @@ -528,7 +528,7 @@ static inline unsigned long long get_tot
> #ifdef CONFIG_X86_32
> # define CRASH_KERNEL_ADDR_MAX (512 << 20)
> #else
> -# define CRASH_KERNEL_ADDR_MAX (896 << 20)
> +# define CRASH_KERNEL_ADDR_MAX (1700 << 20)
>
> And that seems to work. i.e. I'm currently dumping a system where
> crashkernel=1G and it seems to be working.
>
> Am I just living dangerously?
So fundamentally this should work. However there have been a lot of
kinks and silly limitations in the x86 boot protocol.
So it used to be that the bootloader protocol variable ramdisk_max was
set to 896M for 32bit kernels. Because the ramdisk could not be located
in high memory.
Looking today it appears that ramdisk_max has been upped to 4G.
I will let you look through the /sbin/kexec source code.
As for testing I would up the limit to 4G on x86_64 and see how far
you get.
The practical question does the system still work with crashkernel=32M
when you have raised the limit much higher.
So I would test with crashkernel=1G@2G and see if that works. If that
works I figure that in practice all of the bugs are historical and we
can forget them. But a sweep through the /sbin/kexec code for the magic
number 896 might not be out of order.
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-09-25 15:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-24 23:07 896MB address limit Cliff Wickman
2012-09-25 3:11 ` Eric W. Biederman
2012-09-25 14:18 ` Cliff Wickman
2012-09-25 15:10 ` Eric W. Biederman [this message]
2012-09-25 15:57 ` Maxim Uvarov
2012-09-25 15:58 ` Maxim Uvarov
2012-09-27 23:07 ` Cliff Wickman
2012-09-25 17:38 ` Vivek Goyal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871uhqnnoz.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=cpw@sgi.com \
--cc=kexec@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox