aboutsummaryrefslogtreecommitdiffstats
path: root/firmware/bnx2
diff options
context:
space:
mode:
authorYinghai Lu <yinghai@kernel.org>2010-10-05 16:05:14 -0700
committerH. Peter Anvin <hpa@zytor.com>2010-10-05 21:43:14 -0700
commit9f4c13964b58608fbce05540743281ea3146c0e8 (patch)
tree94735fea950cba43958ecf13146a4d5a8b5b22d9 /firmware/bnx2
parent7c996361ef0d02ef8c1435902c909d14195adcdc (diff)
downloadkernel_samsung_tuna-9f4c13964b58608fbce05540743281ea3146c0e8.zip
kernel_samsung_tuna-9f4c13964b58608fbce05540743281ea3146c0e8.tar.gz
kernel_samsung_tuna-9f4c13964b58608fbce05540743281ea3146c0e8.tar.bz2
x86, memblock: Fix crashkernel allocation
Cai Qian found crashkernel is broken with the x86 memblock changes. 1. crashkernel=128M@32M always reported that range is used, even if the first kernel is small and does not usethat range 2. we always got following report when using "kexec -p" Could not find a free area of memory of a000 bytes... locate_hole failed The root cause is that generic memblock_find_in_range() will try to allocate from the top of the range, whereas the kexec code was written assuming that allocation was always near the bottom and that it could blindly extend memory upward. Unfortunately the kexec code doesn't have a system for requesting the range that it really needs, so this is subject to probabilistic failures. This patch hacks around the problem by limiting the target range heuristically to below the traditional bzImage max range. This number is arbitrary and not always correct, and a much better result would be obtained by having kexec communicate this number based on the kernel header information and any appropriate command line options. Reported-and-Bisected-by: CAI Qian <caiqian@redhat.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4CABAF2A.5090501@kernel.org> Cc: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Diffstat (limited to 'firmware/bnx2')
0 files changed, 0 insertions, 0 deletions