On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao <chaow...@redhat.com> wrote: > Hi, Kees > > When I'm testing kaslr with kdump, I find that when 2nd kernel is loaded > high, it doesn't boot. > > I reserved 128M memory at high with kernel cmdline > "crashkernel=128M,high crashkernel=0,low", and for which I got: > > [ 0.000000] Reserving 128MB of memory at 6896MB for crashkernel (System > RAM: 6013MB) > > Then I load kdump kernel into the reserved memory region, using a local > modified kexec-tools which is passing e820 in boot_params. > > The e820 map of system RAM passed to 2nd kernel: > > E820 memmap (of RAM): > 0000000000001000-000000000009e3ff (1) > 00000001af000000-00000001b6f5dfff (1) > 00000001b6fff400-00000001b6ffffff (1) > > In which, 2nd kernel is loaded at 0x1b5000000. > > After triggerred a system crash, 2nd kernel doesn't boot even with > "nokaslr" cmdline: > > # echo c > /proc/sysrq-trigger > [..] > > I'm in purgatory > early console in decompress_kernel > KASLR disabled... > > Decompressing Linux... Parsing ELF... Performing relocations... > > 32-bit relocation outside of kernel!
Interesting, when kernel get at "early console in decompress_kernel" kernel already in 64 bit... what does it mean "32-bit relocation outside of kernel" ? why 32-bit is involved ? 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/