summaryrefslogtreecommitdiff
path: root/kexec/arch
AgeCommit message (Collapse)Author
2013-06-21arm: Fix out of tree build errorGeoff Levand
Prefix local include paths with $(srcdir)/. Fixes build errors like these when building for ARM out of the source tree: cc1: fatal error: kexec/arch/arm/crashdump-arm.h: No such file or directory Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-06-10kexec-tools: sh: Remove saved_max_memZhang Yanfei
saved_max_mem is used to calculate the amount of memory that the previous kernel used. It seems in sh, we just calculate this variable, but we never use it. So remove it. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-06-10kexec-tools: ppc64: Remove saved_max_memZhang Yanfei
saved_max_mem is used to calculate the amount of memory that the previous kernel used. And passed to the dump-capture kernel by kernel commandline parameter "savemaxmem=". But in the dump-capture kernel, we never use this parameter now, so remove saved_max_mem and don't add "savemaxmem=" to new kernel commandline. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-06-10kexec-tools: ppc: Remove saved_max_memZhang Yanfei
saved_max_mem is used to calculate the amount of memory that the previous kernel used. And passed to the dump-capture kernel by kernel commandline parameter "savemaxmem=". But in the dump-capture kernel, we never use this parameter now, so remove saved_max_mem and don't add "savemaxmem=" to new kernel commandline. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-06-10kexec-tools: mips: Remove saved_max_memZhang Yanfei
saved_max_mem is used to calculate the amount of memory that the previous kernel used. And passed to the dump-capture kernel by kernel commandline parameter "savemaxmem=". But in the dump-capture kernel, we never use this parameter now, so remove saved_max_mem and don't add "savemaxmem=" to new kernel commandline. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-05-26kexec-tools: ppc/ppc64: cleanup: Remove never reached returnZhang Yanfei
The return will never be reached, so remove it. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-05-26kexec/s390: cleanup: Remove non-existent header file includeZhang Yanfei
There is no elf.h in this directory, so remove the useless include. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-05-26kexec/s390: cleanup: Fix a mistaken commentZhang Yanfei
When borrowing codes from ia64 architecture, this comment was forgotten to be change. So fix it. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-04-30Revert "kexec: include reserved e820 sections in crash kernel"Zhang Yanfei
This reverts commit e35aa29fb40b37bf86d980b2e19af5e01c2d2549. This patch is based on the commit 49320340f705694e387d794f7f19d407ad9baefa "kexec: lengthen the kernel command line image" Since the latter commit has been reverted due to its useless, this patch should be reverted too. Besides, This patch also changed a kernel restriction of max segments from 16 to 70. Though kexec-tools could have more segments, more than 16, the kexec_load syscall will still fail for the kernel side has a restriction of 16. Cc: Cliff Wickman <cpw@sgi.com> Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-04-26kdump, x86: Process multiple Crash kernel in /proc/iomemYinghai Lu
Vivek found specical handling crashkernel low in not good. We should extend kexec-tools to handle multiple Crash kernel instead. Extend crash_reserved_mem to array instead and use kexec_iomem_for_each_line directly. After that we can drop crashkernel low. -v2: fix left over calling of parse_iomem_single() found by Vivek. Suggested-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-04-25kexec/uImage: probe to identify a corrupted imageSuzuki K. Poulose
Teach uImage_probe_xxx() to return the information about a corrupted image. This is required to prevent the loading of a corrupted ramdisk, where we don't have strict checking for the other formats, unlike the kernel. So, we should abort the operation than causing a problem with the new kernel. Without this patch, a corrupted uImage ramdisk is treated as a plain ramdisk where there is no format check involved. # kexec -l uImage --initrd romfs-initrd.corrupt The data CRC does not match. Computed: 867e73f7 expected 8f097cc0 # echo $? 0 # kexec -e Starting new kernel Bye! Reserving 55MB of memory at 70MB for crashkernel (System RAM: 256MB) Using Xilinx Virtex440 machine description Linux version 3.6.0-rc3 (root@suzukikp) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (GCC) ) #66 Tue Apr 16 06:36:56 UTC 2013 Found initrd at 0xcf5f8000:0xcfff8040 ... NET: Registered protocol family 17 RAMDISK: Couldn't find valid RAM disk image starting at 0. List of all partitions: No filesystem could mount root, tried: ext2 cramfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) With this patch : # kexec -l uImage --initrd romfs-initrd.corrupt uImage: The data CRC does not match. Computed: 867e73f7 expected 8f097cc0 uImage: Corrupted ramdisk file romfs-initrd With a corrupted kernel image(the behaviour remains the same) : # kexec -l uImage.corrupt --initrd romfs-initrd uImage: The data CRC does not match. Computed: 285787b7 expected e37f65ad Cannot determine the file type of uImage.corrupt Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-04-17kexec, i386, bzImage: Remove unnecessary symbol value getZhang Yanfei
We needn't get the initial values for every regs in regs32 from symbol entry32_regs for we will manually initialize them one by one next: /* * Initialize the 32bit start information. */ regs32.eax = 0; /* unused */ regs32.ebx = 0; /* 0 == boot not AP processor start */ regs32.ecx = 0; /* unused */ regs32.edx = 0; /* unused */ regs32.esi = setup_base; /* kernel parameters */ regs32.edi = 0; /* unused */ regs32.esp = elf_rel_get_addr(&info->rhdr, "stack_end"); /* stack, unused */ regs32.ebp = 0; /* unused */ regs32.eip = kernel32_load_addr; /* kernel entry point */ Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-04-17kexec:i386/kexec-[bzImage|elf-x86]:x86_64/kexec-bzImage64: Use "\0" as ↵Wang YanQing
command line instead of empty command line This patch prevents the problems to happen below: In setup_linux_bootloader_parameters_high 120 cmdline_ptr = ((char *)real_mode) + cmdline_offset; 121 memcpy(cmdline_ptr, cmdline, cmdline_len); 122 cmdline_ptr[cmdline_len - 1] = '\0'; if cmdline_len == 0, Line 122 will corrupt kernel16 buf just before the commandline. And in do_bzImage_load, for example, 369 cmdline_end = setup_base + kern16_size_needed + command_line_len - 1; 370 elf_rel_set_symbol(&info->rhdr, "cmdline_end", &cmdline_end, 371 sizeof(unsigned long)); Line 369 will go wrong, too. Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-04-16kexec/powerpc: Handle buffer overflow in kernel command lineSuzuki K. Poulose
Enforce size check for kernel command line to make sure it doesn't overflow COMMAND_LINE_SIZE. Reported-by: Nathan D. Miller <nathanm2@us.ibm.com> Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-04-16Add --dtb option to ppc64Geoff Levand
All other architectures use the command line option --dtb to pass a dtb file name. For consistency add that option to ppc64. Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-29kexec: i386: Add cmdline_add_memmap_internal() to reduce the code duplicationZhang Yanfei
Functions: - cmdline_add_memmap() - cmdline_add_memmap_acpi() - cmdline_add_memmap_reserved() is kind of similar, So add a new function cmdline_add_memmap_internal() to hold the common codes, reducing the duplication. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: ppc: Use die() instead of fatal()Zhang Yanfei
fatal() nearly does the same thing as die() does, so this is kind of duplicate. Remove fatal() and use die() instead. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: Use die() to simplify codeZhang Yanfei
Use die() to simplify code. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: x86_64: elf: fix possible memory leak in elf_x86_64_loadZhang Yanfei
In elf_x86_64_load, allocated memory may not be free'd if the code exits abnormally, by calling die() or return. So the patch fixes the possible memory leak. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: x86_64: elf: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: x86_64: bzImage64: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: ppc: uImage: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: ppc: uImage: fix possible memory leak in ppc_load_bare_bitsZhang Yanfei
In ppc_load_bare_bits, allocated memory may not be free'd if the code exits abnormally, by calling die() or return. So the patch fixes the possible memory leak. This patch is also a preparation for patch10. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: ppc: elf: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: ppc: elf: fix possible memory leak in elf_ppc_loadZhang Yanfei
In elf_ppc_load, allocated memory may not be free'd if the code exits abnormally, by calling die() or return. So the patch fixes the possible memory leak. This patch is also a preparation for patch08. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: multiboot: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: multiboot: fix possible memory leak in multiboot_x86_loadZhang Yanfei
In multiboot_x86_load, allocated memory may not be free'd if the code exits abnormally, by calling return. So the patch fixes the possible memory leak. Besides, remove some extra blank lines. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: elf: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: elf: fix possible memory leak in elf_x86_loadZhang Yanfei
In elf_x86_load, allocated memory may not be free'd if the code exits abnormally, by calling die() or return. So the patch fixes the possible memory leak. This patch is also a preparation for patch04. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-27kexec: i386: bzImage: fix memory leak caused by get_command_lineZhang Yanfei
Since get_command_line returns dynamically allocated memory, it is easy for the caller to forget freeing the memory. Here fixes a memory leak caused by this function. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: ppc64: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: ppc: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Besides, remove the duplicate _ALIGN_* definition in file kexec/arch/ppc/crashdump-powerpc.h. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: x86_64: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: sh: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: s390: remove ALIGN_UP and use _ALIGN_UPZhang Yanfei
We have _ALIGN_UP now, so remove ALIGN_UP and use _ALIGN_UP instead of it. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: mips: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: ia64: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be simplified. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: arm: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: i386: use _ALIGN* to make the logic clearZhang Yanfei
By replacing all the explicit align opertion with marco _ALIGN*, the code logic could be more clear. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-14kexec: ppc: remove duplicated _ALIGN_* macrosZhang Yanfei
We have defined the global align macros for use, so remove the duplicated macros here. And in file kexec/arch/ppc/include/page.h, we directly expand the align operation for marco PAGE_ALIGN since we have removed marco _ALIGN in this file. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-13Correct build failure in init_linux_parameters()Simon Horman
This fixes a build failure introduced by "kexec x86: drop truncation warning for crash kernel". Reported-by: CAI Qian <caiqian@redhat.com> Cc: Cliff Wickman <cpw@sgi.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-08ppc/uImage: Add support for RAM DisksSuzuki K. Poulose
Handle the RAM Disks in uImage format Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-08kexec/uImage: Introduce uImage_probe_kernelSuzuki K. Poulose
uImage supports different types of payloads, including kernel, ramdisks etc. uImage_probe() as of now checks whether the supplied payload is of type KERNEL ( i.e, IH_TYPE_KERNEL or IH_TYPE_KERNEL_NOLOAD ). Change this behaviour to return the image type, if it is one of the supported payloads. This change is in prepartion to support ramdisks in uImage format. Introduce a uImage_probe_kernel() which can be used by the archs to check if the supplied payload is one of the KERNEL types. Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: use dbgprintf instead of #if 0 for debug printingZhang Yanfei
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> [ horms@verge.net.au: Applied manually due to conflict ] Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: fix some compiler warningsZhang Yanfei
I got the following warnings when I compiled kexec-tools: kexec/kexec-elf-rel.c: In function 'elf_rel_load': kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 6 has type 'unsigned int' kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 7 has type 'long long unsigned int' kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'long long unsigned int' kexec/arch/i386/crashdump-x86.c: In function 'get_kernel_paddr': kexec/arch/i386/crashdump-x86.c:99: warning: format '%016Lx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' kexec/arch/i386/crashdump-x86.c: In function 'get_kernel_vaddr_and_size': kexec/arch/i386/crashdump-x86.c:171: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int' kexec/arch/i386/crashdump-x86.c: In function 'get_crash_notes': kexec/arch/i386/crashdump-x86.c:781: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' kexec/arch/i386/crashdump-x86.c: In function 'load_crashdump_segments': kexec/arch/i386/crashdump-x86.c:905: warning: 'nr_ranges' may be used uninitialized in this function The patch fix above warnings. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: Respect memory limit while building crash memory ranges on ppc64Mahesh Salgaonkar
Fix it on ppc64 also. This patch now reads the memory limit information from device-tree file and limits the crash memory ranges accordingly. Tested this patch on ppc64 with upstream kernel version 3.8.0-rc4 Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: Respect memory limit while building crash memory ranges on ppc32.Mahesh Salgaonkar
So far powerpc kernel never exported memory limit information which is reflected by mem= kernel cmdline option. Hence, kexec-tools always used to build ELF header for entire system RAM generating a dump bigger than the actual memory used by the first kernel. This patch now reads the memory limit information from device-tree file and limits the crash memory ranges accordingly. Suzuki tested this patch on ppc32(ppc440) with a kernel patch by Suzuki. The following are the upstream kernel commits that exports memory limit information through /proc/device-tree file: 4bc77a5ed - powerpc: Export memory limit via device tree a84fcd468 - powerpc: Change memory_limit from phys_addr_t to unsigned long long Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Tested-by: Suzuki K. Poulose <suzuki@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec: include reserved e820 sections in crash kernelCliff Wickman
The crash kernel is not able to find its root device if that device is not on PCI 0. This is because it is booted with the command line option memmap=exactmap which currently clears the e820 table and does not restore reserved spaces. This works for a device on PCI 0 because ACPI falls back to a legacy mode. But the error message " [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources" is written to the log even in this functioning case. It fails for some devices on UV2, and only for UV2, because SGI seems to be the only manufacturer currently using the extended PCI(>0). The fix is simple, as long as the command line is long enough to include all the reserved spaces. The command line may have to be lengthened. See [PATCH] kexec: lengthen the kernel command line image Signed-off-by: Cliff Wickman <cpw@sgi.com> [ horms@verge.net.au: Manually applied due to conflicts ] Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec x86: drop truncation warning for crash kernelCliff Wickman
On kexec set-up of a crash kernel on a very large memory machine we sometimes see the worrisome warning: Too many memory ranges, truncating... meaning that the total count of e820 ram, reserved and ACPI spaces is over 128. Per the comment in do_bzImage_load(): /* If using bzImage for capture kernel, then we will not be * executing real mode code. setup segment can be loaded * anywhere as we will be just reading command line. */ So if I understand, the e820 table built here and added to the 'real_mode' area is not going to be used. So the warning message can be omitted. Signed-off-by: Cliff Wickman <cpw@sgi.com> [ horms@verge.net.au manually applied due to conflict ] Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec,x86: Use macro CRASH_MAX_MEMMAP_NR for clarificationZhang Yanfei
For the allocation, using CRASH_MAX_MEMMAP_NR instead of KEXEC_MAX_SEGMENTS + 1 seems more understandable. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> [horms@verge.net.au: Applied by hand due to conflict] Signed-off-by: Simon Horman <horms@verge.net.au>
generated by cgit (git 2.34.1) at 2025-07-18 17:09:44 +0000