Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896Mfirst, then try below 4G, then MAXMEM
From: Yinghai Lu
Date: Thu Oct 24 2013 - 15:13:45 EST
On Thu, Oct 24, 2013 at 4:01 AM, WANG Chao <chaowang@xxxxxxxxxx> wrote:
>
> I think crashkernel=XM,high is really supposed to be used when user indeed
> want to reserve from high.
No. Keep the all 64bit to stay high, make thing simple.
instead of some low and some use high.
>
> Like Vivek said, failing at different point shouldn't be a problem.
> That's an incorrect configuration. When crashkernel=1G,high, old
> kexec-tools still fails the same way. That could cause confusion, in
> your word.
If it would fail later, we should let it fail early as possible.
>
> Let me put it in an example, a user want to utilize this new kernel
> feature to reserve 1G for crash kernel but not upgrade kexec-tools,
>
> - W/o this patch:
> First he would try crashkernel=1G, but failed to reserve. Second time,
> he goes with crashkernel=1G,high, reservation is fine but kexec fails
> to load. Upgrading kexec-tools is essential to him.
>
> - W/ this patch:
> First he would try crashkernel=1G, reservation is ok but kexec fails
> to load the same way as the case of crashkernel=1G,high. Upgrading
> kexec-tools is essential to him.
>
> The point is old kexec-tools can't load high, no matter by what kind of
> crashkernel cmdline to reserve at high.
old kexec-tools could work cross 892M in some case.
That will confuse the user, as it works some time on some setup, but does
not work on other setup.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/