Re: [Crash-utility] problems running crash on recent rawhide live kernels

2007-12-17 Thread Jeff Layton
On Fri, 07 Dec 2007 14:55:08 -0500
Dave Anderson [EMAIL PROTECTED] 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: ff20
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=0xff20 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: 0xff20
 
 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: 813a1780  [THREAD_INFO: 81496000]
   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 [EMAIL PROTECTED]

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility


Re: [Crash-utility] problems running crash on recent rawhide live kernels

2007-12-17 Thread Dave Anderson

Jeff Layton wrote:

On Fri, 07 Dec 2007 14:55:08 -0500
Dave Anderson [EMAIL PROTECTED] 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: ff20
  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=0xff20 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: 0xff20

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: 813a1780  [THREAD_INFO: 81496000]
 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 0xff20, which BTW,
is the first kernel in which I've ever seen it as a negative number.

Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility