crash: Small bundle of fixes for Xen
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? -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility |
crash: Small bundle of fixes for Xen
----- 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 -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility |
crash: Small bundle of fixes for Xen
----- 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> Dave -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility |
crash: Small bundle of fixes for Xen
----- 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? Dave -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility |
crash: Small bundle of fixes for Xen
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 -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility |
crash: Small bundle of fixes for Xen
----- 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@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility |
crash: Small bundle of fixes for Xen
On Fri, Jul 13, 2012 at 09:31:37AM -0400, Dave Anderson wrote:
> > > ----- Original Message ----- > > On Thu, Jul 12, 2012 at 03:47:57PM -0400, Dave Anderson wrote: [...] > > > 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 Our support team is going to use this feature more widely. It looks that we will have good testbed for Xen crash support. > 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. Yes please. It will be very helpful. Daniel -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility |
crash: Small bundle of fixes for Xen
----- Original Message -----
> On Fri, Jul 13, 2012 at 09:31:37AM -0400, Dave Anderson wrote: > > > > > > ----- Original Message ----- > > > On Thu, Jul 12, 2012 at 03:47:57PM -0400, Dave Anderson wrote: > > [...] > > > > > 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 > > Our support team is going to use this feature more widely. > It looks that we will have good testbed for Xen crash support. > > > 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. > > Yes please. It will be very helpful. Here's one: http://people.redhat.com/anderson/xen-5.2-dump.tar.gz It's really old -- it needs the --xen_phys_start 0x3f000000 command line option because that version didn't pass the phys_start location in the dumpfile. Thanks, Dave -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility |
crash: Small bundle of fixes for Xen
On Fri, Jul 13, 2012 at 10:37:19AM -0400, Dave Anderson wrote:
> > > ----- Original Message ----- > > On Fri, Jul 13, 2012 at 09:31:37AM -0400, Dave Anderson wrote: > > > > > > > > > ----- Original Message ----- > > > > On Thu, Jul 12, 2012 at 03:47:57PM -0400, Dave Anderson wrote: > > > > [...] > > > > > > > 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 > > > > Our support team is going to use this feature more widely. > > It looks that we will have good testbed for Xen crash support. > > > > > 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. > > > > Yes please. It will be very helpful. > > Here's one: > > http://people.redhat.com/anderson/xen-5.2-dump.tar.gz > > It's really old -- it needs the --xen_phys_start 0x3f000000 command line > option because that version didn't pass the phys_start location in the > dumpfile. Thanks. I have downloaded it. Daniel -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility |
| All times are GMT. The time now is 03:24 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.