Bug 691632
| Summary: | readmem: Can't read the dump memory(/proc/vmcore). Cannot allocate memory | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Chao Ye <cye> |
| Component: | kexec-tools | Assignee: | Cong Wang <amwang> |
| Status: | CLOSED ERRATA | QA Contact: | Kernel Dump QE <kernel-dump-qe> |
| Severity: | urgent | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.1 | CC: | czhang, gli, gouyang, phan, rkhan |
| Target Milestone: | rc | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kexec-tools-2_0_0-179_el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-05-19 14:16:14 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
Chao Ye
2011-03-29 05:05:09 UTC
I bet this is due to:
vaddr = ioremap_cache(pfn << PAGE_SHIFT, PAGE_SIZE);
if (!vaddr)
return -ENOMEM;
It is really confusing that it returns ENOMEM for read(2)...
Did you see any kernel messages? If not, try to add "ignore_loglevel" to the second kernel.
Might be related with:
commit 23da4563659382c6da6ac1fdf70099fe12010894
Author: Neil Horman <nhorman>
Date: Thu Oct 14 18:54:30 2010 -0400
[kdump] kexec: accelerate vmcore copies by marking oldmem in /proc/vmcore as cached
which is merged in kernel-2.6.32-85.el6~35, so does kernel-2.6.32-84.el6 have this problem on that machine?
readmem: type_addr: 0, addr:ffff880000040d40, size:4 BIOS-provided physical RAM map: BIOS-e820: 0000000000000100 - 00000000000a0000 (usable) BIOS-e820: 0000000000100000 - 00000000cffa8000 (usable) ... user-defined physical RAM map: user: 0000000000000000 - 0000000000001000 (reserved) user: 0000000000001000 - 00000000000a0000 (usable) ... Seems 640K related... *** Bug 690362 has been marked as a duplicate of this bug. *** Tested on amd-dinar-03.lab.bos.redhat.com with latest build: ====================================================================== [root@amd-dinar-03 ~]# rpm -q kernel kexec-tools kernel-2.6.32-131.0.1.el6.x86_64 kexec-tools-2.0.0-186.el6.x86_64 [root@amd-dinar-03 ~]# tail /etc/kdump.conf #kdump_post /var/crash/scripts/kdump-post.sh #extra_bins /usr/bin/lftp #disk_timeout 30 #extra_modules gfs2 #options modulename options #default shell ext4 /dev/mapper/vg_amddinar03-lv_root core_collector makedumpfile -c --message-level 1 -d 31 default shell [root@amd-dinar-03 ~]# service kdump restart Stopping kdump:[ OK ] Detected change(s) the following file(s): /etc/kdump.conf Rebuilding /boot/initrd-2.6.32-131.0.1.el6.x86_64kdump.img Your running kernel is using more than 70% of the amount of space you reserved for kdump, you should consider increasing your crashkernel reservation[WARNING] Starting kdump:[ OK ] [root@amd-dinar-03 ~]# insmod /mnt/tests/kernel/kdump/crash-crasher/crasher/crasher.ko [root@amd-dinar-03 ~]# echo 0 > /proc/crasher -------------------------------------------------------------------- Free memory/Total memory (free %): 187912 / 241096 ( 77.9407 ) Scanning logical volumes Reading all physical volumes. This may take a while... Found volume group "vg_amddinar03" using metadata type lvm2 Activating logical volumes 3 logical volume(s) in volume group "vg_amddinar03" now active Free memory/Total memory (free %): 186948 / 241096 ( 77.5409 ) Saving to the local filesystem /dev/mapper/vg_amddinar03-lv_root e2fsck 1.41.12 (17-May-2010) /dev/mapper/vg_amddinar03-lv_root: recovering journal Clearing orphaned inode 2895036 (uid=0, gid=0, mode=0100600, size=4096) Clearing orphaned inode 2895000 (uid=0, gid=0, mode=0100600, size=4096) Clearing orphaned inode 2894999 (uid=0, gid=0, mode=0100600, size=4096) Clearing orphaned inode 2894990 (uid=0, gid=0, mode=0100600, size=4096) /dev/mapper/vg_amddinar03-lv_root: clean, 122390/3276800 files, 8423377/13107200 blocks EXT4-fs (dm-0): mounted filesystem with ordered data mode Free memory/Total memory (free %): 185768 / 241096 ( 77.0515 ) Loading SELINUX policy type=1404 audit(1303351095.630:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 type=1403 audit(1303351096.448:3): policy loaded auid=4294967295 ses=4294967295 Copying data : [100 %] Saving core complete md: stopping all md devices. sd 0:0:1:0: [sda] Synchronizing SCSI cache Restarting system. machine restart Change status to VERIFIED An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0736.html |