[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.
15 years, 9 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
15 years, 10 months
[PATCH 0/4] crash utility: add ARM crashdump support
by Mika Westerberg
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.
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
15 years, 10 months
Re: [Crash-utility] infinite loop in crash due to double-NMI on x86_64 system
by Dave Anderson
----- "Petr Tesarik" <ptesarik(a)suse.cz> wrote:
> Silacci, Lucas píše v Po 28. 06. 2010 v 17:26 -0400:
> > The dumpsw_notify function is part of a driver that was added to our
> > systems to trigger kernel panics when an NMI occurs. In the version of
> > the kernel we are using (SLES 10 SP1) this was necessary to cause an
> > actual panic to happen and a dump to be saved when an NMI occurred
> > (especially due to a dump switch being pressed, hence the name).
> >
> > That driver registers a callback (dumpsw_notify) into the die_chain and
> > calls panic() if the die code is a DIE_NMI.
>
> Hi,
>
> my opinion is that a NMI is ... well, a non-maskable interrupt. Which
> means there is nothing the kernel could possibly do to prevent the NMI
> handler itself from being interrupted by another NMI. Whatever the
> reason for it.
Really? According to the AMD x86_64 manual -- note the "Masking" section:
8.3.3 NMI-Non-Maskable-Interrupt Exception (Vector 2)
An NMI exception occurs as a result of system logic signalling a
non-maskable interrupt to the processor.
Error Code Returned: None.
Program Restart: NMI is an interrupt. The processor recognizes an NMI
at an instruction boundary. The saved instruction pointer points to the
instruction immediately following the boundary where the NMI was recognized.
Masking: NMI cannot be masked. However, when an NMI is executed by the
processor, recognition of subsequent NMIs are disabled until an IRET
instruction is executed.
And looking at the backtrace, I'm still having a hard time understanding how
it was possible. What am I missing?
Dave
> Having the crash utility loop forever on such dumps is annoying, at the
> very least. And I imagine, such hangs could cause quite some headache to
> Louis Bouchard. ;)
>
> Just my $0.02,
> Petr Tesarik
> PID: 0 TASK: ffffffff8038c340 CPU: 0 COMMAND: "swapper"
> #0 [ffffffff8046dc50] machine_kexec at ffffffff8011a95b
> #1 [ffffffff8046dd20] crash_kexec at ffffffff80154351
> #2 [ffffffff8046dde0] panic at ffffffff801327fa
> #3 [ffffffff8046ded0] dumpsw_notify at ffffffff8831c0c3
> #4 [ffffffff8046dee0] notifier_call_chain at ffffffff8032481f
> #5 [ffffffff8046df00] default_do_nmi at ffffffff80322fab
> #6 [ffffffff8046df40] do_nmi at ffffffff80323365
> #7 [ffffffff8046df50] nmi at ffffffff8032268f
> [exception RIP: smp_send_stop+84]
> RIP: ffffffff80116e44 RSP: ffffffff8046ddd8 RFLAGS: 00000246
> RAX: 00000000000000ff RBX: ffffffff8831c1f8 RCX: 000041049c7256e8
> RDX: 0000000000000005 RSI: 000000005238a938 RDI: 00000000002896a0
> RBP: ffffffff8046df08 R8: 00000000000040fb R9: 000000005238a7e8
> R10: 0000000000000002 R11: 0000ffff0000ffff R12: 000000000000000c
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> --- <NMI exception stack> ---
> #8 [ffffffff8046ddd8] smp_send_stop at ffffffff80116e44
15 years, 10 months
Re: [Crash-utility] crash fails to load compressed RHEL5 vmcore
by Dave Anderson
----- "marc pascual" <marc.m.pascual(a)gmail.com> wrote:
> Dave,
>
> Thank you for your reply. However I'm slightly confused. the kernel
> version where I got the vmcore file is 2.6.18-92.1.10.el5 (x86_64).
> From my previous understanding, I should download and install
> kernel-debug-debuginfo-2.6.18-92.1.10.el5.x86_64.rpm. This package
> gives me 2.6.18-92.1.10.el5debug. However you mentioned that:
>
> "They 2.6.18-92.1.10.el5 and 2.6.18-92.1.10.el5debug kernels are
> completely different kernels."
>
> If this is the case, which package can I get
> 2.6.18-92.1.10.el5/vmlinux from? Assuming this is not the same kernel
> under /boot?
The short answer is: kernel-debuginfo-2.6.18-92.1.10.el5.x86_64.rpm
That RHEL5 kernel version offers 3 different x86_64 kernel packages:
kernel-2.6.18-92.1.10.el5.x86_64.rpm
kernel-xen-2.6.18-92.1.10.el5.x86_64.rpm
kernel-debug-2.6.18-92.1.10.el5.x86_64.rpm
Each of the above has its own associated debuginfo package,
which contains the relevant vmlinux file for that kernel
type:
kernel-debuginfo-2.6.18-92.1.10.el5.x86_64.rpm
kernel-xen-debuginfo-2.6.18-92.1.10.el5.x86_64.rpm
kernel-debug-debuginfo-2.6.18-92.1.10.el5.x86_64.rpm
And when installing any of the -debuginfo packages above,
rpm requires that the kernel-debuginfo-common package be
installed along with it:
kernel-debuginfo-common-2.6.18-92.1.10.el5.x86_64.rpm
Like the name says, the "common" package has debuginfo
data that is the same for all 3 kernel types.
Dave
15 years, 10 months
Re: [Crash-utility] infinite loop in crash due to double-NMI on x86_64 system
by Dave Anderson
----- "Lucas Silacci" <Lucas.Silacci(a)teradata.com> wrote:
> Sorry, guess I wasn't clear. Nobody hit the dump switch on these
> systems. They simply had multiple hardware errors that apparently
> triggered the NMI more than once. That's what I was trying to show with
> the SEL records, that the multiple NMIs were straight from hardware with
> no human intervention.
>
> The systems went through a panic (due to multiple NMIs),
That's what I'm trying to figure out -- when and how was it decided that
the machine should panic instead of continuing to handle the stream of NMIs?
In other words, this "dumpsw_notify" function -- why was it called?
> > PID: 0 TASK: ffffffff8038c340 CPU: 0 COMMAND: "swapper"
> > #0 [ffffffff8046dc50] machine_kexec at ffffffff8011a95b
> > #1 [ffffffff8046dd20] crash_kexec at ffffffff80154351
> > #2 [ffffffff8046dde0] panic at ffffffff801327fa
> > #3 [ffffffff8046ded0] dumpsw_notify at ffffffff8831c0c3
> > #4 [ffffffff8046dee0] notifier_call_chain at ffffffff8032481f
> > #5 [ffffffff8046df00] default_do_nmi at ffffffff80322fab
> > #6 [ffffffff8046df40] do_nmi at ffffffff80323365
> > #7 [ffffffff8046df50] nmi at ffffffff8032268f
> > [exception RIP: smp_send_stop+84]
> > RIP: ffffffff80116e44 RSP: ffffffff8046ddd8 RFLAGS: 00000246
> > RAX: 00000000000000ff RBX: ffffffff8831c1f8 RCX: 000041049c7256e8
> > RDX: 0000000000000005 RSI: 000000005238a938 RDI: 00000000002896a0
> > RBP: ffffffff8046df08 R8: 00000000000040fb R9: 000000005238a7e8
> > R10: 0000000000000002 R11: 0000ffff0000ffff R12: 000000000000000c
> > R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> > ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> > --- <NMI exception stack> ---
> > #8 [ffffffff8046ddd8] smp_send_stop at ffffffff80116e44
>From what you're implying, there is no physical "dump switch".
So I'm trying figure out where that "dumpsw_notify()" function
comes from? Whose module is that and what is its purpose?
Dave
> a reboot, and
> then crash was run on the resulting dump. In fact crash was
> automatically run via a startup script and there was no human
> intervention until after it was noticed that crash was filling up the
> root file system with a temporary file due to the inifinite loop.
15 years, 10 months
infinite loop in crash due to double-NMI on x86_64 system
by Silacci, Lucas
Hi,
I've run into an issue where crash will enter an infinite loop while
decoding exception stacks if those stacks get corrupted.
We've seen this on four different systems where the hardware generated
multiple NMIs and the second and subsequent NMIs caused the NMI
exception stack to be overwritten. When this condition is hit, the
bottom rsp on the NMI exception stack (which would normally point you
back to the kernel thread stack or possibly a different exception stack)
points you back into the middle of the same NMI exception stack. This
causes crash to infinitely loop when it tries to decode that exception
stack.
Now clearly the root cause of the issue is faulty hardware that
generated multiple NMIs. However a very small change in crash can detect
this issue and stop the infinite loop from happening thereby allowing
you to get to a point in crash where you can actually tell that it was
an NMI that caused the system to dump.
The patch is attached to this email. For x86_64 it will detect the
condition of any exception stack that points back at itself.
Please feel free to ask me any questions on this.
Thanks,
-Lucas
15 years, 10 months
Extensions in C++
by Ratnam Tatavarty
Hi,
I am looking for a way to code/compile my Crash tool extension .so in CPP.
During compile step, I hit a name collision with "namespace" keyword upon
including defs.h.
Does anyone try any CPP extensions before and if yes are there any
guidelines/suggestions
about the required changes, compile options? Any insights about Crash
compatibility with CPP
are greatly appreciated.
Build errors:
defs.h:1917: error: expected identifier before ‘namespace’
defs.h:1917: error: expected unqualified-id before ‘namespace’
defs.h:1956: error: expected identifier before ‘namespace’
...
defs.h:2967: error: expected unqualified-id before ‘typename’
defs.h:2967: error: abstract declarator ‘char*’ used as declaration
defs.h:2967: error: expected ‘;’ before ‘typename’
Thanks and Regads,
Ratnam
15 years, 10 months
Re: [Crash-utility] crash fails to load compressed RHEL5 vmcore
by Dave Anderson
----- "marc pascual" <marc.m.pascual(a)gmail.com> wrote:
> Hello,
>
> I have this issue with compressed RHEL5 vmcore files, I can't get it
> to loaded to the crash utility. I don't have this problem with RHEL4 vmcores (diskdump).
> The debuginfo kernel exactly matches the kernel version that generated
> the vmcore
>
> [root@test-fc12 ~]# crash usr/lib/debug/lib/modules/2.6.18-92.1.10.el5debug/vmlinux /nas01/cores/2.6.18-92.1.10.el5.vmcore
>
> crash 4.0.9-2.fc12
> Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 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: page excluded: kernel virtual address: ffffffff804f1260 type: "possible"
> WARNING: cannot read cpu_possible_map
> crash: usr/lib/debug/lib/modules/2.6.18-92.1.10.el5debug/vmlinux and
> /nas01/cores/2.6.18-92.1.10.el5.vmcore do not match!
>
> Usage:
> crash [-h [opt]][-v][-s][-i file][-d num] [-S] [mapfile] [namelist]
> [dumpfile]
>
> Enter "crash -h" for details.
>
> [root@test-fc12 ~]# strings usr/lib/debug/lib/modules/2.6.18-92.1.10.el5debug/vmlinux | grep 2.6 | head -2
> Linux version 2.6.18-92.1.10.el5debug (brewbuilder(a)ls20-bc2-13.build.redhat.com ) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Wed Jul 23 04:27:38 EDT 2008
>
> running strings on the rhel5 vmcore file:
>
> [root@test-fc12 cores]# strings 2.6.18-92.1.10.el5.vmcore | grep 2.6 |
> head -2
> 2X6
> 2T6(
If the diskdump was compressed (and with "makedumpfile -c" it is), then unfortunately
looking for the "Linux version" string won't help. The utsname data may be in the
compressed kdump header in more recent versions, so if you entered this:
# crash -d1 vmlinux vmcore
...
then the dumpfile header will be immediately dumped, and the utsname has most of
the relevant data from the "Linux version" string:
diskdump_data:
filename: (null)
flags: 6 (KDUMP_CMPRS_LOCAL|ERROR_EXCLUDED)
dfd: 3
ofp: 0
machine_type: 62 (EM_X86_64)
header: 19c42fe0
signature: "KDUMP "
header_version: 1
utsname:
sysname: Linux
nodename: hp-dl585g2-01.rhts.bos.redhat.com
release: 2.6.18-164.el5
version: #1 SMP Tue Aug 18 15:51:48 EDT 2009
machine: x86_64
domainname: (none)
But this was fixed fairly recently in makedumpfile, your dump may show
a bunch of (null) strings for the utsname data.
One thing I notice is that the vmlinux file is "2.6.18-92.1.10.el5debug",
and although you haven't shown exactly what kernel the crashed kernel
was running, you've named it "2.6.18-92.1.10.el5.vmcore". If the crashed
kernel was running 2.6.18-92.1.10.el5, then you're using the wrong vmlinux
file, and you should be using:
/usr/lib/debug/lib/modules/2.6.18-92.1.10.el5/vmlinux
They 2.6.18-92.1.10.el5 and 2.6.18-92.1.10.el5debug kernels are completely
different kernels.
If we presume that the crashed kernel and the vmlinux are *both* the "debug"
variety, then if you extend the debug data output by entering -d4, you'll see
every read attempt made from the dumpfile:
# crash -d4 vmlinux vmcore
... [ snip ] ...
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"...
<readmem: ffffffff80447280, KVADDR, "possible", 32, (ROE), c8fce0>
cpu_possible_map: 0 1 2 3 4 5 6 7
<readmem: ffffffff803ed5a0, KVADDR, "present", 32, (ROE), c8fce0>
cpu_present_map: 0 1 2 3 4 5 6 7
<readmem: ffffffff803e8260, KVADDR, "online", 32, (ROE), c8fce0>
cpu_online_map: 0 1 2 3 4 5 6 7
<readmem: ffffffff803ef200, KVADDR, "xtime", 16, (FOE), b50130>
<readmem: ffffffff80301320, KVADDR, "system_utsname", 390, (ROE), b5071c>
...
So, you can see that the very first readmem() is the cpu_possible_map bitmap.
And in your case:
> crash: page excluded: kernel virtual address: ffffffff804f1260 type: "possible"
> WARNING: cannot read cpu_possible_map
That first readmem() attempt failed because the page was explicitly
excluded by makedumpfile. But if makedumpfile's page exclusion mechanism
excluded the page containing that kernel data, I'd be very surprised.
Dave
> does makedumpconfig's compression have something to do with this? from
> kdump.conf on the machine where i got that vmcore:
> ...
> core_collector makedumpfile -c -d31
> ...
>
> Thank you in advace!
>
> Regards,
> Marc
>
15 years, 10 months
crash fails to load compressed RHEL5 vmcore
by marc pascual
Hello,
I have this issue with compressed RHEL5 vmcore files, I can't get it to
loaded to the crash utility. I don't have this problem with RHEL4 vmcores
(diskdump).
The debuginfo kernel exactly matches the kernel version that generated the
vmcore
[root@test-fc12 ~]# crash
> usr/lib/debug/lib/modules/2.6.18-92.1.10.el5debug/vmlinux
> /nas01/cores/2.6.18-92.1.10.el5.vmcore
>
> crash 4.0.9-2.fc12
> Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 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: page excluded: kernel virtual address: ffffffff804f1260 type:
> "possible"
> WARNING: cannot read cpu_possible_map
> crash: usr/lib/debug/lib/modules/2.6.18-92.1.10.el5debug/vmlinux and
> /nas01/cores/2.6.18-92.1.10.el5.vmcore do not match!
>
> Usage:
> crash [-h [opt]][-v][-s][-i file][-d num] [-S] [mapfile] [namelist]
> [dumpfile]
>
> Enter "crash -h" for details.
>
[root@test-fc12 ~]# strings
> usr/lib/debug/lib/modules/2.6.18-92.1.10.el5debug/vmlinux | grep 2.6 | head
> -2
> Linux version 2.6.18-92.1.10.el5debug (
> brewbuilder(a)ls20-bc2-13.build.redhat.com) (gcc version 4.1.2 20071124 (Red
> Hat 4.1.2-42)) #1 SMP Wed Jul 23 04:27:38 EDT 2008
> 2.6.18-92.1.10.el5debug SMP mod_unload gcc-4.1
>
running strings on the rhel5 vmcore file:
[root@test-fc12 cores]# strings 2.6.18-92.1.10.el5.vmcore | grep 2.6 | head
> -2
> 2X6
> 2T6(
>
does makedumpconfig's compression have something to do with this? from
kdump.conf on the machine where i got that vmcore:
...
> core_collector makedumpfile -c -d31
> ...
>
Thank you in advace!
Regards,
Marc
15 years, 10 months
