Bug 977784

Summary: Fedora18: RC2.2: kdump failed to generate expected size of vmcore
Product: [Fedora] Fedora Reporter: IBM Bug Proxy <bugproxy>
Component: kexec-toolsAssignee: Baoquan He <bhe>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 20CC: bhe, bugproxy, chaowang, gansalmon, hannsj_uhl, itamar, jkachuck, jonathan, kernel-maint, madhu.chinakonda, nhorman, ruyang, wgomerin, xiyou.wangcong
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-11 06:45:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description IBM Bug Proxy 2013-06-25 10:30:44 UTC 
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
Comment 1 Josh Boyer 2013-06-25 11:54:19 UTC 
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 2 IBM Bug Proxy 2013-06-26 05:00:29 UTC 
------- 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 3 IBM Bug Proxy 2013-10-31 09:20:58 UTC 
------- Comment From vaish123.com 2013-10-31 09:12 EDT-------
*** Bug 99167 has been marked as a duplicate of this bug. ***
Comment 4 Fedora End Of Life 2013-12-21 14:08:07 UTC 
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.
Comment 5 WANG Chao 2013-12-25 05:25:49 UTC 
Please try with latest F20 and configure kdump.conf option as core_collector makedumpfile -c -d 31 --message-level 31
Comment 6 Dave Young 2014-07-11 06:45:03 UTC 
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