On Thu, Oct 24, 2013 at 4:01 AM, WANG Chao <chaow...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
