[PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then MAXMEM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 24, 2013 at 4:01 AM, WANG Chao <chaowang at redhat.com> 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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux