Subject : kexec/kdump kernel fails to start Submitter : Flavio Leitner <fbl@redhat.com> Date : Tue, 4 Sep 2012 14:32:15 -0300 Message-ID : <20120904143215.5bbbb2a4@obelix.rh> References : https://lkml.org/lkml/2012/9/4/276 Hi folks, I have system that no longer boots kdump kernel. Basically, # echo c > /proc/sysrq-trigger to dump a vmcore doesn't work. It just hangs after showing the usual panic messages. I've bisected the problem and the commit introducing the issue is the one below. Any idea? commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8 Author: WANG Cong <xiyou.wangcong@gmail.com> 2012-03-05 20:05:13 Committer: Ingo Molnar <mingo@elte.hu> 2012-03-06 05:38:26 Parent: 550cf00dbc8ee402bef71628cb71246493dd4500 (Merge tag 'mmc-fixes-for-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Child: a6fca40f1d7f3e232c9de27c1cebbb9f787fbc4f (x86, tlb: Switch cr3 in leave_mm() only when needed) Branches: master, remotes/origin/master Follows: v3.3-rc6 Precedes: v3.5-rc1 x86/mm: Fix the size calculation of mapping tables For machines that enable PSE, the first 2/4M memory region still uses 4K pages, so needs more PTEs in this case, but find_early_table_space() doesn't count this. This patch fixes it. The bug was found via code review, no misbehavior of the kernel was observed. Machine details: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping : 5 microcode : 0x11 cpu MHz : 1596.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 5333.87 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: # free total used free shared buffers cached Mem: 16161684 11749100 4412584 0 10212 11421096 -/+ buffers/cache: 317792 15843892 Swap: 17406420 0 17406420 dmesg is attached. thanks, fbl
If this is still seen with modern kernels please update