| Summary: | [HP BCS 6.5 Bug] Full dump is done even if dump level 31 is specified | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Lisa Mitchell <lisa.mitchell> |
| Component: | kexec-tools | Assignee: | Baoquan He <bhe> |
| Status: | CLOSED DUPLICATE | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.5 | CC: | adaora.onyia, bhe, ctatman, doug.hatch, jerry_hoemann, jingbai.ma, jshortt, nigel.croxon, rwright, tom.vaden, trinh.dao |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-12 03:02:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Lisa Mitchell
2013-10-11 21:19:43 UTC
More details, for the full dump issue on the 128 GB system, my crashkernel size was 512M, specified on the command line : crashkernel=512M, NOT using crashkernel=auto. And I made sure the dump initrd was rebuilt, using the kdump.conf file specifiying dump level 31, using service kdump restart Another correction, My good dump on the very large 8 blade system was on RHEL 6.5 beta 1, the -419 kernel. I've yet to get a dump level=31 dump on RHEL 6.5 snapshot 1. I just reproduced this on a DL980 on RHEL 6.5 snapshot 1, with 64 GB of memory. The dump proceeded very slowly, in the copy phase, and I reset the system before the dump was 30% done. When I rebooted the incomplete vmcore was 25 GB. The dump_level of the dump I took was dump_level: 0 (0x0), and this was after a fresh RHEL 6.5 snapshot 1 install, and setting crashkernel =128M and rebooting. core_collector makedumpfile -c --message-level 1 -d 31 was in /etc/kdump.conf. So this looks like a generic problem for RHEL 6.5 snapshot one, on shipping Proliant platforms as well. Hi Lisa, It's a known problem, and has been fixed. We have delivered a new release kexec-tools-2.0.0-270.el6, please help test it. If you can't get the latest release, I have put one in below link, please access and get it. http://people.redhat.com/~bhe/.2112e0f1a4a02ad7917802fcf2d43426/ Baoquan Thanks *** This bug has been marked as a duplicate of bug 1015764 *** Thanks, can HP have access to 1015764? I just tested kexec-tools-2.0.0-270.el6 on the DL980 that failed previously, just doing an rpm -Uvh on top of the snapshot 1 version, and it worked great! Thanks! I got a dump_level=31 dump, all compressed only 274 MB for a 64 GB system, where before I had stopped the snapshot 1 dump with incomplete vmcore of 25 GB. So looks like you got it fixed. Still would like access to 1015764, though, as we are patching other fixes into makedumpfile, trying to fix another problem and we would like to see what was fixed, or what caused this regression. Hi Lisa, I am asking reporter of that bug whether HP can access it. Meanwhile I put patch in below link, please click it. you can see the cause and fix. http://post-office.corp.redhat.com/archives/kexec-kdump-list/2013-October/msg00019.html Baoquan Thanks I can't access the above link. Get DNS server error, like we can't access post-office.corp.redhat.com. I'll see if Nigel can access it for me. Nigel got me the info, so I don't need access any more. |