Re: [Fastboot] [Patch] Kexec-tools: Fix physcal address value in vmcore ELF segment header

Re: [Fastboot] [Patch] Kexec-tools: Fix physcal address value in vmcore ELF segment header

[Horms]

On Thu, Sep 21, 2006 at 01:01:04PM +0800, Zou Nan hai wrote:
> 
> I used fixed 64M as physical offset in vmcore ELF segment header.
> This gives trouble to crash utility to analyze vmcore on platform that
> load kernel to a different address.
> 
> This patch will fix it.
> 
> Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>

Thanks, 

I have merged this into kexec-tools-testing

Signed-off-by: Simon Horman <horms@verge.net.au>

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

Re: [Fastboot] [Patch] Kexec-tools: Fix physcal address value in vmcore ELF segment header

[Vivek Goyal]

On Thu, Sep 21, 2006 at 01:01:04PM +0800, Zou Nan hai wrote:
> 
> I used fixed 64M as physical offset in vmcore ELF segment header.
> This gives trouble to crash utility to analyze vmcore on platform that
> load kernel to a different address.
> 
> This patch will fix it.
> 
> Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
> 
> diff -Nraup kexec-tools-1.101/kexec/arch/ia64/crashdump-ia64.c kexec-tools-1.101-fix/kexec/arch/ia64/crashdump-ia64.c
> --- kexec-tools-1.101/kexec/arch/ia64/crashdump-ia64.c	2006-09-20 15:29:29.000000000 +0800
> +++ kexec-tools-1.101-fix/kexec/arch/ia64/crashdump-ia64.c	2006-09-20 15:32:27.000000000 +0800
> @@ -28,7 +28,7 @@
>  #include "crashdump-ia64.h"
>  
>  int memory_ranges = 0;
> -#define LOAD_OFFSET 	(0xa000000000000000UL + 0x100000000UL - (1UL<<26))
> +#define LOAD_OFFSET 	(0xa000000000000000UL + 0x100000000UL - kernel_code_start)

This will work as long as virtual address for which kernel is being compiled
remains same. (I guess, 0xa000000000000000UL + 0x100000000UL). If you shift
the kernel little bit in virtual address space, this assumption will be
broken.

That's why I put a patch to read /proc/kcore and determine for which
virtual address the kernel has been built and there is no hardcoding.
(Thanks to Eric for the suggestion.)

-Vivek