Hi, This patch is for xen hypervisor analysis function of the crash command to apply to the xen-3.3.0 (the newest version of xen). * PERCPU_SHIFT becomes 13 (from 12) in the xen-3.3.0. This value is calculated from "__per_cpu_start" and "__per_cpu_data_end". * "jiffies" does not exist in the xen-3.3.0. It was used to show the uptime. I found there is no altanernative (i.e. the xen hypervisor does not have the uptime.). Then if "jiffies" does not exist, "--:--:--" is showed as UPTIME in the sys command. (Is it better to eliminate the whole UPTIME line ?) --- example --- crash> sys KERNEL: xen-syms DUMPFILE: vmcore CPUS: 4 DOMAINS: 5 UPTIME: --:--:-- MACHINE: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2660 Mhz) MEMORY: 2 GB ---------------- This patch is for crash-4.0-7.2. Thanks Itsuro Oda --- --- xen_hyper_defs.h.org 2008-10-06 13:45:39.000000000 +0900 +++ xen_hyper_defs.h 2008-10-06 13:44:44.000000000 +0900 @@ -134,9 +134,8 @@ #endif #if defined(X86) || defined(X86_64) -#define XEN_HYPER_PERCPU_SHIFT 12 #define xen_hyper_per_cpu(var, cpu) \ - ((ulong)(var) + (((ulong)(cpu))<<XEN_HYPER_PERCPU_SHIFT)) + ((ulong)(var) + (((ulong)(cpu))<<xht->percpu_shift)) #elif defined(IA64) #define xen_hyper_per_cpu(var, cpu) \ ((xht->flags & XEN_HYPER_SMP) ? \ @@ -404,6 +403,7 @@ ulong *cpumask; uint *cpu_idxs; ulong *__per_cpu_offset; + int percpu_shift; }; struct xen_hyper_dumpinfo_context { --- xen_hyper.c.org 2008-10-06 13:41:14.000000000 +0900 +++ xen_hyper.c 2008-10-06 14:15:03.000000000 +0900 @@ -71,6 +71,8 @@ #endif #if defined(X86) || defined(X86_64) + xht->percpu_shift + (symbol_value("__per_cpu_data_end") - symbol_value("__per_cpu_start") > 4096) ? 13: 12; member_offset = MEMBER_OFFSET("cpuinfo_x86", "x86_model_id"); buf = GETBUF(XEN_HYPER_SIZE(cpuinfo_x86)); if (xen_hyper_test_pcpu_id(XEN_HYPER_CRASHING_CPU())) { @@ -1746,9 +1748,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; /* hypervisor does not have uptime */ } return jiffies_64; --- xen_hyper_command.c.org 2008-10-07 08:05:37.000000000 +0900 +++ xen_hyper_command.c 2008-10-07 08:24:29.000000000 +0900 @@ -1022,7 +1022,8 @@ (buf1, "%d\n", XEN_HYPER_NR_DOMAINS())); /* !!!Display a date here if it can be found. */ XEN_HYPER_PRI(fp, len, "UPTIME: ", buf1, flag, - (buf1, "%s\n", convert_time(xen_hyper_get_uptime_hyper(), buf2))); + (buf1, "%s\n", (xen_hyper_get_uptime_hyper() ? + convert_time(xen_hyper_get_uptime_hyper(), buf2) : "--:--:--"))); /* !!!Display a version here if it can be found. */ XEN_HYPER_PRI_CONST(fp, len, "MACHINE: ", flag); if (strlen(uts->machine)) { --- -- Itsuro ODA <oda@valinux.co.jp> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dave Anderson
2008-Oct-07 13:39 UTC
[Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0
Itsuro ODA wrote:> Hi, > > This patch is for xen hypervisor analysis function of the > crash command to apply to the xen-3.3.0 (the newest version of xen). > > * PERCPU_SHIFT becomes 13 (from 12) in the xen-3.3.0. > This value is calculated from "__per_cpu_start" and "__per_cpu_data_end". > * "jiffies" does not exist in the xen-3.3.0. > It was used to show the uptime. I found there is no altanernative > (i.e. the xen hypervisor does not have the uptime.). > Then if "jiffies" does not exist, "--:--:--" is showed as UPTIME in > the sys command. > (Is it better to eliminate the whole UPTIME line ?) > --- example --- > crash> sys > KERNEL: xen-syms > DUMPFILE: vmcore > CPUS: 4 > DOMAINS: 5 > UPTIME: --:--:-- > MACHINE: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2660 Mhz) > MEMORY: 2 GB > ---------------- > > This patch is for crash-4.0-7.2. > > Thanks > Itsuro OdaThe patch looks OK. But just for sanity''s sake, is it guaranteed that the per_cpu data section will be greater than 4k on both architectures? Or could there be some combination of xen CONFIG options that could reduce the i386 per_cpu data section contents to less than 4K even though PERCPU_SHIFT is 13? Dave> > --- > --- xen_hyper_defs.h.org 2008-10-06 13:45:39.000000000 +0900 > +++ xen_hyper_defs.h 2008-10-06 13:44:44.000000000 +0900 > @@ -134,9 +134,8 @@ > #endif > > #if defined(X86) || defined(X86_64) > -#define XEN_HYPER_PERCPU_SHIFT 12 > #define xen_hyper_per_cpu(var, cpu) \ > - ((ulong)(var) + (((ulong)(cpu))<<XEN_HYPER_PERCPU_SHIFT)) > + ((ulong)(var) + (((ulong)(cpu))<<xht->percpu_shift)) > #elif defined(IA64) > #define xen_hyper_per_cpu(var, cpu) \ > ((xht->flags & XEN_HYPER_SMP) ? \ > @@ -404,6 +403,7 @@ > ulong *cpumask; > uint *cpu_idxs; > ulong *__per_cpu_offset; > + int percpu_shift; > }; > > struct xen_hyper_dumpinfo_context { > --- xen_hyper.c.org 2008-10-06 13:41:14.000000000 +0900 > +++ xen_hyper.c 2008-10-06 14:15:03.000000000 +0900 > @@ -71,6 +71,8 @@ > #endif > > #if defined(X86) || defined(X86_64) > + xht->percpu_shift > + (symbol_value("__per_cpu_data_end") - symbol_value("__per_cpu_start") > 4096) ? 13: 12; > member_offset = MEMBER_OFFSET("cpuinfo_x86", "x86_model_id"); > buf = GETBUF(XEN_HYPER_SIZE(cpuinfo_x86)); > if (xen_hyper_test_pcpu_id(XEN_HYPER_CRASHING_CPU())) { > @@ -1746,9 +1748,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; /* hypervisor does not have uptime */ > } > > return jiffies_64; > --- xen_hyper_command.c.org 2008-10-07 08:05:37.000000000 +0900 > +++ xen_hyper_command.c 2008-10-07 08:24:29.000000000 +0900 > @@ -1022,7 +1022,8 @@ > (buf1, "%d\n", XEN_HYPER_NR_DOMAINS())); > /* !!!Display a date here if it can be found. */ > XEN_HYPER_PRI(fp, len, "UPTIME: ", buf1, flag, > - (buf1, "%s\n", convert_time(xen_hyper_get_uptime_hyper(), buf2))); > + (buf1, "%s\n", (xen_hyper_get_uptime_hyper() ? > + convert_time(xen_hyper_get_uptime_hyper(), buf2) : "--:--:--"))); > /* !!!Display a version here if it can be found. */ > XEN_HYPER_PRI_CONST(fp, len, "MACHINE: ", flag); > if (strlen(uts->machine)) { > ---_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Oct-07 13:55 UTC
Re: [Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0
On 7/10/08 14:39, "Dave Anderson" <anderson@redhat.com> wrote:> The patch looks OK. But just for sanity''s sake, is it guaranteed that > the per_cpu data section will be greater than 4k on both architectures? > Or could there be some combination of xen CONFIG options that could > reduce the i386 per_cpu data section contents to less than 4K even though > PERCPU_SHIFT is 13?PERCPU_SHIFT has only ever been 12 or 13 so far, and it''s unlikely to ever get smaller. Ongoing, we could help you out by defining some useful label in our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or ''__per_cpu_start + PERCPU_SHIFT'', as I''m not sure about creating labels outside the virtual address ranges defined by the object file). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dave Anderson
2008-Oct-07 14:35 UTC
Re: [Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0
Keir Fraser wrote:> On 7/10/08 14:39, "Dave Anderson" <anderson@redhat.com> wrote: > >> The patch looks OK. But just for sanity''s sake, is it guaranteed that >> the per_cpu data section will be greater than 4k on both architectures? >> Or could there be some combination of xen CONFIG options that could >> reduce the i386 per_cpu data section contents to less than 4K even though >> PERCPU_SHIFT is 13? > > PERCPU_SHIFT has only ever been 12 or 13 so far, and it''s unlikely to ever > get smaller. Ongoing, we could help you out by defining some useful label in > our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or > ''__per_cpu_start + PERCPU_SHIFT'', as I''m not sure about creating labels > outside the virtual address ranges defined by the object file). > > -- KeirYep, that''s fine too, but for now Oda-san''s patch will suffice now as long as the smallest possible percpu data section on the x86 arch with a PERCPU_SHIFT of 13 will always overflow into a space greater than 4k. So I''m still curious, because I note that on a RHEL5 x86_64 hypervisor the per-cpu data space is 1576 bytes, and presumably smaller on an x86. Was there a new data structure that forced the issue? And does it force the issue on both arches? Dave _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Oct-07 15:01 UTC
Re: [Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0
On 7/10/08 15:35, "Dave Anderson" <anderson@redhat.com> wrote:>> PERCPU_SHIFT has only ever been 12 or 13 so far, and it''s unlikely to ever >> get smaller. Ongoing, we could help you out by defining some useful label in >> our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or >> ''__per_cpu_start + PERCPU_SHIFT'', as I''m not sure about creating labels >> outside the virtual address ranges defined by the object file). >> >> -- Keir > > Yep, that''s fine too, but for now Oda-san''s patch will suffice now as > long as the smallest possible percpu data section on the x86 arch with > a PERCPU_SHIFT of 13 will always overflow into a space greater than 4k. > So I''m still curious, because I note that on a RHEL5 x86_64 hypervisor > the per-cpu data space is 1576 bytes, and presumably smaller on an x86. > Was there a new data structure that forced the issue? And does it force > the issue on both arches?PERCPU_SHIFT has to be big enough that the per-cpu data area happens to be smaller than 1<<PERCPU_SHIFT bytes. This relationship is not enforced at build time but we BUG_ON() it early during boot. Indeed at some point during 3.3 development some big structs got dumped in the per-cpu area and increased its size beyond 2^12. Hence we BUG()ed and hence we bumped to 2^13. What this does mean is that we might, on some builds, actually have data area < 4kB even while we have PERCPU_SHIFT==13. I think it''s unlikely in practice though since I believe we''re well over the 4kB boundary now. I don''t think Xen/ia64 uses this same implementation technique. It''s probably more like Linux''s percpu data area implementation. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Itsuro ODA
2008-Oct-07 22:33 UTC
[Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0
Hi, It is a good question. I checked about i386. __per_cpu_data_end - __per_cpu_start is smaller than 4K, but PERCPU_SHIFT is 13 (it is common both x86_32 and x86_64). Oops. I will consider more. Thanks Itsuro Oda On Tue, 07 Oct 2008 09:39:05 -0400 Dave Anderson <anderson@redhat.com> wrote:> Itsuro ODA wrote: > > Hi, > > > > This patch is for xen hypervisor analysis function of the > > crash command to apply to the xen-3.3.0 (the newest version of xen). > > > > * PERCPU_SHIFT becomes 13 (from 12) in the xen-3.3.0. > > This value is calculated from "__per_cpu_start" and "__per_cpu_data_end". > > * "jiffies" does not exist in the xen-3.3.0. > > It was used to show the uptime. I found there is no altanernative > > (i.e. the xen hypervisor does not have the uptime.). > > Then if "jiffies" does not exist, "--:--:--" is showed as UPTIME in > > the sys command. > > (Is it better to eliminate the whole UPTIME line ?) > > --- example --- > > crash> sys > > KERNEL: xen-syms > > DUMPFILE: vmcore > > CPUS: 4 > > DOMAINS: 5 > > UPTIME: --:--:-- > > MACHINE: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2660 Mhz) > > MEMORY: 2 GB > > ---------------- > > > > This patch is for crash-4.0-7.2. > > > > Thanks > > Itsuro Oda > > The patch looks OK. But just for sanity''s sake, is it guaranteed that > the per_cpu data section will be greater than 4k on both architectures? > Or could there be some combination of xen CONFIG options that could > reduce the i386 per_cpu data section contents to less than 4K even though > PERCPU_SHIFT is 13? > > Dave > > > > > --- > > --- xen_hyper_defs.h.org 2008-10-06 13:45:39.000000000 +0900 > > +++ xen_hyper_defs.h 2008-10-06 13:44:44.000000000 +0900 > > @@ -134,9 +134,8 @@ > > #endif > > > > #if defined(X86) || defined(X86_64) > > -#define XEN_HYPER_PERCPU_SHIFT 12 > > #define xen_hyper_per_cpu(var, cpu) \ > > - ((ulong)(var) + (((ulong)(cpu))<<XEN_HYPER_PERCPU_SHIFT)) > > + ((ulong)(var) + (((ulong)(cpu))<<xht->percpu_shift)) > > #elif defined(IA64) > > #define xen_hyper_per_cpu(var, cpu) \ > > ((xht->flags & XEN_HYPER_SMP) ? \ > > @@ -404,6 +403,7 @@ > > ulong *cpumask; > > uint *cpu_idxs; > > ulong *__per_cpu_offset; > > + int percpu_shift; > > }; > > > > struct xen_hyper_dumpinfo_context { > > --- xen_hyper.c.org 2008-10-06 13:41:14.000000000 +0900 > > +++ xen_hyper.c 2008-10-06 14:15:03.000000000 +0900 > > @@ -71,6 +71,8 @@ > > #endif > > > > #if defined(X86) || defined(X86_64) > > + xht->percpu_shift > > + (symbol_value("__per_cpu_data_end") - symbol_value("__per_cpu_start") > 4096) ? 13: 12; > > member_offset = MEMBER_OFFSET("cpuinfo_x86", "x86_model_id"); > > buf = GETBUF(XEN_HYPER_SIZE(cpuinfo_x86)); > > if (xen_hyper_test_pcpu_id(XEN_HYPER_CRASHING_CPU())) { > > @@ -1746,9 +1748,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; /* hypervisor does not have uptime */ > > } > > > > return jiffies_64; > > --- xen_hyper_command.c.org 2008-10-07 08:05:37.000000000 +0900 > > +++ xen_hyper_command.c 2008-10-07 08:24:29.000000000 +0900 > > @@ -1022,7 +1022,8 @@ > > (buf1, "%d\n", XEN_HYPER_NR_DOMAINS())); > > /* !!!Display a date here if it can be found. */ > > XEN_HYPER_PRI(fp, len, "UPTIME: ", buf1, flag, > > - (buf1, "%s\n", convert_time(xen_hyper_get_uptime_hyper(), buf2))); > > + (buf1, "%s\n", (xen_hyper_get_uptime_hyper() ? > > + convert_time(xen_hyper_get_uptime_hyper(), buf2) : "--:--:--"))); > > /* !!!Display a version here if it can be found. */ > > XEN_HYPER_PRI_CONST(fp, len, "MACHINE: ", flag); > > if (strlen(uts->machine)) { > > --- > > > > > -- > Crash-utility mailing list > Crash-utility@redhat.com > https://www.redhat.com/mailman/listinfo/crash-utility-- Itsuro ODA <oda@valinux.co.jp> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Itsuro ODA
2008-Oct-07 22:39 UTC
Re: [Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0
Hi, It is very helpful. Thanks Itsuro Oda On Tue, 07 Oct 2008 14:55:00 +0100 Keir Fraser <keir.fraser@eu.citrix.com> wrote:> On 7/10/08 14:39, "Dave Anderson" <anderson@redhat.com> wrote: > > > The patch looks OK. But just for sanity''s sake, is it guaranteed that > > the per_cpu data section will be greater than 4k on both architectures? > > Or could there be some combination of xen CONFIG options that could > > reduce the i386 per_cpu data section contents to less than 4K even though > > PERCPU_SHIFT is 13? > > PERCPU_SHIFT has only ever been 12 or 13 so far, and it''s unlikely to ever > get smaller. Ongoing, we could help you out by defining some useful label in > our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or > ''__per_cpu_start + PERCPU_SHIFT'', as I''m not sure about creating labels > outside the virtual address ranges defined by the object file). > > -- Keir > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel-- Itsuro ODA <oda@valinux.co.jp> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Itsuro ODA
2008-Oct-09 07:08 UTC
[Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0
Hi, I decided to use the version number of xen which is included in the XEN_ELFNOTE_CRASH_INFO after all. The defect is that vmcores taken on the xen-unstable during the xen-3.3 development before the changset 17831 (2008/6/12) can not be analized with the newer crash. I think it is not a big problem since it is rare case to analyze such vmcores right now. On Wed, 8 Oct 2008 08:56:48 -0400 (EDT) Dave Anderson <anderson@redhat.com> wrote:> > ----- "Itsuro ODA" <oda@valinux.co.jp> wrote: > > > Hi, > > > > It is a good question. > > I checked about i386. __per_cpu_data_end - __per_cpu_start is smaller > > than 4K, but PERCPU_SHIFT is 13 (it is common both x86_32 and > > x86_64). > > Oops. > > > > I will consider more. > > Ok, I''ll wait for a new patch set. > > Another direction that you might consider is to check whether > a new symbol was introduced in the same patch-set that > incremented the PERCPU_SHIFT values?I found this is equivalent as using "__per_cpu_data_end - __per_cpu_start > 4K" since the change of the PERCPU_SHIFT was for x86_64 only and it was not helpful for i386.> Or take Keir up on his offer to compile-in an absolute > value that can be accessed like a symbol?It is checked first in the patch.> As far as the UPTIME display, it will probably raise > fewer questions in the future if you would just remove > it entirely. > > Thanks, > Dave >* PERCPU_SHIFT becomes 13 (from 12) in the xen-3.3.0. This value is determined by xen version number. (If the symbol "__per_cpu_shift" exists, it is used first for the future.) * "jiffies" does not exist in the xen-3.3.0. It was used to show the uptime. I found there is no altanernative (i.e. the xen hypervisor does not have the uptime.). Then if "jiffies" does not exist, "--:--:--" is showed as UPTIME in the sys command. --- example --- crash> sys KERNEL: xen-syms DUMPFILE: vmcore CPUS: 4 DOMAINS: 5 UPTIME: --:--:-- MACHINE: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2660 Mhz) MEMORY: 2 GB ---------------- This patch is for crash-4.0-7.2. Thanks Itsuro Oda --- --- defs.h.org 2008-10-09 09:25:11.000000000 +0900 +++ defs.h 2008-10-09 09:53:53.000000000 +0900 @@ -4118,6 +4118,8 @@ int is_sadump_xen(void); void set_xen_phys_start(char *); ulong xen_phys_start(void); +int xen_major_version(void); +int xen_minor_version(void); /* * diskdump.c --- netdump.h.org 2008-10-09 09:25:03.000000000 +0900 +++ netdump.h 2008-10-09 09:49:26.000000000 +0900 @@ -110,6 +110,8 @@ int p2m_frames; ulong *p2m_mfn_frame_list; ulong xen_phys_start; + int xen_major_version; + int xen_minor_version; }; #define KDUMP_P2M_INIT (0x1) --- netdump.c.org 2008-10-09 09:24:54.000000000 +0900 +++ netdump.c 2008-10-09 09:53:20.000000000 +0900 @@ -1525,6 +1525,8 @@ nd->xen_kdump_data->p2m_mfn = *(uptr+(words-1)); if (words > 9 && !nd->xen_kdump_data->xen_phys_start) nd->xen_kdump_data->xen_phys_start = *(uptr+(words-2)); + nd->xen_kdump_data->xen_major_version = *uptr; + nd->xen_kdump_data->xen_minor_version = *(uptr+1); } } break; @@ -1730,6 +1732,8 @@ nd->xen_kdump_data->p2m_mfn = *(up+(words-1)); if (words > 9 && !nd->xen_kdump_data->xen_phys_start) nd->xen_kdump_data->xen_phys_start = *(up+(words-2)); + nd->xen_kdump_data->xen_major_version = *up; + nd->xen_kdump_data->xen_minor_version = *(up+1); } } break; @@ -2343,3 +2347,15 @@ { return nd->xen_kdump_data->xen_phys_start; } + +int +xen_major_version(void) +{ + return nd->xen_kdump_data->xen_major_version; +} + +int +xen_minor_version(void) +{ + return nd->xen_kdump_data->xen_minor_version; +} --- xen_hyper_defs.h.org 2008-10-06 13:45:39.000000000 +0900 +++ xen_hyper_defs.h 2008-10-06 13:44:44.000000000 +0900 @@ -134,9 +134,8 @@ #endif #if defined(X86) || defined(X86_64) -#define XEN_HYPER_PERCPU_SHIFT 12 #define xen_hyper_per_cpu(var, cpu) \ - ((ulong)(var) + (((ulong)(cpu))<<XEN_HYPER_PERCPU_SHIFT)) + ((ulong)(var) + (((ulong)(cpu))<<xht->percpu_shift)) #elif defined(IA64) #define xen_hyper_per_cpu(var, cpu) \ ((xht->flags & XEN_HYPER_SMP) ? \ @@ -404,6 +403,7 @@ ulong *cpumask; uint *cpu_idxs; ulong *__per_cpu_offset; + int percpu_shift; }; struct xen_hyper_dumpinfo_context { --- xen_hyper.c.org 2008-10-06 13:41:14.000000000 +0900 +++ xen_hyper.c 2008-10-09 11:31:24.000000000 +0900 @@ -71,6 +71,13 @@ #endif #if defined(X86) || defined(X86_64) + if (symbol_exists("__per_cpu_shift")) { + xht->percpu_shift = (int)symbol_value("__per_cpu_shift"); + } else if (xen_major_version() >= 3 && xen_minor_version() >= 3) { + xht->percpu_shift = 13; + } else { + xht->percpu_shift = 12; + } member_offset = MEMBER_OFFSET("cpuinfo_x86", "x86_model_id"); buf = GETBUF(XEN_HYPER_SIZE(cpuinfo_x86)); if (xen_hyper_test_pcpu_id(XEN_HYPER_CRASHING_CPU())) { @@ -1746,9 +1753,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; /* hypervisor does not have uptime */ } return jiffies_64; --- xen_hyper_command.c.org 2008-10-07 08:05:37.000000000 +0900 +++ xen_hyper_command.c 2008-10-07 08:24:29.000000000 +0900 @@ -1022,7 +1022,8 @@ (buf1, "%d\n", XEN_HYPER_NR_DOMAINS())); /* !!!Display a date here if it can be found. */ XEN_HYPER_PRI(fp, len, "UPTIME: ", buf1, flag, - (buf1, "%s\n", convert_time(xen_hyper_get_uptime_hyper(), buf2))); + (buf1, "%s\n", (xen_hyper_get_uptime_hyper() ? + convert_time(xen_hyper_get_uptime_hyper(), buf2) : "--:--:--"))); /* !!!Display a version here if it can be found. */ XEN_HYPER_PRI_CONST(fp, len, "MACHINE: ", flag); if (strlen(uts->machine)) { --- -- Itsuro ODA <oda@valinux.co.jp> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel