1:02 a.m.
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...
Thanks.
Itsuro Oda
On Fri, 05 Sep 2008 13:42:46 +0900
Itsuro ODA <oda(a)valinux.co.jp> wrote:
Hi,
I recieved the dump file via FTP from Yuji and I can reproduced
the problem.
Hmm, it seems the format of the crash note section is not expected.
(and there is another problem; "jiffies" is lost.)
I will check more deeply.
Until the problem is fixed, try the following quick hack.
------------------------------------------------------------------
--- xen_hyper.c.org 2008-09-05 12:48:57.000000000 +0900
+++ xen_hyper.c 2008-09-05 13:32:28.000000000 +0900
@@ -150,7 +150,7 @@
* Do some initialization.
*/
#ifndef IA64
- xen_hyper_dumpinfo_init();
+// xen_hyper_dumpinfo_init(); /* XXX: should be fixed !! */
#endif
xhmachdep->pcpu_init();
xen_hyper_domain_init();
@@ -1746,9 +1746,11 @@
tmp2 = (ulong)jiffies_64;
jiffies_64 = (ulonglong)(tmp2 - tmp1);
}
- } else {
+ } else if (symbol_exists("jiffies")) {
get_symbol_data("jiffies", sizeof(long), &jiffies);
jiffies_64 = (ulonglong)jiffies;
+ } else {
+ jiffies_64 = 0; /* XXX: find alternative !! */
}
return jiffies_64;
------------------------------------------------------------------
(the "dumpinfo" sub command cannot be used.)
Thanks.
Itsuro Oda
On Thu, 04 Sep 2008 16:29:51 +0900
Yuji Shimada <shimada-yxb(a)necst.nec.co.jp> wrote:
> Hi ODA-san,
>
> Thank you so much for your reply.
>
> > What arch did you use ?
>
> I used x86_64 arch.
>
> > If you send me xen-syms-3.3-unstable and dumpfile.core
> > I will investigate more.
>
> Please find "xen-syms-3.3-unstable", attached with the mail.
> If you need "dumpfile.core" to investigate this issue, please let me
know.
>
> In such case, I think I should send you "dumpfile.core" stored on
> the disk by post, or upload it to your site. Because it is a huge size.
>
> Thanks,
>
> --
> Yuji Shimada
--
Itsuro ODA <oda(a)valinux.co.jp>
_______________________________________________
Xen-devel mailing list
Xen-devel(a)lists.xensource.com
http://lists.xensource.com/xen-devel
--
Itsuro ODA <oda(a)valinux.co.jp>
2:03 a.m.
New subject: [Xen-devel] crash can't analyze memory dumpfile of Xen
On 3/10/08 07:02, "Itsuro ODA" <oda(a)valinux.co.jp> wrote:
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...
Is the problem easier if you don't try to support every random snapshot of
xen-unstable? Why not constrain yourself to stable releases (or even random
snapshots of stable branches): then you could indeed just look for >=3.3?
-- Keir
2:21 a.m.
New subject: [Xen-devel] crash can't analyze memory dumpfile of Xen
Hi,
Yes, it is one option.
(If I can not find any good idea, I will select this.)
Thanks.
Itsuro Oda
On Fri, 03 Oct 2008 08:03:48 +0100
Keir Fraser <keir.fraser(a)eu.citrix.com> wrote:
On 3/10/08 07:02, "Itsuro ODA" <oda(a)valinux.co.jp>
wrote:
> 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...
Is the problem easier if you don't try to support every random snapshot of
xen-unstable? Why not constrain yourself to stable releases (or even random
snapshots of stable branches): then you could indeed just look for >=3.3?
-- Keir
--
Itsuro ODA <oda(a)valinux.co.jp>
7:47 a.m.
New subject: [Xen-devel] crash can't analyze memory dumpfile of Xen
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
10:08 p.m.
New subject: [Xen-devel] crash can't analyze memory dumpfile of Xen
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(a)redhat.com> 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(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Itsuro ODA <oda(a)valinux.co.jp>
6237
days inactive
6237
days old
devel@lists.crash-utility.osci.io
4 comments
3 participants
participants (3)
-
Dave Anderson -
Itsuro ODA -
Keir Fraser