On 10/07/2010 11:18 AM, Vivek Goyal wrote: > > Ok, I was browsing through kexec-tools, x86 bzImage code and trying to > refresh my memory what segments were being loaded and what were memory > address concerns. > > - relocatable bzImage (max addr 0x37ffffff, 896MB). > Though I don't know/understand where that 896MB come from. > > - initrd (max addr 0x37ffffff, 896MB) > Don't know why 896MB as upper limit 896 MB is presumably the (default!!) LOWMEM limit on 32 bits. This is actually wrong if vmalloc= is also specified on command line, though, or with nonstandard compile-time options. > - Purgatory (max addr 2G) > > - A segment to keep elf headers (no limit) > These are accessed when second kernel as fully booted so can be > addressed in higher addresses. > > - A backup segment to copy first 640K of memory (not aware of any limit) > - Setup/parameter segment (no limit) > - We don't really execute anything here and just access it for > command line. Probably has a 4 GB limit, since I believe it only has a 32-bit pointer. > So atleast for bzImage it looks that if we specify crashkernel=128M<896M, it > will work. > > So I am fine with above additional syntax for crashkernel=. May be we shall > have to the deprecate the crashkernel=X<@0 syntax. > > CCing kexec list, in case others have any comments. It would be easy enough to either deprecate or make it an alias for crashkernel=...<896M, which is basically what Yinghai's patch does. -hpa
