Re: [Crash-utility] [PATCH] Remove struct domain::is_polling
by Dave Anderson
Hi Bernhard,
Looks fine to me, although I'd prefer to continue to print
the "-1" in xen_hyper_dump_xen_hyper_offset_table(), the
same way that "help -o" does for all the Linux offsets.
CC'ing the xencrash maintainer Itsuro Oda to get his ACK.
Thanks,
Dave
----- "Bernhard Walle" <bwalle(a)suse.de> wrote:
> According to that change set in the Xen unstable branch
>
> changeset: 18428:ae9b223a675d
> user: Keir Fraser <keir.fraser(a)citrix.com>
> date: Thu Sep 04 14:38:26 2008 +0100
> files: xen/common/domain.c
> xen/common/event_channel.c
> xen/common/schedule.c
> xen/include/xen/sched.h
> description:
> More efficient implementation of SCHEDOP_poll when polling a
> single port.
> Signed-off-by: Keir Fraser <keir.fraser(a)citrix.com>
>
> the member "is_polling" of struct domain will be removed in Xen 4.4.
> This patch fixes the problem that a dump cannot be opened in
> Hypervisor mode in
> crash when produced by such a Xen version. That's the error message of
> Crash:
>
> crash: invalid structure member offset: domain_is_polling
> FILE: xen_hyper.c LINE: 1182 FUNCTION:
> xen_hyper_store_domain_context()
>
> [./crash] error trace: 52bfc2 => 52e401 => 52ee07 => 508062
>
> 508062: OFFSET_verify+168
> 52ee07: xen_hyper_store_domain_context+742
> 52e401: xen_hyper_refresh_domain_context_space+196
> 52bfc2: xen_hyper_domain_init+959
>
>
> Signed-off-by: Bernhard Walle <bwalle(a)suse.de>
>
> ---
> xen_hyper.c | 9 ++++++++-
> xen_hyper_dump_tables.c | 6 ++++--
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> --- a/xen_hyper.c
> +++ b/xen_hyper.c
> @@ -188,7 +188,13 @@ xen_hyper_domain_init(void)
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_hvm, "domain", "is_hvm");
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_privileged, "domain",
> "is_privileged");
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_debugger_attached, "domain",
> "debugger_attached");
> +
> + /*
> + * Will be removed in Xen 4.4 (hg ae9b223a675d),
> + * need to check that with XEN_HYPER_VALID_MEMBER() before using
> + */
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_polling, "domain",
> "is_polling");
> +
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_dying, "domain",
> "is_dying");
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_paused_by_controller,
> "domain", "is_paused_by_controller");
> XEN_HYPER_MEMBER_OFFSET_INIT(domain_is_shutting_down, "domain",
> "is_shutting_down");
> @@ -1179,7 +1185,8 @@ xen_hyper_store_domain_context(struct xe
> dc->domain_flags |= XEN_HYPER_DOMS_privileged;
> } else if (*(dp + XEN_HYPER_OFFSET(domain_debugger_attached))) {
> dc->domain_flags |= XEN_HYPER_DOMS_debugging;
> - } else if (*(dp + XEN_HYPER_OFFSET(domain_is_polling))) {
> + } else if (XEN_HYPER_VALID_MEMBER(domain_is_polling) &&
> + *(dp + XEN_HYPER_OFFSET(domain_is_polling))) {
> dc->domain_flags |= XEN_HYPER_DOMS_polling;
> } else if (*(dp +
> XEN_HYPER_OFFSET(domain_is_paused_by_controller))) {
> dc->domain_flags |= XEN_HYPER_DOMS_ctrl_pause;
> --- a/xen_hyper_dump_tables.c
> +++ b/xen_hyper_dump_tables.c
> @@ -775,8 +775,10 @@ xen_hyper_dump_xen_hyper_offset_table(ch
> (buf, "%ld\n", xen_hyper_offset_table.domain_is_privileged));
> XEN_HYPER_PRI(fp, len, "domain_debugger_attached: ", buf, flag,
> (buf, "%ld\n", xen_hyper_offset_table.domain_debugger_attached));
> - XEN_HYPER_PRI(fp, len, "domain_is_polling: ", buf, flag,
> - (buf, "%ld\n", xen_hyper_offset_table.domain_is_polling));
> + if (XEN_HYPER_VALID_MEMBER(domain_is_polling)) {
> + XEN_HYPER_PRI(fp, len, "domain_is_polling: ", buf, flag,
> + (buf, "%ld\n", xen_hyper_offset_table.domain_is_polling));
> + }
> XEN_HYPER_PRI(fp, len, "domain_is_dying: ", buf, flag,
> (buf, "%ld\n", xen_hyper_offset_table.domain_is_dying));
> XEN_HYPER_PRI(fp, len, "domain_is_paused_by_controller: ", buf,
> flag,
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
15 years, 8 months
- 2
- 1
"crash: cannot allocate any more memory!" for 2.6.27.4
by Dheeraj Sangamkar
Hi,
I am able to use crash to debug a crash dump generated when I initiate the
crash using the sysrq-trigger in the /proc directory.
But when I try to use crash to debug a kernel vmcore generated due to the
insertion of my module, I get the error below.
Please let me know if I am doing anything wrong or if you think that the
dump is corrupted. I use kdump for dump collection.
I am using a 2.6.27.4-2-default kernel.
---------------------------------------------------------------------------------------------------------------------------------
/var/crash/2008-12-01-18:40 # crash System.map-default vmlinux vmcore
crash 4.0-7.4
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
please wait... (gathering module symbol data) buf_1K_used: 299
buf_2K_used: 1
buf_4K_used: 155
buf_8K_used: 1
buf_32K_used: 2
buf_1K_ovf: 0
buf_2K_ovf: 0
buf_4K_ovf: 0
buf_8K_ovf: 0
buf_32K_ovf: 0
buf_1K_maxuse: 2 of 10
buf_2K_maxuse: 1 of 10
buf_4K_maxuse: 1 of 5
buf_8K_maxuse: 1 of 5
buf_32K_maxuse: 1 of 1
buf_inuse[5]: [0][0][0][0][1]
smallest: 16
largest: 21474854400
embedded: 2
max_embedded: 2
mallocs: 0
frees: 0
reqs/total: 459/21475603516.0
average size: 46787807.2
crash: cannot allocate any more memory!
---------------------------------------------------------------------------------------------------------------------------------
Thanks in advance,
Dheeraj
--
Simplicity of character is the natural result of profound thought.
15 years, 8 months
- 1
- 0