1:55 p.m.
Jeff Layton wrote:
> Relevant packages:
>
> kernel-2.6.24-0.62.rc3.git5.fc9.x86_64
> kernel-debuginfo-2.6.24-0.62.rc3.git5.fc9.x86_64
> crash-4.0-4.10.x86_64
>
> ... the host is a FV xen guest (but that shouldn't matter, should
> it?).
To get crash version 4.0-4.11 to run against that particular
dumpfile, it needs to know the kernel's "phys_base" relocation
value. And I don't know how (or if it's even possible) to get
it from a fully-virtualized Xen guest dumpfile. However, if
you run crash on the live on the kernel that panicked, you can
determine it. So running live on kernel-2.6.24-0.62.rc3.git5.fc9
I see:
crash> help -m | grep phys_base
phys_base: ffffffffff200000
crash>
...which in turn can be used as a command line argument for the
xendump dumpfile from that kernel. So taking the sample dumpfile
you gave me:
# crash --machdep phys_base=0xffffffffff200000 vmlinux vmcore-rawhide.xmdump
crash 4.0-4.11
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 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.
NOTE: setting phys_base to: 0xffffffffff200000
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"...
KERNEL: vmlinux
DUMPFILE: vmcore-rawhide.xmdump
CPUS: 1
DATE: Tue Dec 4 15:41:08 2007
UPTIME: 06:10:51
LOAD AVERAGE: 0.00, 0.00, 0.00
TASKS: 74
NODENAME: dhcp231-229.rdu.redhat.com
RELEASE: 2.6.24-0.62.rc3.git5.fc9
VERSION: #1 SMP Sat Dec 1 13:59:08 EST 2007
MACHINE: x86_64 (3458 Mhz)
MEMORY: 511.6 MB
PANIC: "SysRq : Trigger a crashdump"
PID: 0
COMMAND: "swapper"
TASK: ffffffff813a1780 [THREAD_INFO: ffffffff81496000]
CPU: 0
STATE: TASK_RUNNING (ACTIVE)
crash>
Pain in the ass. But I don't know any better way.
Dave
2:20 p.m.
New subject: problems running crash on recent rawhide live kernels
On Fri, 07 Dec 2007 14:55:08 -0500
Dave Anderson <anderson(a)redhat.com> wrote:
> Jeff Layton wrote:
> > Relevant packages:
> >
> > kernel-2.6.24-0.62.rc3.git5.fc9.x86_64
> > kernel-debuginfo-2.6.24-0.62.rc3.git5.fc9.x86_64
> > crash-4.0-4.10.x86_64
> >
> > ... the host is a FV xen guest (but that shouldn't matter, should
> > it?).
To get crash version 4.0-4.11 to run against that particular
dumpfile, it needs to know the kernel's "phys_base" relocation
value. And I don't know how (or if it's even possible) to get
it from a fully-virtualized Xen guest dumpfile. However, if
you run crash on the live on the kernel that panicked, you can
determine it. So running live on kernel-2.6.24-0.62.rc3.git5.fc9
I see:
crash> help -m | grep phys_base
phys_base: ffffffffff200000
crash>
...which in turn can be used as a command line argument for the
xendump dumpfile from that kernel. So taking the sample dumpfile
you gave me:
# crash --machdep phys_base=0xffffffffff200000 vmlinux
vmcore-rawhide.xmdump
crash 4.0-4.11
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 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.
NOTE: setting phys_base to: 0xffffffffff200000
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"...
KERNEL: vmlinux
DUMPFILE: vmcore-rawhide.xmdump
CPUS: 1
DATE: Tue Dec 4 15:41:08 2007
UPTIME: 06:10:51
LOAD AVERAGE: 0.00, 0.00, 0.00
TASKS: 74
NODENAME: dhcp231-229.rdu.redhat.com
RELEASE: 2.6.24-0.62.rc3.git5.fc9
VERSION: #1 SMP Sat Dec 1 13:59:08 EST 2007
MACHINE: x86_64 (3458 Mhz)
MEMORY: 511.6 MB
PANIC: "SysRq : Trigger a crashdump"
PID: 0
COMMAND: "swapper"
TASK: ffffffff813a1780 [THREAD_INFO: ffffffff81496000]
CPU: 0
STATE: TASK_RUNNING (ACTIVE)
crash>
Pain in the ass. But I don't know any better way.
Dave
Sorry for the delayed response. Did you need me to get that info from
my xen guest so you could use that coredump, or do you have it
covered? Thanks for fixing up crash, BTW...
--
Jeff Layton <jlayton(a)redhat.com>
2:45 p.m.
New subject: problems running crash on recent rawhide live kernels
Jeff Layton wrote:
On Fri, 07 Dec 2007 14:55:08 -0500
Dave Anderson <anderson(a)redhat.com> wrote:
> > Jeff Layton wrote:
> > > Relevant packages:
> > >
> > > kernel-2.6.24-0.62.rc3.git5.fc9.x86_64
> > > kernel-debuginfo-2.6.24-0.62.rc3.git5.fc9.x86_64
> > > crash-4.0-4.10.x86_64
> > >
> > > ... the host is a FV xen guest (but that shouldn't matter, should
> > > it?).
>
>To get crash version 4.0-4.11 to run against that particular
>dumpfile, it needs to know the kernel's "phys_base" relocation
>value. And I don't know how (or if it's even possible) to get
>it from a fully-virtualized Xen guest dumpfile. However, if
>you run crash on the live on the kernel that panicked, you can
>determine it. So running live on kernel-2.6.24-0.62.rc3.git5.fc9
>I see:
>
> crash> help -m | grep phys_base
> phys_base: ffffffffff200000
> crash>
>
>...which in turn can be used as a command line argument for the
>xendump dumpfile from that kernel. So taking the sample dumpfile
>you gave me:
>
># crash --machdep phys_base=0xffffffffff200000 vmlinux
>vmcore-rawhide.xmdump
>
>crash 4.0-4.11
>Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 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.
>
>NOTE: setting phys_base to: 0xffffffffff200000
>
>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"...
>
> KERNEL: vmlinux
> DUMPFILE: vmcore-rawhide.xmdump
> CPUS: 1
> DATE: Tue Dec 4 15:41:08 2007
> UPTIME: 06:10:51
>LOAD AVERAGE: 0.00, 0.00, 0.00
> TASKS: 74
> NODENAME: dhcp231-229.rdu.redhat.com
> RELEASE: 2.6.24-0.62.rc3.git5.fc9
> VERSION: #1 SMP Sat Dec 1 13:59:08 EST 2007
> MACHINE: x86_64 (3458 Mhz)
> MEMORY: 511.6 MB
> PANIC: "SysRq : Trigger a crashdump"
> PID: 0
> COMMAND: "swapper"
> TASK: ffffffff813a1780 [THREAD_INFO: ffffffff81496000]
> CPU: 0
> STATE: TASK_RUNNING (ACTIVE)
>
>crash>
>
>Pain in the ass. But I don't know any better way.
>
>Dave
>
>
Sorry for the delayed response. Did you need me to get that info from
my xen guest so you could use that coredump, or do you have it
covered? Thanks for fixing up crash, BTW...
No, thanks, I have that dumpfile stashed aside.
The problem is that I don't see how the physical base address
can be calculated with just the vmcore and vmlinux. When it's
running live, the physical base address can be calculated using
/proc/iomem. So I downloaded that kernel, ran it live, and that's
where I got the phys_base value of 0xffffffffff200000, which BTW,
is the first kernel in which I've ever seen it as a negative number.
Dave
6039
days inactive
6049
days old
devel@lists.crash-utility.osci.io
2 comments
2 participants
participants (2)
-
Dave Anderson -
Jeff Layton