>> On 05.07.12 at 17:00, Daniel Kiper <daniel.kiper(a)oracle.com&gt; wrote: max_cpus is not available since 20374 changeset (Miscellaneous data placement adjustments). It was moved to __initdata section. This section is freed after Xen initialization. Assume that max_cpus is always equal to XEN_HYPER_SIZE(cpumask_t) * 8.

Signed-off-by: Daniel Kiper <daniel.kiper(a)oracle.com&gt; diff -Npru crash-6.0.8.orig/xen_hyper.c crash-6.0.8/xen_hyper.c --- crash-6.0.8.orig/xen_hyper.c 2012-06-29 16:59:18.000000000 +0200 +++ crash-6.0.8/xen_hyper.c 2012-07-05 14:52:59.000000000 +0200 @@ -1879,11 +1879,9 @@ xen_hyper_get_cpu_info(void) uint *cpu_idx; int i, j, cpus; - get_symbol_data("max_cpus", sizeof(xht->max_cpus), &xht->max_cpus); XEN_HYPER_STRUCT_SIZE_INIT(cpumask_t, "cpumask_t"); - if (XEN_HYPER_SIZE(cpumask_t) * 8 > xht->max_cpus) { - xht->max_cpus = XEN_HYPER_SIZE(cpumask_t) * 8; - } + xht->max_cpus = XEN_HYPER_SIZE(cpumask_t) * 8; + if (xht->cpumask) { free(xht->cpumask); } _______________________________________________ Xen-devel mailing list Xen-devel(a)lists.xen.org http://lists.xen.org/xen-devel

----- Original Message ----- > > > ----- Original Message ----- > > On Thu, Jul 05, 2012 at 05:29:50PM +0200, Daniel Kiper wrote: > > > On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > > Hi, > > > > > > > > > > It looks that Xen support for crash have not been maintained > > > > > since 2009. I am trying to fix this. Here it is small > > > > > bundle of fixes: > > > > > - xen: Always calculate max_cpus value, > > > > > - xen: Read only crash notes for onlined CPUs, > > > > > - x86/xen: Read variables from dynamically allocated per_cpu data, > > > > > - xen: Get idle data from alternative source, > > > > > - xen: Read data correctly from dynamically allocated console ring too. > > > > > > > > > > Daniel > > > > > > > > Daniel, > > > > > > > > Can you absolutely confirm that these changes are all > > > > backwards-compatible? > > > > > > I have not done tests with older versions of Xen. However, > > > I made all patches with backward compatibility in mind. Anyway, > > > If you wish I could do tests with let's say Xen Ver. 3.4 > > > and Xen Linux Kernel Ver. 2.6.18 at least. > > > > I think Dave is worried about it breaking with the version that is bundled > > with RHEL5U8? > > Correct... > > Dave > And as it turns out, it does break RHEL5 xen, at least the changes you made for the log command: crash> log log: invalid kernel virtual address: 616e69625f64616f type: "conring contents" crash>

On Thu, Jul 12, 2012 at 03:47:57PM -0400, Dave Anderson wrote: > > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > > > > > > > ----- Original Message ----- > > > > On Thu, Jul 05, 2012 at 05:29:50PM +0200, Daniel Kiper wrote: > > > > > On Thu, Jul 05, 2012 at 11:15:29AM -0400, Dave Anderson > > > > > wrote: > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > Hi, > > > > > > > > > > > > > > It looks that Xen support for crash have not been > > > > > > > maintained > > > > > > > since 2009. I am trying to fix this. Here it is small > > > > > > > bundle of fixes: > > > > > > > - xen: Always calculate max_cpus value, > > > > > > > - xen: Read only crash notes for onlined CPUs, > > > > > > > - x86/xen: Read variables from dynamically allocated > > > > > > > per_cpu data, > > > > > > > - xen: Get idle data from alternative source, > > > > > > > - xen: Read data correctly from dynamically allocated > > > > > > > console ring too. > > > > > > > > > > > > > > Daniel > > > > > > > > > > > > Daniel, > > > > > > > > > > > > Can you absolutely confirm that these changes are all > > > > > > backwards-compatible? > > > > > > > > > > I have not done tests with older versions of Xen. However, > > > > > I made all patches with backward compatibility in mind. > > > > > Anyway, > > > > > If you wish I could do tests with let's say Xen Ver. 3.4 > > > > > and Xen Linux Kernel Ver. 2.6.18 at least. > > > > > > > > I think Dave is worried about it breaking with the version > > > > that is bundled > > > > with RHEL5U8? > > > > > > Correct... > > > > > > Dave > > > > > > > And as it turns out, it does break RHEL5 xen, at least the > > changes > > you made for the log command: > > > > crash> log > > log: invalid kernel virtual address: 616e69625f64616f type: > > "conring contents" > > crash> > > > > Daniel, > > Your patch breaks the RHEL5 xen hypervisor log command because "conring" used > to be declared as a statically-sized array: > > crash> whatis conring > char conring[16384]; > crash> > > It appears from your patch that "conring" is now declared as a pointer, > given that your patch does this: > > --- crash-6.0.8.orig/xen_hyper_command.c 2012-06-29 > 16:59:18.000000000 +0200 > +++ crash-6.0.8/xen_hyper_command.c 2012-07-05 > 16:22:35.000000000 +0200 > @@ -590,24 +590,31 @@ xen_hyper_dump_log(void) > ulong conring; > char *buf; > char last; > + uint32_t conring_size; > > - conring = symbol_value("conring"); > + get_symbol_data("conring", sizeof(ulong), &conring); > get_symbol_data("conringc", sizeof(uint), &conringc); > get_symbol_data("conringp", sizeof(uint), &conringp); > ... > > If I change your patch such that the end result looks like this: > > if (get_symbol_type("conring", NULL, NULL) == > TYPE_CODE_ARRAY) > conring = symbol_value("conring"); > else > get_symbol_data("conring", sizeof(ulong), > &conring); > > it works for RHEL5 xen hypervisor. > > Does that work for you? Thanks. It works. I though that there is an issue with conring symbol too. Have you done other tests on RHEL5?

I discoverd additional crash issue with Xen core dumps. I am working on fix for that. I would like to add relevant patch for next release of this bundle of patches. I am going to do all tests for new release (probably next week). Is it OK for you? Daniel