Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
by tachibana＠mxm.nes.nec.co.jp
Hi Hatayama-san,
On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
>
> >
> >
> > ----- Original Message -----
> >> Fujitsu has stand-alone dump mechanism based on firmware level
> >> functionality, which we call SADUMP, in short.
> >>
> >> We've maintained utility tools internally but now we're thinking that
> >> the best is crash utility and makedumpfile supports the sadump format
> >> for the viewpoint of both portability and maintainability.
> >>
> >> We'll be of course responsible for its maintainance in a continuous
> >> manner. The sadump dump format is very similar to diskdump format and
> >> so kdump (compressed) format, so we estimate patch set would be a
> >> relatively small size.
> >>
> >> Could you tell me whether crash utility and makedumpfile can support
> >> the sadump format? If OK, we'll start to make patchset.
I think it's not bad to support sadump by makedumpfile. However I have
several questions.
- Do you want to use makedumpfile to make an existing file that sadump has
dumped small?
- It isn't possible to support the same form as kdump-compressed format
now, is it?
- When the information that makedumpfile reads from a note of /proc/vmcore
(or a header of kdump-compressed format) is added by an extension of
makedumpfile, do you need to modify sadump?
Thanks
tachibana
> >
> > Sure, yes, the crash utility can always support another dumpfile format.
> >
>
> Thanks. It helps a lot.
>
> > It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
> > Does your internal version patch diskdump.c, or do you maintain your
> > own "sadump.c"? I ask because if your patchset is at all intrusive,
> > I'd prefer it be kept in its own file, primarily for maintainability,
> > but also because SADUMP is essentially a black-box to anybody outside
> > Fujitsu.
>
> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.
>
> On the other hand, there's a code to be placed at such specific
> area. sadump is triggered depending on kdump's progress and so
> register values to be contained in vmcore varies according to the
> progress: If crash_notes has been initialized when sadump is
> triggered, sadump packs the register values in crash_notes; if not
> yet, packs registers gathered by firmware. This is sadump specific
> processing, so I think putting it in specific sadump.c file is a
> natural and reasonable choise.
>
> Anyway, I have not made any patch set for this. I'll post a patch set
> when I complete.
>
> Again, thanks a lot for the positive answer.
>
> Thanks.
> HATAYAMA, Daisuke
>
>
> _______________________________________________
> kexec mailing list
> kexec(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
1 year
Re: [Crash-utility] Updating PPC
by Dave Anderson
----- Original Message -----
> Hello Dave,
>
> I attach patches which are updating powerpc based on linux-2.6.27.
> Please review them.
>
> Following updates have been done but some of them could not test yet
> because of constraints in environment.
> (Non-SMP powerpc virtual machine of qemu can only use)
>
> - Get rid of __func__. symbols (patch 0001)
> This patch can delete such symbols from command output like
>
> crash> sym -l | grep __func__ -m 3
> c03604ac (r) __func__.21434
> c0360500 (r) __func__.21333
> c0360508 (r) __func__.21309
>
> - Minor updates (patch 0002/0003/0004)
> ppc_processor_speed() support "ibm,extended-clock-frequency" [Not tested]
> ppc_get_smp_cpus() can return correct cpu numbers on SMP [Not tested]
> "bt", "mach" can handle (tt->flags & IRQSTACKS) [Not tested]
>
> - Enhancement of "bt" (patch 0005/0006/0007/0008)
> Detect exeption frame of linux-2.6 style ("bt" can dispaly '+' parts of below)
> Some functions are cleanuped with ppc64's.
> * Link Register of nested exception frame could not be tested.
> This may require the exception in kernel mode like oops but
> can not try kernel dump for a while...
>
> crash> bt 1
> PID: 1 TASK: c8818000 CPU: 0 COMMAND: "init"
> #0 [c881da10] schedule at c0356ac4
> #1 [c881da70] schedule_timeout at c0357468
> #2 [c881dab0] do_select at c00c4758
> #3 [c881dd90] core_sys_select at c00c4bd0
> #4 [c881dee0] sys_select at c00c52b0
> #5 [c881df30] ppc_select at c00053c0
> #6 [c881df40] ret_from_syscall at c0011f64
> + syscall [c01] exception frame:
> +R0: 0000008e R1: b8c11a60 R2: 48008660 R3: 0000000b
> +R4: b8c11cac R5: 00000000 R6: 00000000 R7: b8c11b24
> +R8: 00000000 R9: 00000400 R10: 00000000 R11: 0ff24b2c
> +R12: 0ff1b8ec R13: 100207f0
> +NIP: 0ff24b40 MSR: 0000d032 OR3: 0000000b CTR: 0ff24b2c
> +LR: 10005314 XER: 00000000 CCR: 24002462 MQ: 00000000
> +DAR: 0ffb4cd0 DSISR: 0a000000 Syscall Result: 00000000
>
> Still remaining the parts of PPC update and I have to setup more useful environment
> for the tests as soon as possible.
>
> Thanks,
> Toshi.
Hello Toshi,
All patches are queued for crash-6.0.1.
Thanks,
Dave
13 years, 1 month
Updating PPC
by Toshikazu Nakayama
Hello Dave,
I attach patches which are updating powerpc based on linux-2.6.27.
Please review them.
Following updates have been done but
some of them could not test yet because of constraints in environment.
(Non-SMP powerpc virtual machine of qemu can only use)
- Get rid of __func__. symbols (patch 0001)
This patch can delete such symbols from command output like
crash> sym -l | grep __func__ -m 3
c03604ac (r) __func__.21434
c0360500 (r) __func__.21333
c0360508 (r) __func__.21309
- Minor updates (patch 0002/0003/0004)
ppc_processor_speed() support "ibm,extended-clock-frequency" [Not tested]
ppc_get_smp_cpus() can return correct cpu numbers on SMP [Not tested]
"bt", "mach" can handle (tt->flags & IRQSTACKS) [Not tested]
- Enhancement of "bt" (patch 0005/0006/0007/0008)
Detect exeption frame of linux-2.6 style ("bt" can dispaly '+' parts of below)
Some functions are cleanuped with ppc64's.
* Link Register of nested exception frame could not be tested.
This may require the exception in kernel mode like oops but
can not try kernel dump for a while...
crash> bt 1
PID: 1 TASK: c8818000 CPU: 0 COMMAND: "init"
#0 [c881da10] schedule at c0356ac4
#1 [c881da70] schedule_timeout at c0357468
#2 [c881dab0] do_select at c00c4758
#3 [c881dd90] core_sys_select at c00c4bd0
#4 [c881dee0] sys_select at c00c52b0
#5 [c881df30] ppc_select at c00053c0
#6 [c881df40] ret_from_syscall at c0011f64
+ syscall [c01] exception frame:
+R0: 0000008e R1: b8c11a60 R2: 48008660 R3: 0000000b
+R4: b8c11cac R5: 00000000 R6: 00000000 R7: b8c11b24
+R8: 00000000 R9: 00000400 R10: 00000000 R11: 0ff24b2c
+R12: 0ff1b8ec R13: 100207f0
+NIP: 0ff24b40 MSR: 0000d032 OR3: 0000000b CTR: 0ff24b2c
+LR: 10005314 XER: 00000000 CCR: 24002462 MQ: 00000000
+DAR: 0ffb4cd0 DSISR: 0a000000 Syscall Result: 00000000
Still remaining the parts of PPC update and I have to setup more useful environment
for the tests as soon as possible.
Thanks,
Toshi.
13 years, 1 month
[help]crash can't anaylyse xen guest paravirtulized linux vmcore
by hu jun
xen guest linux : paravirtulized
Vsles11-1:/usr/src/linux # grep CONFIG_DEBUG_INFO .config -n
4574:CONFIG_DEBUG_INFO=y
Vsles11-1:/usr/src/linux # ls
..tmp_kallsyms1.o.cmd .tmp_System.map .version Makefile crypto kernel scripts
..tmp_kallsyms2.o.cmd .tmp_kallsyms1.S .vmlinux.cmd Module.symvers drivers lib security
..tmp_vmlinux1.cmd .tmp_kallsyms1.o .vmlinux.o.cmd README firmware mm sound
..tmp_vmlinux2.cmd .tmp_kallsyms2.S COPYING README.SUSE fs modules.builtin tools
.config .tmp_kallsyms2.o CREDITS REPORTING-BUGS include modules.order usr
.config.old .tmp_versions Documentation System.map init net virt
.mailmap .tmp_vmlinux1 Kbuild arch ipc perfmon vmlinux
.missing-syscalls.d .tmp_vmlinux2 MAINTAINERS block kdb samples vmlinux.o
Vsles11-1:/usr/src/linux #
SLES11:/etc/xen # xm dump-core 4 /opt/sles11_1.mem
Dumping core of domain: 4 ...
SLES11:/etc/xen # cd /opt/
SLES11:/opt # ls
.Trash-0 centos_guest huawei kdump linux-3.0 novell sles11_1.mem sys_use user xen_study
10-17-12:52 gnome job kernel lost+found openoffice.org sles11_ana tar_rpm vmlinux
Life hardware kde3 kvm network openoffice.org3 sles11_guest tencent winxp_guest
SLES11:/opt # crash vmlinux sles11_1.mem
crash 4.0-7.6
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"...
crash: cannot resolve "end_pfn"
use lastest crash version:
SLES11:/opt/tar_rpm/crash-5.1.9 # ./crash /opt/vmlinux /opt/sles11_1.mem
crash 5.1.9
Copyright (C) 2002-2011 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 (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
crash: cannot find mfn 0 (0x0) in page index
crash: cannot read/find pte page
13 years, 1 month
[ANNOUNCE] crash version 6.0.0 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
Changelog:
- Updated the embedded gdb version to FSF gdb-7.3.1. This change is
required for kernels built with gcc-4.6.1, which now defaults to
using -gdwarf-4. When using prior versions of crash on such a
vmlinux file, it fails immediately with the message "Dwarf Error:
wrong version in compilation unit header (is 4, should be 2) [in
module vmlinux]" followed by "crash: vmlinux: no debugging data
available".
(anderson(a)redhat.com)
- Incremental patch for the SADUMP dumpfile support that was introduced
in crash-5.1.8. The patchset fixes minor bugs, cleans up the sadump
module, addresses the issue of gathering the first 640KB backup from
a kdump-enabled kernel, prepares for makedumpfile's support of the
SADUMP format, and has "bt" display the stored register set when the
compressed kdump was generated from an SADUMP dumpfile.
(d.hatayama(a)jp.fujitsu.com)
- Fix for the "gdb" command, or any command that resolves to a gdb
command, to allow redirection to a pipe or file. This addresses a
regression that was introduced by an unrelated "gdb" command fix
in crash-5.1.4 that prevented the stripping of quotation marks from
the input line. Without the patch, redirection of a "gdb" command
to a pipe or file fails with the error message "gdb: gdb request
failed: <original-command-line-including-redirection>".
(anderson(a)redhat.com)
- Fix for live system analysis of 32-bit PPC kernels. Without the
patch, the session would fail after displaying the error message:
WARNING: machine type mismatch:
crash utility: PPC
vmlinux: (unknown)
(nakayama.ts(a)ncos.nec.co.jp)
- Fix to allow vmalloc memory access on 32-bit PPC kernels. Without
the patch, the warning message "WARNING: cannot access vmalloc'd
module memory" would be displayed during invocation, and kernel
virtual memory that was vmalloc'd could not be accessed.
(nakayama.ts(a)ncos.nec.co.jp)
- Fix to correctly gather task addresses from 32-bit PPC kernels.
Without the patch, during invocation a stream of error messages
indicating "crash: invalid task address in pid_hash: <address>"
would be displayed.
(nakayama.ts(a)ncos.nec.co.jp)
- Fix for the "bt" command in 32-bit PPC kernels. Without the patch,
the "bt" command would generate a segmentation violation.
(nakayama.ts(a)ncos.nec.co.jp)
13 years, 1 month
making sense of virtualbox .sav files
by Scott Edwards
Hello,
I suspect the open source edition of vbox and the oracle non foss edition
use the same format for the save state files (ram and device info dumps).
The bulk of /proc/kcore equiv is in here, with other metadata. file(1) just
whines this is data...
If you have any information leading to use of this save state data with
crash, please advise. I've scoured all the places I can think of. For better
or worse, I'm not sure I can pull this off by using the ose code - it's just
a bit too far above my head to know I'm making a reliable export of .sav
files to kcore equiv outputs.
Regards,
Scott Edwards
13 years, 1 month
Re: [Crash-utility] Fix fatal problems in PPC
by Dave Anderson
----- Original Message -----
> Hello Dave,
>
> I'm trying to use crash configured with PPC on linux-2.6.27 powerpc.
> And when crash started with /dev/mem, I found some problems and fixed them.
>
> I'm afraid that PPC32 is now not maintained for long time, most people use PPC64 only?
> I don't know true reason but if possible, please check attached patch set.
Correct -- there is no "PPC architecture maintainer" w/respect to the crash
utility, and there have been very few architecture-specific patches for 32-bit
ppc in recent years.
>
> Report of problems which I met as below:
> [problem 1] Display type mismatch WARNING
> WARNING: machine type mismatch:
> crash utility: PPC
> vmlinux: (unknown)
> -> Simply lacking of verification, remove WARNING with 0001
>
> [problem 2] Display vmalloc fault WARNING
> WARNING: cannot access vmalloc'd module memory
> -> PTE index was wrong, fix with 0002
>
> [problem 3] Repeat "invalid task address in pid_hash:" 500 times
> crash: invalid task address in pid_hash: c8818450
> -> Alignment check was too old, fix with 0003
>
> [problem 4] bt command is always SEGV while accessing stack frame
> -> Similar to problem 3, fix with 0004
OK, good -- these 4 patches are queued for crash-6.0.0.
> I continue to test the basic command regressions or
> update PPC implementation by learning from PPC64.
Great! I now designate you as the PPC maintainer!
Thanks,
Dave
13 years, 1 month
Fix fatal problems in PPC
by Toshikazu Nakayama
Hello Dave,
I'm trying to use crash configured with PPC on linux-2.6.27 powerpc.
And when crash started with /dev/mem, I found some problems and fixed them.
I'm afraid that PPC32 is now not maintained for long time,
most people use PPC64 only?
I don't know true reason but if possible, please check attached patch set.
Report of problems which I met as below:
[problem 1] Display type mismatch WARNING
WARNING: machine type mismatch:
crash utility: PPC
vmlinux: (unknown)
-> Simply lacking of verification, remove WARNING with 0001
[problem 2] Display vmalloc fault WARNING
WARNING: cannot access vmalloc'd module memory
-> PTE index was wrong, fix with 0002
[problem 3] Repeat "invalid task address in pid_hash:" 500 times
crash: invalid task address in pid_hash: c8818450
-> Alignment check was too old, fix with 0003
[problem 4] bt command is always SEGV while accessing stack frame
-> Similar to problem 3, fix with 0004
I continue to test the basic command regressions or
update PPC implementation by learning from PPC64.
Thanks,
Toshi
13 years, 1 month
Info re: the next release
by Dave Anderson
I know several of you are awaiting anxiously for the next release,
which will be crash version 6.0.0. I update the major number to
signal a change in the embedded gdb version, which will be rebased
from gdb-7.0 to gdb-7.3.1. This change is required for kernels
built with gcc-4.6.1, which now defaults to using -gdwarf-4, and the
currently-embedded gdb-7.0 does not support DWARF 4. If you try to
use the current version of crash on such a vmlinux, it fails
immediately with the message:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module vmlinux]"
followed by:
crash: vmlinux: no debugging data available
I've got the upgrade done, but I'm still working out a few minor kinks
that always seem to happen with a gdb upgrade.
I'll release it as soon as possible.
Dave
13 years, 1 month
[RESEND] Re: [PATCH 00/11] sadump: Incremental update patches
by Dave Anderson
I don't know what it is about Daisuke's mail, but when I respond to them
with my Zimbra mailer, the archived version gets screwed up for some reason:
https://www.redhat.com/archives/crash-utility/2011-October/msg00091.html
The same thing happened last month when I responded to another of Daisuke's
emails.
Anyway, I believe the digested version will be OK, but in order to archive this
message properly, here it is again:
----- Original Message -----
... [ cut ] ...
> > If I remove the "use_regs_in_elf_notes_on_kdump_fmt_from_sadump.patch.patch" patch
> > the backtraces are correct. Now, it may be true that the changes you made make
> > sense with respect to sadump dumpfiles, where the register set stored in the header
> > is a reflection of the last location that each cpu ran (?).
> >
> > But those changes are totally unacceptable for compressed kdump dumpfiles.
>
> I undestand the situtation.
>
> I attach V2 patch. I confirmed this doesn't break the logic explained
> above. Could you review this?
>
> Thanks.
> HATAYAMA, Daisuke
Hello Daisuke,
This v2 version tests OK.
The sadump patchset, plus this updated patch, are queued for crash-6.0.0.
Thanks,
Dave
13 years, 1 month
