Hi,
It is a good point.
Thank you for your suggestion.
Itsuro Oda
On Fri, 03 Oct 2008 08:47:28 -0400
Dave Anderson <anderson@xxxxxxxxxx> wrote:
> 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
>
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Itsuro ODA <oda@xxxxxxxxxxxxx>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
