[PATCH] Remove struct domain::is_polling
by Bernhard Walle
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,
15 years, 8 months
Implement end_pfn -> max_pfn change for Xen dumps
by Bernhard Walle
This patch reflects the change from end_pfn to max_pfn in x86_64
mainline between 2.6.26 and 2.6.27 that already has been partitially
implemented in x86_64_init(PRE_GDB):
...
if (kernel_symbol_exists("end_pfn"))
/* 2.6.11 layout */
machdep->machspec->page_offset = PAGE_OFFSET_2_6_11;
else
/* 2.6.27 layout */
machdep->machspec->page_offset = PAGE_OFFSET_2_6_27;
...
also for Xen Dom0 dumps (not in HV mode).
Signed-off-by: Bernhard Walle <bwalle(a)suse.de>
---
kernel.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/kernel.c
+++ b/kernel.c
@@ -102,8 +102,14 @@ kernel_init()
}
if (machine_type("X86"))
get_symbol_data("max_pfn", sizeof(ulong), &kt->p2m_table_size);
- if (machine_type("X86_64"))
- get_symbol_data("end_pfn", sizeof(ulong), &kt->p2m_table_size);
+ if (machine_type("X86_64")) {
+ /*
+ * kernel version < 2.6.27 => end_pfn
+ * kernel version >= 2.6.27 => max_pfn
+ */
+ if (!try_get_symbol_data("end_pfn", sizeof(ulong), &kt->p2m_table_size))
+ get_symbol_data("max_pfn", sizeof(ulong), &kt->p2m_table_size);
+ }
if ((kt->m2p_page = (char *)malloc(PAGESIZE())) == NULL)
error(FATAL, "cannot malloc m2p page.");
}
15 years, 8 months
Re: [Crash-utility] Crash Setup
by Dave Anderson
----- "ADITYA KRISHNAN" <princeofporsche(a)gmail.com> wrote:
> Hi,
> Thanks for the help and guidance, I downloaded and ran the latest
> version of crash. it gives me the following output:
>
>
> 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"...(no debugging
> symbols found)...
>
>
> crash: /boot/vmlinux-syms-2.6.16.13-xen: no debugging data available
>
>
> On running gdb /boot/vmlinux-syms-2.6.16.13-xen i got the following
> output:
>
>
>
> 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"...(no debugging
> symbols found)...
>
>
> crash: /boot/vmlinux-syms-2.6.16.13-xen: no debugging data available
>
>
>
>
> GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
> 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-redhat-linux-gnu"...
> (no debugging symbols found)
> Using host libthread_db library "/lib64/libthread_db.so.1".
>
>
> (gdb)
>
>
> The common point being debug info was not found. But when running
> crash it says GDB was configured as "x86_64-unknown-linux-gnu" and
> when running only gdb it says GDB was configured as
> "x86_64-redhat-linux-gnu"
The lack of debuginfo is the only issue. The "configured as..." message
is irrelevant, as long as the machine type x86_64 is correct.
>
> This may be a stupid question... but am I right in assuming that crash
> will now run if I compile xen again with -g option ?
That should be correct. I don't know how your "vmlinux-syms-2.6.16.13-xen"
kernel was built, but it's surprising to me that it's got the "syms" string
in its name, but was built without -g. But the "(no debugging symbols found)"
message from gdb is proof of that.
When xensource builds their hypervisor binary, it's debuginfo-full version
is called "xen-syms". I would have thought the same would apply to your vmlinux
kernel, but I don't know what distribution/procedure is responsible for creating
your vmlinux file?
Dave
15 years, 8 months
Re: 32 bit linux-2.6.24-git8 user_regs_structchange breaks opening kdump crashfiles
by Dave Anderson
----- "Joe Porter" <joe.porter(a)ccur.com> wrote:
> On Tue, 2008-11-18 at 14:05 -0500, Dave Anderson wrote:
> > Hi Joe,
> >
> > Can you verify that the attached patch works with your kdump?
> >
> > Thanks,
> > Dave
> >
>
> Hi Dave,
>
> The 2.6.25 kernel I built using "make defconfig" DID NOT exhibit this
> bug.
>
> The 2.6.25 kernel I built using "make oldconfig" DOES have the bug.
>
> So this could happen in any distro with the right combination of
> kernel config options
> (I would think after 2.6.25).
>
> I'll see if I can work out what options trigger this.
>
> I suspect it's either the CPU optimization choice or some SMP or
> real-timey option.
>
> I'll let you know what I find out.
>
> In the meantime your patch was sufficient to get around this.
Excellent -- thanks for your patience and time spent on this.
The fix is queued for the next release.
Thanks,
Dave
>
>
> Below I show crash-4.0-7.4 failing and then your patched
> crash-4.0-7.4:
>
>
> [root@beebo 11-18-08.1647.31]# /usr/src/crash-4.0-7.4.orig/crash
> vmcore vmlinux
>
> 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 "i686-pc-linux-gnu"...
>
> please wait... (determining panic task)
> crash: invalid structure member offset: user_regs_struct_ebp
> FILE: netdump.c LINE: 687 FUNCTION: get_netdump_panic_task()
>
> [/usr/src/crash-4.0-7.4.orig/crash] error trace: 80e0a0d => 8154325 =>
> 814fe0b => 813ec91
>
> 813ec91: OFFSET_verify+126
> 814fe0b: get_netdump_panic_task+1196
> 8154325: get_kdump_panic_task+11
> 80e0a0d: get_dumpfile_panic_task+153
>
> [root@beebo 11-18-08.1647.31]#
>
> -----------------------------------------------------------------------------------------
>
> [root@beebo 11-18-08.1647.31]# /usr/src/crash-4.0-7.4.patched/crash
> vmcore vmlinux
>
> 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 "i686-pc-linux-gnu"...
>
> KERNEL: vmlinux
> DUMPFILE: vmcore
> CPUS: 8
> DATE: Tue Nov 18 16:46:59 2008
> UPTIME: 00:01:30
> LOAD AVERAGE: 0.85, 0.33, 0.12
> TASKS: 148
> NODENAME: beebo
> RELEASE: 2.6.25-oldconfig
> VERSION: #1 SMP PREEMPT Tue Nov 18 16:31:40 EST 2008
> MACHINE: i686 (3657 Mhz)
> MEMORY: 4 GB
> PANIC: "SysRq : Trigger a crashdump"
> PID: 5504
> COMMAND: "crashme"
> TASK: f6f1b400 [THREAD_INFO: f7072000]
> CPU: 5
> STATE: TASK_RUNNING (SYSRQ)
>
> crash>
15 years, 8 months
Re: [Crash-utility] 32 bit linux-2.6.24-git8 user_regs_struct change breaks opening kdump crashfile
by Dave Anderson
----- "Joe Porter" <joe.porter(a)ccur.com> wrote:
> > Sorry -- I didn't make myself clear enough in my question.
>
> Hi Dave,
>
> Don't sweat it.
>
> If I had time to really look and think everything would make much
> more
> sense. ;)
>
> >
> > What I meant was: did the original code in the crash x86_init()
> > fall into the "if" clause here:
> >
> > if (!VALID_STRUCT(user_regs_struct)) {
> > /* Use this hardwired version -- sometimes
> the
> > * debuginfo doesn't pick this up even
> though
> > * it exists in the kernel; it shouldn't
> change.
> > */
> >
> > Since the offset values and structure size required shouldn't have
> changed
> > (even though the names did),
>
> I think I was ending up in the if statement ... trying to remember
> back
> to a couple of weeks ago.
>
> I never looked at the VALID_STRUCT code, but I wouldn't be surprised
> if
> it is failing ... see the gdb vmlinux output below. The data types
> are
> different and several members got joined up into the long unsigned
> ints.
The VALID_STRUCT() simply returns TRUE if the debuginfo is aware
of the user_regs_struct:
#define VALID_STRUCT(X) (size_table.X >= 0)
AIUI, if nothing in the kernel actually instantiates a declared data
structure, then it won't be placed in the debuginfo data of the vmlinux
file. At least that is what has happened over the years, hence the
addition of the "if !(VALID_STRUCT())" kludge in the crash utility.
When that happens, the structure size and the two offset values are
hardwired. And if they were hardwired, then you would not have seen
the error with the kdump.
>
> > I'm presuming that x86_init() did *not* fall
> > into that code, because if it did, the offsets and size values would
> have
> > been assigned, and you wouldn't have seen the ultimate error.
>
> OK
>
> > So my
> > guess is that the user_regs_struct *is* in the debuginfo of the new
> > kernel.
>
> I assumed that gdb knew about the structure.
Here's what happens on a RHEL5 2.6.18-based kernel:
# gdb /usr/lib/debug/lib/modules/2.6.18-92.el5/vmlinux
GNU gdb Red Hat Linux (6.5-37.el5rh)
Copyright (C) 2006 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-redhat-linux-gnu"...
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) ptype struct user_regs_struct
No struct type named user_regs_struct.
(gdb)
The above is an x86_64, but the same thing happens with an x86.
So with RHEL5 kernels, the "if" statement will be taken, and
the size/offset values get hardwired.
On your kdump, especially since your gdb attempts show that the
user_regs_struct debug data exists, then the values apparently were
not hardwired, because so you would *not* have entered the "if" clause.
In your case, the structure size would have been determined OK,
and therefore the VALID_STRUCT() would have subsequently worked.
But the two MEMBER_OFFSET_INIT() attempts would have failed quietly
because of the name change -- and later on the kdump attempt would
fail when it tried to use them.
>
> > That's what I'm trying to confirm here. In other words, if
> > you do this:
> >
> > # gdb vmlinux
> > ...
> > (gdb) ptype struct user_regs_struct
> >
> > does it know about the structure?
>
> Here you go (git8 then git7):
>
> # Linux kernel version: 2.6.24-git8
>
> [root@beebo 11-11-08.1814.44]# gdb vmlinux
> GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
> Copyright (C) 2006 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 "i386-redhat-linux-gnu"...Using host
> libthread_db library "/lib/libthread_db.so.1".
>
> (gdb) ptype struct user_regs_struct
> type = struct user_regs_struct {
> long unsigned int bx;
> long unsigned int cx;
> long unsigned int dx;
> long unsigned int si;
> long unsigned int di;
> long unsigned int bp;
> long unsigned int ax;
> long unsigned int ds;
> long unsigned int es;
> long unsigned int fs;
> long unsigned int gs;
> long unsigned int orig_ax;
> long unsigned int ip;
> long unsigned int cs;
> long unsigned int flags;
> long unsigned int sp;
> long unsigned int ss;
> }
> (gdb)
>
>
> # Linux kernel version: 2.6.24-git7
>
> [root@beebo 11-11-08.1750.38]# gdb vmlinux
> GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
> Copyright (C) 2006 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 "i386-redhat-linux-gnu"...Using host
> libthread_db library "/lib/libthread_db.so.1".
>
> (gdb) ptype struct user_regs_struct
> type = struct user_regs_struct {
> long int ebx;
> long int ecx;
> long int edx;
> long int esi;
> long int edi;
> long int ebp;
> long int eax;
> short unsigned int ds;
> short unsigned int __ds;
> short unsigned int es;
> short unsigned int __es;
> short unsigned int fs;
> short unsigned int __fs;
> short unsigned int gs;
> short unsigned int __gs;
> long int orig_eax;
> long int eip;
> short unsigned int cs;
> short unsigned int __cs;
> long int eflags;
> long int esp;
> short unsigned int ss;
> short unsigned int __ss;
> }
> (gdb)
>
>
>
> > If it does, then all the changes
> > you made in the "if" part of the patch are not required.
>
> Gotcha.
What is kind of strange is that nobody has reported this before.
By any chance does the Concurrent kernel add something that
actually instantiates a user_regs_struct?
>
>
> > The x86_64 would use x86_64_init() instead of x86_init(), so it's
> > irrelevant. And the x86_64 code doesn't care about those fields.
> >
>
> Understood.
>
>
> > I appreciate your time -- sorry to drag you down into my world.
> > (Please forgive an old "ccur.com" guy...)
>
> Original Concurrent or from the old Harris people?
>
>From the Westford MA branch of the "original" Concurrent (which was
actually created when Masscomp and Concurrent/New-Jersey merged).
Not long after the Harris/Concurrent merger, the Concurrent/Westford
office closed. (And I moved on to Digital)
> No forgiveness necessary ... crash is the best tool out there ... we
> should all thank you loudly.
>
> I'm the kdump/crash guy here, but I'm not allowed to spend much time
> on
> it ... I'm grateful it works as well as it does.
>
> I'm very busy on another project right now that has too much
> visibility
> at the top for me to appear to be doing much else.
>
> If you like, I can help out testing and providing feedback ... more
> when
> things calm down.
I'll post a patch that you can run a quick test with.
But just for my own sanity, can you verify that the failing crash
utility did *not* pass through the "if" kludge?
Thanks,
Dave
15 years, 8 months
Re: [Crash-utility] 32 bit linux-2.6.24-git8 user_regs_struct change breaks opening kdump crashfiles
by Dave Anderson
----- "Joe Porter" <joe.porter(a)ccur.com> wrote:
> On Mon, 2008-11-17 at 15:30 -0500, Dave Anderson wrote:
> > Does the new kernel that has the name changes end up using the
> > initial attempts to set the size, esp and ebp offsets? Or does
> > it always end up using the "if (!VALID_STRUCT())" section? It's
> > only going to use one or the other, depending upon whether the
> > user_regs_struct gets exported-to/included-in the debuginfo data.
>
> I did a binary search on all the kernels between 2.6.23 and
> 2.6.28-rc?.
>
> It was pretty clear that we were always going to get into this after
> 2.6.24-git8.
>
Hi Joe,
Sorry -- I didn't make myself clear enough in my question.
What I meant was: did the original code in the crash x86_init()
fall into the "if" clause here:
if (!VALID_STRUCT(user_regs_struct)) {
/* Use this hardwired version -- sometimes the
* debuginfo doesn't pick this up even though
* it exists in the kernel; it shouldn't change.
*/
Since the offset values and structure size required shouldn't have changed
(even though the names did), I'm presuming that x86_init() did *not* fall
into that code, because if it did, the offsets and size values would have
been assigned, and you wouldn't have seen the ultimate error. So my
guess is that the user_regs_struct *is* in the debuginfo of the new
kernel. That's what I'm trying to confirm here. In other words, if
you do this:
# gdb vmlinux
...
(gdb) ptype struct user_regs_struct
does it know about the structure? If it does, then all the changes
you made in the "if" part of the patch are not required.
> After I figured out the names changed, I didn't take it any further
> than
> what you see in the patch.
>
> When I dropped in the new x86_user_regs_struct, the code wouldn't
> build
> without making the two little changes to the MEMBER_OFFSET_INIT
> calls.
>
> There were a lot of related changes to the elf core code and also in
> the 64 bit user_regs_struct.
>
> I assume the 64 bit kdump crashfiles still work either because the
> crash
> initialization code differs or because the 32 bit elf core stuff
> changed
> to cause the !VALID_STRUCT() call to come back true.
The x86_64 would use x86_64_init() instead of x86_init(), so it's
irrelevant. And the x86_64 code doesn't care about those fields.
>
> I'm really not very familiar with crash and kdump.
>
> I'll attach a git7-git8 diff of some of the related code from
> asm-x86.
>
> I guess any final fix would need to take into account guarding
> against
> any other future changes like this ... if one could reasonably do so.
>
> I won't have much time to delve into it any more for at least a few
> more
> weeks.
I appreciate your time -- sorry to drag you down into my world.
(Please forgive an old "ccur.com" guy...)
Thanks,
Dave
15 years, 8 months
Re: [Crash-utility] Crash Setup
by Dave Anderson
----- "ADITYA KRISHNAN" <akrishn7(a)ncsu.edu> wrote:
> Hi,
>
>
> I am new to crash utility. I want to run crash ( crash 4.0-2.18.1) on
> dual-core AMD Opteron (x86_64) cluster. The cluster nodes are running
> xen 3.0 the proc/version gives the following output : 2.6.16.13-xen
> i am running xen 3.0 which has been installed on fc5.
>
If the crash version 4.0-2.18.1 you are using is the Red Hat
version 4.0-2.18.1, then it is well over 2 years old. I don't
think that xen kernels were even supported back then?
(see http://people.redhat.com/anderson/crash.changelog.html)
In any case, please try the latest version by downloading
crash-4.0-7.4.tar.gz from http://people.redhat.com/anderson,
and build it like this:
# tar xvzmf crash-4.0-7.4.tar.gz
...
# cd crash-4.0-7.4
# make
...
#
If there is a bug here, then I need to know if it exists in
the latest version. I don't debug old versions.
>
> I guess the kernel was not built with debugging info on
I don't think so. If that were true, it would have failed much
earlier with a message like:
vmlinux-syms-2.6.16.13-xen: no debugging data available
And given that the name of the file is "vmlinux-syms-2.6.16.13-xen"
the "syms" presumably implies it's got debugging data in it.
But I don't know how it works on whatever distribution you're
running. It seems strange that a "vmlinux-syms-2.6.16.13-xen"
with full debuginfo data would be located in /boot?
>
>
> Running crash gives the following output:
>
>
>
> crash 4.0-2.18.1
> Copyright (C) 2002, 2003, 2004, 2005, 2006 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005 Fujitsu Limited
> Copyright (C) 2005 NEC Corporation
> Copyright (C) 1999, 2002 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.
>
>
> WARNING: cannot read linux_banner string
> crash: /boot/vmlinux-syms-2.6.16.13-xen and /dev/mem do not match!
>
>
> I read up on the previous threads that this is because /dev/mem
> returns all zereos.
> I think I need something like a patch for installing the /dev/crash
> module. I am new to this so can anyone help me out with a detailed
> procedure of what needs to be done.
>
I wouldn't think the /dev/crash driver is necessary on a kernel of
that vintage. Only Red Hat kernels from RHEL4 onward and upstream
kernels with the CONFIG_STRICT_DEVMEM configuration turned on would
require an alternative like the Red Hat /dev/crash driver.
But that being said, the "cannot read linux_banner string" means
that either one of these two things happened:
1. the read() from /dev/mem failed, or
2. the read() from /dev/mem worked, but returned zeroes.
I can't tell which happened, but I'm guessing the latter, because
there are a handful of other read()'s done from /dev/mem before that
particular one is done, which is trying to access the linux_banner string.
It may be due to an incorrect access to the linux_banner string, which has
changed over the years. In some kernels, the "linux_banner" symbol
is the address of the actual string, whereas on others it contains
a pointer to the actual string. The crash utility (*now*) has
this code segment in its verify_version() function:
if (!(sp = symbol_search("linux_banner")))
error(FATAL, "linux_banner symbol does not exist?\n");
else if ((sp->type == 'R') || (sp->type == 'r'))
linux_banner = symbol_value("linux_banner");
else
get_symbol_data("linux_banner", sizeof(ulong), &linux_banner);
If you do an "nm -Bn vmlinux-syms-2.6.16.13-xen | grep linux_banner",
what do you see? If it's type R or r, then crash reads directly from
that symbol value address. Otherwise it reads the contents of the
that symbol value address, and reads the string from there.
You can also try "gdb vmlinux-syms-2.6.16.13-xen", from which
you can determine whether there's a level of indirection there.
But I'm blanking out w/respect to your "previous threads that this is
because /dev/mem returns all zeroes" statement. I'm not aware (at
least any more) of any case where /dev/mem would return zeroes instead
of failing the read() call itself? Can you point me to those
threads?
But again -- I'm not interested in issues with older versions
of crash. Please upgrade to the latest version, and if that
doesn't work, run it as "crash -d3 /boot/vmlinux-syms-2.6.16.13-xen",
and there will be a bunch of debug output displayed that may help nail
it down.
Dave
15 years, 8 months
Re: [Crash-utility] 32 bit linux-2.6.24-git8 user_regs_struct change breaks opening kdump crashfiles
by Dave Anderson
----- "Joe Porter" <joe.porter(a)ccur.com> wrote:
> Hello crash,
>
> The user_regs_struct was redefined in
> linux-2.6.24-git8/include/asm-x86/user_32.h.
>
> This results in the following error when opening 32 bit kdump
> crashfiles:
> -------------------------------------------------------------------------
> please wait... (determining panic task)
> crash: invalid structure member offset: user_regs_struct_ebp
> FILE: netdump.c LINE: 687 FUNCTION: get_netdump_panic_task()
>
> [/sbin/crash] error trace: 80e09f4 => 8154159 => 814fc3f => 813ec75
>
> 813ec75: OFFSET_verify+126
> 814fc3f: get_netdump_panic_task+1196
> 8154159: get_kdump_panic_task+11
> 80e09f4: get_dumpfile_panic_task+153
> --------------------------------------------------------------------
>
> I've inserted a patch to crash-4.0-7.4/x86.c that fixes this for all
> linux-2.6.24-git8
> and later kernels (2.6.25 -> 2.6.28-rc5). I've also inserted the
> kernel change that
> caused the breakage.
>
> The fix is bad because it breaks all kernels <= linux-2.6.24-git7.
>
> A better fix would be backward and forward compatible with all
> kernels, but since there
> was a lot of hardwired code revolving around the old 32 bit
> user_regs_struct I thought I
> would just submit this patch to expose the problem and maybe look for
> a better fix in the
> next crash update.
Right -- it wouldn't be a "better fix", but rather the "only fix"
that's going to be acceptable.
Does the new kernel that has the name changes end up using the
initial attempts to set the size, esp and ebp offsets? Or does
it always end up using the "if (!VALID_STRUCT())" section? It's
only going to use one or the other, depending upon whether the
user_regs_struct gets exported-to/included-in the debuginfo data.
Dave
>
> thx, joe
>
> --- crash-4.0-7.4.orig/x86.c 2008-10-14 09:35:40.000000000 -0400
> +++ crash-4.0-7.4/x86.c 2008-11-17 13:37:40.000000000 -0500
> @@ -1774,29 +1774,39 @@
> machdep->flags |= OMIT_FRAME_PTR;
> STRUCT_SIZE_INIT(user_regs_struct, "user_regs_struct");
> MEMBER_OFFSET_INIT(user_regs_struct_ebp,
> - "user_regs_struct", "ebp");
> + "user_regs_struct", "bp");
> MEMBER_OFFSET_INIT(user_regs_struct_esp,
> - "user_regs_struct", "esp");
> + "user_regs_struct", "sp");
> if (!VALID_STRUCT(user_regs_struct)) {
> /* Use this hardwired version -- sometimes the
> * debuginfo doesn't pick this up even though
> * it exists in the kernel; it shouldn't change.
> */
> struct x86_user_regs_struct {
> - long ebx, ecx, edx, esi, edi, ebp, eax;
> - unsigned short ds, __ds, es, __es;
> - unsigned short fs, __fs, gs, __gs;
> - long orig_eax, eip;
> - unsigned short cs, __cs;
> - long eflags, esp;
> - unsigned short ss, __ss;
> + unsigned long bx;
> + unsigned long cx;
> + unsigned long dx;
> + unsigned long si;
> + unsigned long di;
> + unsigned long bp;
> + unsigned long ax;
> + unsigned long ds;
> + unsigned long es;
> + unsigned long fs;
> + unsigned long gs;
> + unsigned long orig_ax;
> + unsigned long ip;
> + unsigned long cs;
> + unsigned long flags;
> + unsigned long sp;
> + unsigned long ss;
> };
> ASSIGN_SIZE(user_regs_struct) =
> sizeof(struct x86_user_regs_struct);
> ASSIGN_OFFSET(user_regs_struct_ebp) =
> - offsetof(struct x86_user_regs_struct, ebp);
> + offsetof(struct x86_user_regs_struct, bp);
> ASSIGN_OFFSET(user_regs_struct_esp) =
> - offsetof(struct x86_user_regs_struct, esp);
> + offsetof(struct x86_user_regs_struct, sp);
> }
> MEMBER_OFFSET_INIT(thread_struct_cr3, "thread_struct", "cr3");
> STRUCT_SIZE_INIT(cpuinfo_x86, "cpuinfo_x86");
>
> --------------------------------------------------------------------------------
>
> --- linux-2.6.24-git7/include/asm-x86/user_32.h 2008-01-24
> 17:58:37.000000000 -0500
> +++ linux-2.6.24-git8/include/asm-x86/user_32.h 2008-11-11
> 18:56:13.000000000 -0500
> @@ -75,13 +75,23 @@
> * doesn't use the extra segment registers)
> */
> struct user_regs_struct {
> - long ebx, ecx, edx, esi, edi, ebp, eax;
> - unsigned short ds, __ds, es, __es;
> - unsigned short fs, __fs, gs, __gs;
> - long orig_eax, eip;
> - unsigned short cs, __cs;
> - long eflags, esp;
> - unsigned short ss, __ss;
> + unsigned long bx;
> + unsigned long cx;
> + unsigned long dx;
> + unsigned long si;
> + unsigned long di;
> + unsigned long bp;
> + unsigned long ax;
> + unsigned long ds;
> + unsigned long es;
> + unsigned long fs;
> + unsigned long gs;
> + unsigned long orig_ax;
> + unsigned long ip;
> + unsigned long cs;
> + unsigned long flags;
> + unsigned long sp;
> + unsigned long ss;
> };
>
> /* When the kernel dumps core, it starts by dumping the user struct
> -
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
15 years, 8 months
32 bit linux-2.6.24-git8 user_regs_struct change breaks opening kdump crashfiles
by Joe Porter
Hello crash,
The user_regs_struct was redefined in linux-2.6.24-git8/include/asm-x86/user_32.h.
This results in the following error when opening 32 bit kdump crashfiles:
-------------------------------------------------------------------------
please wait... (determining panic task)
crash: invalid structure member offset: user_regs_struct_ebp
FILE: netdump.c LINE: 687 FUNCTION: get_netdump_panic_task()
[/sbin/crash] error trace: 80e09f4 => 8154159 => 814fc3f => 813ec75
813ec75: OFFSET_verify+126
814fc3f: get_netdump_panic_task+1196
8154159: get_kdump_panic_task+11
80e09f4: get_dumpfile_panic_task+153
--------------------------------------------------------------------
I've inserted a patch to crash-4.0-7.4/x86.c that fixes this for all linux-2.6.24-git8
and later kernels (2.6.25 -> 2.6.28-rc5). I've also inserted the kernel change that
caused the breakage.
The fix is bad because it breaks all kernels <= linux-2.6.24-git7.
A better fix would be backward and forward compatible with all kernels, but since there
was a lot of hardwired code revolving around the old 32 bit user_regs_struct I thought I
would just submit this patch to expose the problem and maybe look for a better fix in the
next crash update.
thx, joe
--- crash-4.0-7.4.orig/x86.c 2008-10-14 09:35:40.000000000 -0400
+++ crash-4.0-7.4/x86.c 2008-11-17 13:37:40.000000000 -0500
@@ -1774,29 +1774,39 @@
machdep->flags |= OMIT_FRAME_PTR;
STRUCT_SIZE_INIT(user_regs_struct, "user_regs_struct");
MEMBER_OFFSET_INIT(user_regs_struct_ebp,
- "user_regs_struct", "ebp");
+ "user_regs_struct", "bp");
MEMBER_OFFSET_INIT(user_regs_struct_esp,
- "user_regs_struct", "esp");
+ "user_regs_struct", "sp");
if (!VALID_STRUCT(user_regs_struct)) {
/* Use this hardwired version -- sometimes the
* debuginfo doesn't pick this up even though
* it exists in the kernel; it shouldn't change.
*/
struct x86_user_regs_struct {
- long ebx, ecx, edx, esi, edi, ebp, eax;
- unsigned short ds, __ds, es, __es;
- unsigned short fs, __fs, gs, __gs;
- long orig_eax, eip;
- unsigned short cs, __cs;
- long eflags, esp;
- unsigned short ss, __ss;
+ unsigned long bx;
+ unsigned long cx;
+ unsigned long dx;
+ unsigned long si;
+ unsigned long di;
+ unsigned long bp;
+ unsigned long ax;
+ unsigned long ds;
+ unsigned long es;
+ unsigned long fs;
+ unsigned long gs;
+ unsigned long orig_ax;
+ unsigned long ip;
+ unsigned long cs;
+ unsigned long flags;
+ unsigned long sp;
+ unsigned long ss;
};
ASSIGN_SIZE(user_regs_struct) =
sizeof(struct x86_user_regs_struct);
ASSIGN_OFFSET(user_regs_struct_ebp) =
- offsetof(struct x86_user_regs_struct, ebp);
+ offsetof(struct x86_user_regs_struct, bp);
ASSIGN_OFFSET(user_regs_struct_esp) =
- offsetof(struct x86_user_regs_struct, esp);
+ offsetof(struct x86_user_regs_struct, sp);
}
MEMBER_OFFSET_INIT(thread_struct_cr3, "thread_struct", "cr3");
STRUCT_SIZE_INIT(cpuinfo_x86, "cpuinfo_x86");
--------------------------------------------------------------------------------
--- linux-2.6.24-git7/include/asm-x86/user_32.h 2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24-git8/include/asm-x86/user_32.h 2008-11-11
18:56:13.000000000 -0500
@@ -75,13 +75,23 @@
* doesn't use the extra segment registers)
*/
struct user_regs_struct {
- long ebx, ecx, edx, esi, edi, ebp, eax;
- unsigned short ds, __ds, es, __es;
- unsigned short fs, __fs, gs, __gs;
- long orig_eax, eip;
- unsigned short cs, __cs;
- long eflags, esp;
- unsigned short ss, __ss;
+ unsigned long bx;
+ unsigned long cx;
+ unsigned long dx;
+ unsigned long si;
+ unsigned long di;
+ unsigned long bp;
+ unsigned long ax;
+ unsigned long ds;
+ unsigned long es;
+ unsigned long fs;
+ unsigned long gs;
+ unsigned long orig_ax;
+ unsigned long ip;
+ unsigned long cs;
+ unsigned long flags;
+ unsigned long sp;
+ unsigned long ss;
};
/* When the kernel dumps core, it starts by dumping the user struct -
15 years, 8 months