Description of problem: There looks like a problem which will block the following RHEL5.4 feature working properly, kexec-tools: Bug 475414 - FEAT RHEL5.4: [kdump] Salvaging panic messages from kdump vmcore kernel: Bug 485308 - FEAT RHEL5.4: [kdump] Salvaging panic messages from kdump vmcore I am getting incomplete dmesgs on almost all architectures with or without filtering VMCores (although I don't think whether filtering or not is really matter, "makedumpfile --dump-dmesg" is running on /proc/vmcore directly anyway, i.e., never on a filtered VMCore). Anyway, I have tested it for both with or without filtering, but the results are the same -- incomplete dmesgs. # cat /etc/kdump.conf ext3 /dev/mapper/VolGroup00-LogVol00 core_collector makedumpfile -c -d 31 kdump_post /bin/dump-dmesg-script # cat /bin/dump-dmesg-script #!/bin/msh makedumpfile --dump-dmesg /proc/vmcore /mnt/dmesg.txt exit 0 After the kdump finished, I am getting the following files, 1) i386 # cat dmesg.txt <5>Linux version 2.6.18-156.el5 2) ppc # cat dmesg.txt <6>Using pSeries machine description <7>Page orders: linear map 3) x86_64 # cat dmesg.txt <5>Linux version 2.6.18-156.el5 In addition, it also does not work without filtering, # cat /etc/kdump.conf ext3 /dev/mapper/VolGroup00-LogVol00 extra_bins /sbin/makedumpfile kdump_post /bin/dump-dmesg-script # cat /bin/dump-dmesg-script #!/bin/msh makedumpfile --dump-dmesg /proc/vmcore /mnt/dmesg.txt exit 0 1) i386 # cat dmesg.txt <5>Linux version 2.6.18-156.el5 2) x86_64 # cat dmesg.txt <5>Linux version 2.6.18-156.el5 3) ppc # cat dmesg.txt <6>Using pSeries machine description <7>Page orders: linear map 4) ia64 # cat dmesg.txt <5>Linux version 2.6.18-156.el5 For the data point, if I manually run this command when login into the kdump kernel, i.e., run through INIT process; disable kdump daemon, I can see that the dmesg file is more complete. Note, this should not be considered as a workaround of this problem, because kdump has seldom been used this way. # makedumpfile --dump-dmesg /proc/vmcore dmesg.txt makedumpfile Completed. # cat dmesg.txt <5>Linux version 2.6.18-156.el5PAE (mockbuild.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Mon Jun 29 18:34:12 EDT 2009 <6>BIOS-provided physical RAM map: <4> BIOS-e820: 0000000000010000 - 000000000009b000 (usable) <4> BIOS-e820: 000000000009b000 - 00000000000a0000 (reserved) <4> BIOS-e820: 00000000000ce000 - 0000000000100000 (reserved) <4> BIOS-e820: 0000000000100000 - 00000000e3f70000 (usable) <4> BIOS-e820: 00000000e3f70000 - 00000000e3f77000 (ACPI data) <4> BIOS-e820: 00000000e3f77000 - 00000000e3f80000 (ACPI NVS) <4> BIOS-e820: 00000000e3f80000 - 00000000e4000000 (reserved) <4> BIOS-e820: 00000000fec00000 - 00000000fec00400 (reserved) <4> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) <4> BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) <4> BIOS-e820: 0000000100000000 - 0000000400000000 (usable) ... Version-Release number of selected component (if applicable): kexec-tools-1.102pre-75.el5 kernel-2.6.18-156.el5 RHEL5.4-Server-20090701.0 How reproducible: always Steps to Reproduce: 1. configure kdump using the above kdump.conf and dump-dmesg-script. 2. manually crash the system -- SysRq-C. 3. cat /dmesg.txt (assume /dev/mapper/VolGroup00-LogVol00 is the root partition.) Actual results: incomplete demsg Expected results: complete desmg
I disagree with your assertion regarding the workaround. Nothing in the origional RFE indicates that the feature needs to be used from within kdump itself. It just requests that we be able to extract the dmesg log from a vmcore without needing to have the debuginfo pacage installed (as crash would otherwise require). To say that kdump is seldom used this way is a misnomer, since kdump has never been able to be used this way previously. Certainly I need to look at this problem and fix it, but I don't see why it needs to block the 5.4 release (especially since I think it went out already). Adjusting flags for 5.5