----- Original Message ----- > 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 just did some basic commands, and I didn't see any other problems besides the log/conring issue. But I don't really have a good test suite for the Xen hypervisor options. And honestly, I've never even seen a "real" hypervisor crash dump, I just have a few forced samples. If you'd like, I can give you a pointer to a really early RHEL5.2-era (2.6.18-89.el5) xen-syms/vmcore pair that you can use to verify your changes on if you don't have any dumps of that era available. > > 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 No problem, I'll just wait for your v2 set. Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility