Re: [Crash-utility] [PATCH 0/4] crash utility: add ARM crashdump support
by Dave Anderson
----- "Mika Westerberg" <ext-mika.1.westerberg(a)nokia.com> wrote:
>
> On Wed, Jun 30, 2010 at 03:10:58PM +0200, ext Dave Anderson wrote:
>
> > In any case, I'm more than happy to fold in ARM support, but I don't know what
> > to do in this case.
> >
> > I wonder if it would it be possible for you, Jan and Thomas to somehow collaborate
> > on this effort? It seems that both sides would benefit from the work of the other
> > side. I've added them to the cc list.
>
> Sure. Can those patches be found in some public ML? I quickly searched but
> couldn't find anything.
>
> Regards,
> MW
Jan is contacting you off-list.
Thanks,
Dave
13 years, 10 months
[crash-utility] [lkcd-devel] Patch to add LKCD vmcore validation feature
by Vitaly Kuzmichev
Hello,
Attached is the patch to add separate tool for validating LKCD netdumps
and blockdumps.
We are planning to add this feature in our fork of crash-3.10.
Our customers requested this feature, but we have found that the 'crash'
does not print any warnings when someone tries to load incomplete
vmcore. They need a simple way to verify if core file generated from
LKCD is complete.
--
Best regards,
Vitaly Kuzmichev, Software Engineer,
MontaVista Software, LLC.
13 years, 10 months
[ANNOUNCE] crash version 5.0.6 is available
by Dave Anderson
- Fix for support of xendump and Xen kdump dumpfiles from 2.6.27 and
and later x86_64 kernels. Without the patch, the crash session
would fail during initialization with the error message "crash:
cannot resolve end_pfn".
(ptesarik(a)suse.cz)
- Fix for the "s390dbf" command to allow the command's output to be
redirected to a pipe.
(holzheu(a)linux.vnet.ibm.com)
- Fix for the x86 "bt" command to generically recognize the end of
trace condition for tasks entering the kernel from user-space without
having to hardwire any more kernel entry point function names.
Without the patch, a task that took a clock interrupt from user-space
and crashed while operating on the soft IRQ stack failed with the
error message "bt: cannot resolve stack trace".
(anderson(a)redhat.com)
- Display the "machine type mismatch" warning when attempting to use a
ppc64 vmlinux file on a non-ppc64 64-bit host. Without the patch,
the fact that ppc64 vmlinux ELF files are type ET_DYN, and not type
ET_EXEC like all of the other architectures, was allowing the vmlinux
to be accepted without the mismatch warning, and would subsequently
fail without a meaningful explanation being displayed.
(anderson(a)redhat.com)
- Fix for the x86_64 "bt" command if the kdump-generated NMI interrupts
a multi-threaded task that has just entered kernel space but has not
changed the RSP stack pointer register from its user-space per-thread
stack location to the kernel stack. Without the patch, the command
follows the display of the exception frame on the NMI exception stack
with the message "WARNING: possibly bogus exception frame", displays
the error message "bt: cannot transition from exception stack to
current process stack", and does not display the user-space exception
frame.
(anderson(a)redhat.com)
- Added the "set" command to the list of commands acceptable when
running in --minimal mode. The command is limited to the setting
of internal variables since there is no task context in that mode.
(anderson(a)redhat.com)
- Fix for the "vtop" command when run against x86 Xen PAE kernels.
Without the patch, the "PAGE:" displays (machine and pseudo-physical)
contained non-zero values in the lower 12 bits, and the translation
of the PTE entry was incorrect as a result of receiving the incorrect
contents in the lower 12-bits of the PTE entry.
(anderson(a)redhat.com)
- Implemented support for running against live x86_64 pv_ops/Xen guest
kernels.
(anderson(a)redhat.com)
- Implemented support for xendump ELF dumpfiles generated from x86_64
pvops/Xen guest kernels.
(anderson(a)redhat.com)
- Implemented support for running against live x86 pv_ops/Xen guest
kernels.
(anderson(a)redhat.com)
- Implemented support for xendump ELF dumpfiles generated from x86
pvops/Xen guest kernels.
(anderson(a)redhat.com)
- Determine the bit positions of PG_reserved and PG_slab using the
newer pageflags enumerator values if available.
(anderson(a)redhat.com)
- Fix to prevent the "repeat" command from keeping a crash session
alive if the controlling terminal session is killed.
(anderson(a)redhat.com)
Download from: http://people.redhat.com/anderson
13 years, 11 months
Re: [Crash-utility] [PATCH 0/4] crash utility: add ARM crashdump support
by Dave Anderson
----- "Mika Westerberg" <ext-mika.1.westerberg(a)nokia.com> wrote:
> Hello Dave,
>
> First of all, thanks for the great tool! It is the best post-mortem analysis
> tool I've ever used.
>
> This series implements ARM support for the crash utility. Current implementation
> provides following:
>
> o Virtual to physical address translation through page tables
> o Stack unwinding support using ARM unwind tables
> o And some more to get minimal support for ARM architecture
>
> There are limitations, however:
>
> o Only one CPU is supported (I don't have access to ARM SMP hardware)
> o No support for stack unwinding with CONFIG_FRAMEPOINTER
> o Only diskdump format is supported (generated by makedumpfile)
>
> These apply on top of crash 5.0.5 sources. Please let me know, if there is
> something that needs to be changed. It would be great if you would consider
> taking these in upstream crash.
Hi Mike,
Actually I have a problem with this -- although I think it's a good one for you...
As I understand it, this patch-set will run on an ARM host against either
an ARM kdump-ELF or makedumpfile-generated dumpfile, and presumably on a
live ARM system.
As it turns out, over the last couple of weeks, I've been going back-and-forth
with another ARM-support patch-set created by Jan Karlsson and Thomas Fange of
Sony Ericcson. However, their patch set is designed to be built on and run
on a 32-bit x86 host, although I think that with a very minor tweak, it could
also could be built and run on an ARM host. For that reason, it doesn't support
running on a live ARM system, but rather only for ARM dumpfiles running
on an x86 host (or x86_64 given its capability of running 32-bit binaries).
In any case, I'm more than happy to fold in ARM support, but I don't know what
to do in this case.
I wonder if it would it be possible for you, Jan and Thomas to somehow collaborate
on this effort? It seems that both sides would benefit from the work of the other
side. I've added them to the cc list.
This should be interesting...
Dave
> With these patches, the crash utility can analyze ARM crashdumps pretty well (at
> least in my testing environment). What is missing, can be implemented later on
> when we have kernel[1] support and users.
>
> After this, all necessary userspace components should be ready for ARM
> architecture (kexec-tools, makedumpfile and crash utility).
>
> I've tested this on OMAP3 based platforms with 2.6.32 and latest mainline
> kernels (with the kdump patches).
>
> Regards,
> MW
>
> [1]
> Note that kernel crashdump support is not yet in mainline but I'm hoping that it
> will be merged eventually (patches are in RMK's patch tracker already).
>
> Mika Westerberg (4):
> configure: add support for ARM targets
> crash: add support for ARM kernel image
> crash: add ARM diskdump support
> crash: add ARM crashdump support
>
> Makefile | 12 +-
> arm.c | 1188
> +++++++++++++++++++++++++++++++++++++++++++++++++++
> configure.c | 14 +
> defs.h | 131 ++++++
> diskdump.c | 50 ++-
> kernel.c | 2 +-
> lkcd_vmdump_v2_v3.h | 4 +-
> symbols.c | 8 +-
> unwind_arm.c | 702 ++++++++++++++++++++++++++++++
> 9 files changed, 2102 insertions(+), 9 deletions(-)
> create mode 100644 arm.c
> create mode 100644 unwind_arm.c
14 years
