Problem Description --------------------------------- Trying to force the system to generate dump by using sysrq-trigger on Fedora 18 rc2 installed system on P7 Lpar ,noticed system got rebooted & generated the vmcore ,But vmcore is not as expected size. Check out the size of vmcore just 12k , which is unexpected: [root@miz10 ~]# du -sh /var/crash/18.01.13-05\:47\:20/vmcore 12K /var/crash/18.01.13-05:47:20/vmcore [root@miz10 ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.6.10-4.fc18.ppc64p7 root=/dev/mapper/fedora_miz10-root ro rd.md=0 rd.dm=0 rd.lvm.lv=fedora_miz10/swap rd.luks=0 rd.lvm.lv=fedora_miz10/root rhgb quiet crashkernel=512M@64M [root@miz10 ~]# uname -a Linux miz10.austin.ibm.com 3.6.10-4.fc18.ppc64p7 #1 SMP Wed Dec 12 16:08:02 MST 2012 ppc64 ppc64 ppc64 GNU/Linux --- Consoel log --- [ 267.863733] SysRq : Trigger a crash [ 267.863753] Unable to handle kernel paging request for data at address 0x00000000 [ 267.863757] Faulting instruction address: 0xc000000000477b30 [ 267.863761] Oops: Kernel access of bad area, sig: 11 [#1] [ 267.863764] SMP NR_CPUS=1024 NUMA pSeries [ 267.863771] Modules linked in: bnep bluetooth rfkill ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_filter ebtables ip6table_filter ip6_tables uinput ibmveth ibmvscsic scsi_transport_srp scsi_tgt [ 267.863799] NIP: c000000000477b30 LR: c000000000478834 CTR: c000000000477b00 [ 267.863803] REGS: c0000000f334f7f0 TRAP: 0300 Not tainted (3.6.6-3.fc18.ppc64p7) [ 267.863806] MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 28222822 XER: 00000001 [ 267.863816] SOFTE: 0 [ 267.863818] CFAR: c000000000005280 [ 267.863820] DAR: 0000000000000000, DSISR: 42000000 [ 267.863823] TASK = c0000000fa26d900[1055] 'echo-sysrq.sh' THREAD: c0000000f334c000 CPU: 5 GPR00: c000000000478834 c0000000f334fa70 c0000000012b3d98 0000000000000063 GPR04: 0000000000000000 c00000000146ece8 0000000000000010 0000000000000002 GPR08: 0000000000000001 0000000000000001 0000000000000000 c000000000b16c20 GPR12: 0000000048222822 c000000003ee1180 00000000101441a0 0000000000000000 GPR16: 0000000010142434 0000000010142438 00000000100e0c18 00000000ffffffff GPR20: 000000001013c660 0000000000000000 0000000000000000 0000000000000004 GPR24: 0000000000000000 0000000000000001 c000000001197940 c0000000015de748 GPR28: 0000000000000063 c000000001167480 c00000000123d930 c000000001197b58 [ 267.863875] NIP [c000000000477b30] .sysrq_handle_crash+0x30/0x50 [ 267.863879] LR [c000000000478834] .__handle_sysrq+0xf4/0x240 [ 267.863882] Call Trace: [ 267.863885] [c0000000f334fa70] [c0000000007d5298] .printk+0x80/0x98 (unreliable) [ 267.863890] [c0000000f334faf0] [c000000000478834] .__handle_sysrq+0xf4/0x240 [ 267.863895] [c0000000f334fbb0] [c000000000478a1c] .write_sysrq_trigger+0x9c/0xa0 [ 267.863900] [c0000000f334fc40] [c0000000002a4e5c] .proc_reg_write+0xbc/0x140 [ 267.863905] [c0000000f334fcf0] [c00000000021b104] .vfs_write+0xd4/0x200 [ 267.863909] [c0000000f334fd90] [c00000000021b56c] .SyS_write+0x5c/0xe0 [ 267.863914] [c0000000f334fe30] [c000000000009854] syscall_exit+0x0/0x94 [ 267.863917] Instruction dump: [ 267.863919] 7c0802a6 fbc1fff0 ebc2c950 f8010010 f821ff81 60000000 60000000 e95e8000 [ 267.863927] 39200001 912a0000 7c0004ac 39400000 <992a0000> 38210080 e8010010 ebc1fff0 [ 267.863936] ---[ end trace 824c205dcc366cb3 ]--- [ 267.865239] [ 267.865244] Sending IPI to other CPUs [ 267.866253] IPI complete I'm in purgatory [ 9.692480] sd 0:0:1:0: [sda] Assuming drive cache: write through [ 9.693059] sd 0:0:1:0: [sda] Assuming drive cache: write through [ 9.725057] sd 0:0:1:0: [sda] Assuming drive cache: write through dracut-pre-pivot[195]: ++ KDUMP_PATH=/var/crash dracut-pre-pivot[195]: ++ CORE_COLLECTOR= dracut-pre-pivot[195]: ++ DEFAULT_CORE_COLLECTOR='makedumpfile -c --message-level 1 -d 31' dracut-pre-pivot[195]: ++ DEFAULT_ACTION=dump_rootfs dracut-pre-pivot[195]: +++ date +%d.%m.%y-%T dracut-pre-pivot[195]: ++ DATEDIR=06.12.12-16:40:28 dracut-pre-pivot[195]: ++ DUMP_INSTRUCTION= dracut-pre-pivot[195]: ++ SSH_KEY_LOCATION=/root/.ssh/kdump_id_rsa dracut-pre-pivot[195]: ++ KDUMP_SCRIPT_DIR=/kdumpscripts dracut-pre-pivot[195]: ++ DD_BLKSIZE=512 dracut-pre-pivot[195]: ++ FINAL_ACTION='reboot -f' dracut-pre-pivot[195]: ++ DUMP_RETVAL=0 dracut-pre-pivot[195]: ++ conf_file=/etc/kdump.conf dracut-pre-pivot[195]: ++ KDUMP_PRE= dracut-pre-pivot[195]: ++ KDUMP_POST= dracut-pre-pivot[195]: ++ export PATH=/usr/sbin:/usr/bin:/sbin:/bin:/kdumpscripts dracut-pre-pivot[195]: ++ PATH=/usr/sbin:/usr/bin:/sbin:/bin:/kdumpscripts dracut-pre-pivot[195]: ++ read_kdump_conf dracut-pre-pivot[195]: ++ '[' '!' -f /etc/kdump.conf ']' dracut-pre-pivot[195]: ++ read config_opt config_val dracut-pre-pivot[195]: ++ case "$config_opt" in dracut-pre-pivot[195]: ++ read config_opt config_val dracut-pre-pivot[195]: ++ case "$config_opt" in dracut-pre-pivot[195]: ++ KDUMP_PATH=/var/crash dracut-pre-pivot[195]: ++ read config_opt config_val dracut-pre-pivot[195]: ++ read config_opt config_val dracut-pre-pivot[195]: ++ case "$config_opt" in dracut-pre-pivot[195]: ++ read config_opt config_val dracut-pre-pivot[195]: ++ case "$config_opt" in dracut-pre-pivot[195]: ++ read config_opt config_val dracut-pre-pivot[195]: ++ '[' -z '' ']' dracut-pre-pivot[195]: ++ CORE_COLLECTOR='makedumpfile -c --message-level 1 -d 31' dracut-pre-pivot[195]: ++ is_ssh_dump_target dracut-pre-pivot[195]: ++ grep -q '^ssh.*@' /etc/kdump.conf dracut-pre-pivot[195]: ++ is_raw_dump_target dracut-pre-pivot[195]: ++ grep -q '^raw' /etc/kdump.conf dracut-pre-pivot[195]: ++ '[' -z '' ']' dracut-pre-pivot[195]: ++ add_dump_code dump_rootfs dracut-pre-pivot[195]: ++ DUMP_INSTRUCTION=dump_rootfs dracut-pre-pivot[195]: ++ do_kdump_pre dracut-pre-pivot[195]: ++ '[' -n '' ']' dracut-pre-pivot[195]: ++ '[' 0 -ne 0 ']' dracut-pre-pivot[195]: ++ dump_rootfs dracut-pre-pivot[195]: ++ mount -o remount,rw /sysroot/ dracut-pre-pivot[195]: ++ mkdir -p /sysroot//var/crash/06.12.12-16:40:28 dracut-pre-pivot[195]: ++ makedumpfile -c --message-level 1 -d 31 /proc/vmcore /sysroot//var/crash/06.12.12-16:40:28/vmcore dracut-pre-pivot[195]: Excluding free pages : [ 0 %] ++ return 1 dracut-pre-pivot[195]: ++ DUMP_RETVAL=1 dracut-pre-pivot[195]: ++ do_kdump_post 1 dracut-pre-pivot[195]: ++ '[' -n '' ']' dracut-pre-pivot[195]: ++ '[' 0 -ne 0 ']' dracut-pre-pivot[195]: ++ '[' 1 -ne 0 ']' dracut-pre-pivot[195]: ++ do_default_action dracut-pre-pivot[195]: ++ wait_for_loginit dracut-pre-pivot[195]: ++ '[' no = yes ']' dracut-pre-pivot[195]: ++ return dracut-pre-pivot[195]: ++ dump_rootfs dracut-pre-pivot[195]: ++ mount -o remount,rw /sysroot/ dracut-pre-pivot[195]: ++ mkdir -p /sysroot//var/crash/06.12.12-16:40:28 dracut-pre-pivot[195]: ++ makedumpfile -c --message-level 1 -d 31 /proc/vmcore /sysroot//var/crash/18.01.13-05\:47\:20 dracut-pre-pivot[195]: Excluding free pages : [ 0 %] ++ return 1 dracut-pre-pivot[195]: ++ reboot -f dracut-pre-pivot[195]: Rebooting. [ 19.502581] Restarting system. [root@miz10 ~]# rpm -qa | grep -i kdump system-config-kdump-2.0.10-1.fc18.noarch [root@miz10 ~]# rpm -qa | grep -i kexec kexec-tools-2.0.3-58.fc18.ppc64 Thanks... Manas == Comment: #4 - MANAS K. NAYAK <maknayak.com> - 2013-01-29 23:49:32 == (In reply to comment #3) > Please check with the GA levels and all updates applied (yum update) This is still reproducible on GA build. I ran yum update prior to the test. [root@miz03 ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.7.2-204.fc18.ppc64 root=UUID=e6c3ea2d-17b1-48fb-bc21-4ef923157812 ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8 crashkernel=512M@64M Size of the vmcore generated only 36K. [root@miz03 /]# du -sh /var/crash/* 36K /var/crash/127.0.0.1-2013.01.30-04:30:00 [root@miz03 ~]# uname -a Linux miz03.xxx.xxx.xxx 3.7.2-204.fc18.ppc64 #1 SMP Fri Jan 18 10:44:51 MST 2013 ppc64 ppc64 ppc64 GNU/Linux --- log for /var/log/messages --- [ 179.674275] SysRq : Trigger a crash [ 179.674299] Unable to handle kernel paging request for data at address 0x00000000 [ 179.674305] Faulting instruction address: 0xc000000000495390 [ 179.674311] Oops: Kernel access of bad area, sig: 11 [#1] [ 179.674314] SMP NR_CPUS=1024 NUMA pSeries [ 179.674321] Modules linked in: bnep bluetooth rfkill windfarm_smu_sat i2c_core windfarm_pid ibmveth uinput dm_service_time ibmvscsi scsi_transport_srp scsi_tgt dm_multipath [ 179.674340] NIP: c000000000495390 LR: c000000000496094 CTR: c000000000495360 [ 179.674346] REGS: c0000000687037e0 TRAP: 0300 Not tainted (3.7.2-204.fc18.ppc64) [ 179.674349] MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 28222422 XER: 00000001 [ 179.674362] SOFTE: 0 [ 179.674364] CFAR: c000000000005400 [ 179.674367] DAR: 0000000000000000, DSISR: 42000000 [ 179.674370] TASK = c00000002a8b4ad0[6693] 'triggerdump.sh' THREAD: c000000068700000 CPU: 3 GPR00: c000000000496094 c000000068703a60 c000000001318448 0000000000000063 GPR04: 0000000000000000 c0000000014cf668 0000000000000010 0000000000000002 GPR08: 0000000000000001 0000000000000001 0000000000000000 c000000000b5cc30 GPR12: 0000000048222422 c000000003ee0a80 00000000101441a0 0000000000000000 GPR16: 0000000010142434 0000000010142438 00000000100e0c18 00000000ffffffff GPR20: 000000001013c660 0000000000000000 0000000000000000 0000000000000004 GPR24: 0000000000000000 0000000000000001 c0000000011f9250 c000000001642050 GPR28: 0000000000000063 c0000000011c7d00 c00000000129ecb8 c0000000011f9468 [ 179.674433] NIP [c000000000495390] .sysrq_handle_crash+0x30/0x50 [ 179.674438] LR [c000000000496094] .__handle_sysrq+0xf4/0x240 [ 179.674441] Call Trace: [ 179.674447] [c000000068703a60] [c00000000080633c] .printk+0x80/0x98 (unreliable) [ 179.674453] [c000000068703ae0] [c000000000496094] .__handle_sysrq+0xf4/0x240 [ 179.674459] [c000000068703ba0] [c00000000049627c] .write_sysrq_trigger+0x9c/0xa0 [ 179.674466] [c000000068703c30] [c0000000002bfb2c] .proc_reg_write+0xbc/0x140 [ 179.674472] [c000000068703ce0] [c0000000002333f4] .vfs_write+0xd4/0x200 [ 179.674477] [c000000068703d80] [c000000000233864] .SyS_write+0x64/0xe0 [ 179.674483] [c000000068703e30] [c0000000000098d4] syscall_exit+0x0/0x94 [ 179.674487] Instruction dump: [ 179.674490] 7c0802a6 fbc1fff0 ebc2cde8 f8010010 f821ff81 60000000 60000000 e95e8000 [ 179.674499] 39200001 912a0000 7c0004ac 39400000 <992a0000> 38210080 e8010010 ebc1fff0 [ 179.674511] ---[ end trace 30f82ea151b9669f ]--- [ 179.676166] [ 179.676173] Sending IPI to other CPUs [ 179.677183] IPI complete I'm in purgatory Thanks... Manas == Comment: #7 - MAHESH J. SALGAONKAR <mahesh.salgaonkar.com> - 2013-02-12 03:20:18 == The issue is makedumpfile fails to translate vmemmap (Virtual memmap) addresses to physical address while excluding free pages. ------------- [root@miz02 127.0.0.1-2013.01.30-16:44:35]# rm -f ./out; makedumpfile -c -d 31 ./vmcore ./out The kernel version is not supported. The created dumpfile may be incomplete. Excluding free pages : [ 0 %] page_to_pfn: Can't convert the address of page descriptor (f000000000765800) to pfn. page_to_pfn: Can't convert the address of page descriptor (f000000000765800) to pfn. makedumpfile Failed. ------------- When makedumfile dump level is reduced to not filter free pages the makedumpfile works fine. ------------- [root@miz02 127.0.0.1-2013.01.30-16:44:35]# rm -f ./out; makedumpfile -c -d 15 ./vmcore ./out The kernel version is not supported. The created dumpfile may be incomplete. Copying data : [100 %] The dumpfile is saved to ./out. makedumpfile Completed. ------------- [root@miz02 127.0.0.1-2013.01.30-16:44:35]# uname -a Linux miz02.austin.ibm.com 3.7.2-204.fc18.ppc64 #1 SMP Fri Jan 18 10:44:51 MST 2013 ppc64 ppc64 ppc64 GNU/Linux [root@miz02 127.0.0.1-2013.01.30-16:44:35]# grep VMEMMAP /boot/config-3.7.2-204.fc18.ppc64 CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y [root@miz02 127.0.0.1-2013.01.30-16:44:35]# The Fedora18 kernel is compiled with CONFIG_SPARSEMEM_VMEMMAP option and hence it uses vmemmap address. Some of the memory allocated to maintain free pages list comes from vmemmap area. The current makedumpfile does not have support to translate vmemmap address to physical address. I am investigating and working on adding this support into makedumpfile. For now the workaround is to lower the dump level to 15 or below for successful vmcore generation. This can be done by adding following line to /etc/kdump.conf core_collector makedumpfile -c --message-level 1 -d 15 == Comment: #8 - NAVEED A. UPPINANGADY SALIH <naveedaus.com> - 2013-05-17 06:18:00 == (In reply to comment #7) > The Fedora18 kernel is compiled with CONFIG_SPARSEMEM_VMEMMAP option and > hence it uses vmemmap address. Some of the memory allocated to maintain free > pages list comes from vmemmap area. The current makedumpfile does not have > support to translate vmemmap address to physical address. I am investigating > and working on adding this support into makedumpfile. > > For now the workaround is to lower the dump level to 15 or below for > successful vmcore generation. > This can be done by adding following line to /etc/kdump.conf > > core_collector makedumpfile -c --message-level 1 -d 15 This issue is still found in F19alpha, -d 15 did not help either, but removing "-d xx" helped. == Comment: #9 - MAHESH J. SALGAONKAR <mahesh.salgaonkar.com> - 2013-05-22 06:35:27 == (In reply to comment #8) > (In reply to comment #7) > > > The Fedora18 kernel is compiled with CONFIG_SPARSEMEM_VMEMMAP option and > > hence it uses vmemmap address. Some of the memory allocated to maintain free > > pages list comes from vmemmap area. The current makedumpfile does not have > > support to translate vmemmap address to physical address. I am investigating > > and working on adding this support into makedumpfile. Is there a reason why fedora 19 kernel is built with CONFIG_SPARSEMEM_VMEMMAP ? > > > > For now the workaround is to lower the dump level to 15 or below for > > successful vmcore generation. > > This can be done by adding following line to /etc/kdump.conf > > > > core_collector makedumpfile -c --message-level 1 -d 15 > > This issue is still found in F19alpha, > -d 15 did not help either, but removing "-d xx" helped. == Comment: #11 - NISHANTH ARAVAMUDAN <aravam.com> - 2013-05-28 15:51:39 == (In reply to comment #10) > As discussed, > > If this CONFIG_SPARSEMEM_VMEMMAP goes into RHEL7 then makedumpfile will not > work. That seems wrong (or needs some further clarification). From a build with pseries_defconfig: CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y Thanks, Nish == Comment: #12 - MANAS K. NAYAK <maknayak.com> - 2013-06-25 05:53:01 == Verified on kernel 3.9.6-301.fc19.ppc64p7 on F19 , it triggered below Oops on console and did not generate any vmcore file . [root@miz11 ~]# echo c > /proc/sysrq-trigger [ 305.598125] SysRq : Trigger a crash [ 305.598142] Unable to handle kernel paging request for data at address 0x00000000 [ 305.598147] Faulting instruction address: 0xc0000000004a9f8c [ 305.598153] Oops: Kernel access of bad area, sig: 11 [#1] [ 305.598156] SMP NR_CPUS=1024 NUMA pSeries [ 305.598162] Modules linked in: bnep bluetooth rfkill btrfs raid6_pq libcrc32c xor ibmveth ibmvscsi scsi_transport_srp scsi_tgt uinput [last unloaded: iptable_mangle] [ 305.598180] NIP: c0000000004a9f8c LR: c0000000004aad10 CTR: c0000000004a9f60 [ 305.598185] REGS: c0000000a7303830 TRAP: 0300 Tainted: P (3.9.6-301.fc19.ppc64p7) [ 305.598190] MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 48222822 XER: 00000001 [ 305.598201] SOFTE: 0 [ 305.598204] CFAR: c00000000000908c [ 305.598206] DAR: 0000000000000000, DSISR: 42000000 [ 305.598210] TASK = c0000000cc280000[1084] 'bash' THREAD: c0000000a7300000 CPU: 6 GPR00: c0000000004aad10 c0000000a7303ab0 c0000000012a0490 0000000000000063 GPR04: 0000000000000000 0000000000000016 c000000000c12cd8 c0000000017c2128 GPR08: c000000000c00490 0000000000000000 0000000000000001 0000000000006a1c GPR12: 0000000048222822 c000000003ec1800 0000000010142550 0000000040000000 GPR16: 0000000010143cdc 0000000000000000 00000000101306fc 00000000101424dc GPR20: 00000000101424e0 000000001013c6f0 0000000000000000 0000000000000000 GPR24: 0000000000000007 0000000000000000 0000000000000001 c0000000011acae0 GPR28: c0000000015c6650 0000000000000063 c000000001177914 c0000000011acea0 [ 305.598271] NIP [c0000000004a9f8c] .sysrq_handle_crash+0x2c/0x40 [ 305.598276] LR [c0000000004aad10] .__handle_sysrq+0x100/0x260 [ 305.598279] Call Trace: [ 305.598283] [c0000000a7303ab0] [f000000000311680] 0xf000000000311680 (unreliable) [ 305.598289] [c0000000a7303b20] [c0000000004aad10] .__handle_sysrq+0x100/0x260 [ 305.598295] [c0000000a7303be0] [c0000000004ab450] .write_sysrq_trigger+0xa0/0xb0 [ 305.598301] [c0000000a7303c60] [c0000000002c1774] .proc_reg_write+0xb4/0x130 [ 305.598307] [c0000000a7303d00] [c000000000233aa8] .vfs_write+0xc8/0x200 [ 305.598312] [c0000000a7303d90] [c000000000233ef4] .SyS_write+0x64/0xe0 [ 305.598318] [c0000000a7303e30] [c000000000009e54] syscall_exit+0x0/0x98 [ 305.598322] Instruction dump: [ 305.598325] 60000000 7c0802a6 f8010010 f821ff91 60000000 60000000 3d42001c 392ad858 [ 305.598334] 39400001 91490000 7c0004ac 39200000 <99490000> 38210070 e8010010 7c0803a6 [ 305.598345] ---[ end trace c049a4ea122eec01 ]--- [ 305.600149] [ 305.600155] Sending IPI to other CPUs [ 305.601165] IPI complete [root@miz11 crash]# uname -a Linux miz11.austin.ibm.com 3.9.6-301.fc19.ppc64p7 #1 SMP Tue Jun 18 04:23:12 MST 2013 ppc64 ppc64 ppc64 GNU/Linux [root@miz11 crash]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.9.6-301.fc19.ppc64p7 root=/dev/mapper/fedora_miz11-root ro rd.lvm.lv=fedora_miz11/swap rd.dm=0 rd.lvm.lv=fedora_miz11/root vconsole.keymap=us rd.md=0 rd.luks=0 vconsole.font=latarcyrheb-sun16 crashkernel=512M@64M LANG=en_US.UTF-8 [root@miz11 crash]# rpm -qi system-config-kdump-2.0.11-2.fc19.noarch Name : system-config-kdump Version : 2.0.11 Release : 2.fc19 Architecture: noarch Install Date: Tue 25 Jun 2013 05:09:48 AM EDT Group : System Environment/Base Size : 1397998 License : GPLv2+ Signature : RSA/SHA1, Thu 13 Jun 2013 01:40:00 PM EDT, Key ID 0562eb6fba094068 Source RPM : system-config-kdump-2.0.11-2.fc19.src.rpm Build Date : Wed 12 Jun 2013 06:54:03 AM EDT Build Host : buildvm-09.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://fedorahosted.org/system-config-kdump/ Summary : A graphical interface for configuring kernel crash dumping Description : system-config-kdump is a graphical tool for configuring kernel crash dumping via kdump and kexec. [root@miz11 crash]# rpm -qi kexec-tools Name : kexec-tools Version : 2.0.4 Release : 4.fc19 Architecture: ppc64 Install Date: Tue 25 Jun 2013 05:09:47 AM EDT Group : Applications/System Size : 878951 License : GPLv2 Signature : RSA/SHA1, Wed 19 Jun 2013 10:47:31 AM EDT, Key ID 0562eb6fba094068 Source RPM : kexec-tools-2.0.4-4.fc19.src.rpm Build Date : Tue 18 Jun 2013 01:55:06 PM EDT Build Host : ppc-builder5.qa.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project Summary : The kexec/kdump userspace component. Description : kexec-tools provides /sbin/kexec binary that facilitates a new kernel to boot using the kernel's kexec feature either on a normal or a panic reboot. This package contains the /sbin/kexec binary and ancillary utilities that together form the userspace component of the kernel's kexec feature. Thanks... Manas
Why is this marked as a kernel issue? You're forcing a crash and then kdump isn't doing it's thing. Sounds more like a kdump issue to me?
------- Comment From vaish123.com 2013-06-26 04:59 EDT------- (In reply to comment #16) > Why is this marked as a kernel issue? You're forcing a crash and then kdump > isn't doing it's thing. Sounds more like a kdump issue to me? Yes this is a kdump issue.
------- Comment From vaish123.com 2013-10-31 09:12 EDT------- *** Bug 99167 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Please try with latest F20 and configure kdump.conf option as core_collector makedumpfile -c -d 31 --message-level 31
We have rebased to latest upstream kexec-tools release. This issue should have been resolve. Closing, please reopen if it's still a problem Thanks Dave