On 09/27/2010 04:21 AM, caiqian at redhat.com wrote: > > ----- "CAI Qian" <caiqian at redhat.com> wrote: > >> ----- "Yinghai Lu" <yinghai at kernel.org> wrote: >> >>> Please check this one on top of tip or next. >> This failed for both trees. >> [root at localhost linux-next]# patch -Np1 <memblock.patch >> patching file arch/x86/kernel/setup.c >> Hunk #1 FAILED at 516. >> 1 out of 1 hunk FAILED -- saving rejects to file >> arch/x86/kernel/setup.c.rej > After manually applied the patch on the top of the latest mmotm tree, now there was no /proc/vmcore exported to the second kernel anymore. It could be the results of other recent commits in mmotm though. It said, > > Warning: Core image elf header is notsane > Kdump: vmcore not initialized > > Here is the dmesg from the second kernel, > > Initializing cgroup subsys cpuset > Linux version 2.6.36-rc5-mm1+ (root at localhost.localdomain) (gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) ) #6 SMP Mon Sep 27 07:00:15 EDT 2010 > Command line: ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet console=tty0 console=ttyS0,115200 crashkernel=128M irqpoll maxcpus=1 reset_devices cgroup_disable=memory memmap=exactmap memmap=640K at 0K memmap=130408K at 32768K elfcorehdr=163176K kexec_jump_back_entry=0x000000000232f063 > BIOS-provided physical RAM map: > BIOS-e820: 0000000000000100 - 000000000009f400 (usable) > BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) > BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) > BIOS-e820: 0000000000100000 - 00000000dfffb000 (usable) > BIOS-e820: 00000000dfffb000 - 00000000e0000000 (reserved) > BIOS-e820: 00000000fffbc000 - 0000000100000000 (reserved) > BIOS-e820: 0000000100000000 - 0000000ca0000000 (usable) > last_pfn = 0xca0000 max_arch_pfn = 0x400000000 > NX (Execute Disable) protection: active > user-defined physical RAM map: > user: 0000000000000000 - 00000000000a0000 (usable) > user: 0000000002000000 - 0000000009f5a000 (usable) ... > Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > Warning: Core image elf header is notsane > Kdump: vmcore not initialized > >> it should work on tip..., I tested on RHEL 6.0 beta. with /etc/init.d/kdump restart BTW, second kernel is not supposed to take crashkernel=128M again. /etc/init.d/kdump scripts remove that while using /proc/cmdline. please refer http://people.redhat.com/mingo/tip.git/readme.txt to get tip/master and apply attached patch cat crashkernel_limit.patch | patch -p1 Thanks Yinghai -------------- next part -------------- A non-text attachment was scrubbed... Name: crashkernel_limit.patch Type: text/x-patch Size: 2230 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/kexec/attachments/20100927/8771656b/attachment.bin>
