[Crash-utility] Re: [Xen-devel] crash can't analyze memory dumpfile of Xen

Dave Anderson anderson at redhat.com
Fri Oct 3 12:47:28 UTC 2008


Itsuro ODA wrote:
> Hi,
> 
> I found the root cause of this problem is that the value of "PERCPU_SHIFT"
> was changed to 13 from 12.
> 
> The quick workaround is to apply the following patch to the crash command:
> ----------------------------------------------------------------------
> --- xen_hyper_defs.h.org        2008-10-03 14:46:28.000000000 +0900
> +++ xen_hyper_defs.h    2008-10-03 14:46:50.000000000 +0900
> @@ -134,7 +134,7 @@
>  #endif
> 
>  #if defined(X86) || defined(X86_64)
> -#define XEN_HYPER_PERCPU_SHIFT 12
> +#define XEN_HYPER_PERCPU_SHIFT 13
>  #define xen_hyper_per_cpu(var, cpu)  \
>         ((ulong)(var) + (((ulong)(cpu))<<XEN_HYPER_PERCPU_SHIFT))
>  #elif defined(IA64)
> ------------------------------------------------------------------------
> 
> I need to think the backword compatibility. I wonder how to determine
> the value of "PERCPU_SHIFT". The change of "PERCPU_SHIFT" was made at
> a certain point of xen-unstable before xen-3.3 release. The xen version
> number (3.3) can't use as key... I will consider more...

 From the crash utility perspective, and looking at the RHEL5 xen sources
where these hypervisor definitions exist:

   #define PERCPU_SIZE (1UL << PERCPU_SHIFT)

   static void __init percpu_init_areas(void)
   {
       unsigned int i, data_size = __per_cpu_data_end - __per_cpu_start;
       unsigned int first_unused;

       BUG_ON(data_size > PERCPU_SIZE);

during initialization you could calculate the difference between the
__per_cpu_data_end and __per_cpu_start symbol values, and if it's more
than the original 4k size (12), then it must be 13.

Dave




More information about the Crash-utility mailing list