Why module's global symbol cannot be displayed in crash?
by Lei Wen
Hi list,
I find in current 6.1.4 crash, when load module with "mod -S",
only module's function symbol could be parsed out.
But for module's global variant, crash cannot find related symbol...
Any idea for this?
Thanks,
Lei
11 years, 8 months
Re: [Crash-utility] Why module's global symbol cannot be displayed in crash? [ARM]
by Dave Anderson
----- Original Message -----
> On Wed, Mar 20, 2013 at 10:56 PM, Dave Anderson <anderson(a)redhat.com>
> wrote:
> >
> >
> > ----- Original Message -----
> >
> >> >
> >> > On that note, I only have a handful of sample ARM vmcore
> >> > dumpfiles,
> >> > and none of their kernels have any modules. My supposition was
> >> > that
> >> > it is simply common usage that ARM kernels are built without
> >> > modules
> >> > because of their typically embedded use-cases.
> >> >
> >> > In any case, if somebody can make a sample ARM vmcore available
> >> > to
> >> > me that does have modules, I'd appreciate having it on hand for
> >> > testing.
> >> >
> >>
> >> Here is one such dump file: http://sdrv.ms/ZTjmUn
> >> For I don't want anyone to access it, I don't post towards the
> >> maillist.
> >>
> >> Thanks,
> >> Lei
> >>
> >
> > Got them -- thanks!
> >
> > I note that when running with an x86_64 binary that I built
> > using "make target=ARM", that I don't see data or bss symbols
> > either before or after loading the modules. I did this:
>
> So what it means?...
> Kernel build method is wrong?
>
> I don't understand why module would be showed in the "before" file,
> shouldn't it only existed in "after" file for module being loaded?
>
> Should I do anything else to check?...
>
> Thanks,
> Lei
With respect to "mod -[sS]", it seems to be a problem that can be partially
addressed by doing this:
--- crash/symbols.c 2013-03-21 10:00:10.173201102 -0400
+++ ARM_crash-6.1.4/symbols.c 2013-03-21 10:06:01.531186455 -0400
@@ -10560,7 +10560,7 @@
break;
}
}
- if (i < lm->mod_sections) {
+ if (i <= lm->mod_sections) {
if (CRASHDEBUG(2))
fprintf(fp, "%08lx (%c) [%s] %s\n",
(ulong)syminfo.value,
And then it would also require filtering out the symbols types, because doing
the above also captures (U) and (a) types.
But it's ARM-specific, though, because the patch above causes problems with
x86_64.
Dave
11 years, 8 months
is_page_ptr vs. x86_64_kvtop
by Bruce Korb
Hi Dave, et al.,
I have this little problem. I am trying to get a lustre file system
extension working again. It used to work, but does no more.
It first calls is_page_ptr(kvaddr, &kpaddr) to convert a virtual
address into a physical address, and then calls:
> readmem(kpaddr, PHYSADDR, buf, used,
> "trace page data", RETURN_ON_ERROR)
to fetch the bytes. Updating the release to SLES-11 SP2 causes
this to now fail. In my debugging of crash/gdb, this:
> is_page_ptr (addr=18446719884937843744, phys=0x7fffffffd370) at memory.c:11448
> 11448 if (IS_SPARSEMEM()) {
> (gdb) p/x addr
> $8 = 0xffffea001cdad420
is about to fail. However, this:
> crash> gdb x/4xg 0xffffea001cdad420
works just fine. I've stepped through x_command until it gets to
x86_64_kvtop() where I'm finding the logic a little twisty.
But it pretty clearly does not rely on section_mem_map_addr() stuff.
So, here's my point: this is confusing. What should I look for
to determine why "is_page_ptr()" is saying 0xffffea001cdad420
is invalid while "x86_64_kvtop()" is saying that it is and its
physical address is 0x87afad420?
> 878 return(readmem(addr, memtype, buf, len,
> (gdb) s
> readmem (addr=0xffffea001cdad420, memtype=0x1, buffer=0x5d85d10, size=0x8,
> type=0x945f0a "gdb_readmem_callback", error_handle=0x2) at memory.c:1991
>
> 0xffffea001cdad420: PML4 DIRECTORY: ffffffff81623000
> PAGE DIRECTORY: 87fff7067
> PUD: 87fff7000 => 87fff6067
> PMD: 87fff6730 => 800000087ae001e3
> PAGE: 87ae00000 (2MB)
> PTE PHYSICAL FLAGS
> 800000087ae001e3 87ae00000 (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL|NX)
> (gdb) p physpage
> $34 = 0x87afad420
0xffffea001cdad420: 0x0200000000000000 0xffffffff00000001
0xffffea001cdad430: 0x0000000000000000 0x0000000000000000
Help, please? Thank you!
11 years, 8 months
[PATCH]fix kmem -s(slab) to support Linux 3.7 and later
by qiaonuohan
Hello Dave,
When using crash on Linux 3.8, I found kmem -s is not working well.
After some investigations, I got to know commit
3c58346525d82625e68e24f071804c2dc057b6f4 changes the usage of
kmem_cache.array, nodelists is also stored in it, which caused original
code failed to work.
I made some fix, please refer to the attachment.
--
--
Regards
Qiao Nuohan
11 years, 8 months
[PATCH 0/2] crash: Bundle of fixes for Xen
by Daniel Kiper
Hi,
Here is next bundle of fixes for crash Xen support:
- xen: Improve calculation of beginning of virtual address space,
- xen: Fix console buffer content length calculation.
All patches were tested with Xen versions up to latest unstable.
Daniel
11 years, 8 months
[PATCH 1/2] xen: Improve calculation of beginning of virtual address space
by Daniel Kiper
Xen changeset 26447 (x86: re-introduce map_domain_page() et al) once again
altered virtual address space. Current algorithm calculating its start could
not cope with that change. New version establishes this value on the base of
image start address and is more generic.
Signed-off-by: Daniel Kiper <daniel.kiper(a)oracle.com>
diff -Npru crash-6.1.4.orig/xen_hyper.c crash-6.1.4/xen_hyper.c
--- crash-6.1.4.orig/xen_hyper.c 2013-02-14 21:38:54.000000000 +0100
+++ crash-6.1.4/xen_hyper.c 2013-03-15 13:11:16.595713662 +0100
@@ -43,10 +43,14 @@ xen_hyper_init(void)
#endif
#ifdef X86_64
- if (xen_major_version() >= 4)
- xht->xen_virt_start = 0xffff82c480000000;
- else
- xht->xen_virt_start = 0xffff828c80000000;
+ xht->xen_virt_start = symbol_value("start");
+
+ /*
+ * Xen virtual mapping is aligned to 1 GiB boundary.
+ * Image starts no more than 1 GiB below
+ * beginning of virtual address space.
+ */
+ xht->xen_virt_start &= 0xffffffffc0000000;
#endif
if (machine_type("X86_64") &&
11 years, 8 months
[PATCH 2/2] xen: Fix console buffer content length calculation
by Daniel Kiper
Function displaying console buffer always assumes its content lenght
equal to console buffer size. This is not true and sometimes it sends
garbage to the screen. This patch fixes this issue.
Additionally, remove references to unused conringc variable.
Signed-off-by: Daniel Kiper <daniel.kiper(a)oracle.com>
diff -Npru crash-6.1.4.orig/xen_hyper_command.c crash-6.1.4/xen_hyper_command.c
--- crash-6.1.4.orig/xen_hyper_command.c 2013-02-14 21:38:54.000000000 +0100
+++ crash-6.1.4/xen_hyper_command.c 2013-03-14 15:03:58.045075917 +0100
@@ -585,11 +585,10 @@ xen_hyper_cmd_log(void)
void
xen_hyper_dump_log(void)
{
- uint conringc, conringp;
- uint warp, start, len, idx, i;
+ uint conringp, warp, len, idx, i;
ulong conring;
char *buf;
- char last;
+ char last = 0;
uint32_t conring_size;
if (get_symbol_type("conring", NULL, NULL) == TYPE_CODE_ARRAY)
@@ -597,7 +596,6 @@ xen_hyper_dump_log(void)
else
get_symbol_data("conring", sizeof(ulong), &conring);
- get_symbol_data("conringc", sizeof(uint), &conringc);
get_symbol_data("conringp", sizeof(uint), &conringp);
if (symbol_exists("conring_size"))
@@ -605,21 +603,19 @@ xen_hyper_dump_log(void)
else
conring_size = XEN_HYPER_CONRING_SIZE;
- warp = FALSE;
if (conringp >= conring_size) {
- if ((start = conringp & (conring_size - 1))) {
- warp = TRUE;
- }
+ idx = conringp & (conring_size - 1);
+ len = conring_size;
+ warp = TRUE;
} else {
- start = 0;
+ idx = 0;
+ len = conringp;
+ warp = FALSE;
}
buf = GETBUF(conring_size);
readmem(conring, KVADDR, buf, conring_size,
"conring contents", FAULT_ON_ERROR);
- idx = start;
- len = conring_size;
- last = 0;
wrap_around:
for (i = idx; i < len; i++) {
11 years, 8 months
[PATH] crash: Fix "dev -d" for recent kernels
by Michael Holzheu
Hello Dave,
The following kernel commit changes the member "rq" to member
"root_rl" in the request_queue structure:
commit a051661ca6d134c18599498b185b667859d4339b
Author: Tejun Heo <tj(a)kernel.org>
Date: Tue Jun 26 15:05:44 2012 -0700
blkcg: implement per-blkg request allocation
- struct request_list rq;
+ struct request_list root_rl;
This breaks the "dev -d" crash command:
crash> dev -d
MAJOR GENDISK NAME REQUEST QUEUE TOTAL ASYNC SYNC DRV
dev: invalid structure member offset: request_queue_rq
FILE: dev.c LINE: 3807 FUNCTION: get_diskio_1()
80116438: OFFSET_verify+96
800f55da: get_diskio_1+62
800f5c52: display_all_diskio+1318
8006ff1c: exec_command+972
dev: invalid structure member offset: request_queue_rq
FILE: dev.c LINE: 3807 FUNCTION: get_diskio_1()
The following fix just uses "root_rl" instead of "rq". Not completely sure, if
this is sufficient.
With the fix on my s390 system I get:
crash> dev -d
MAJOR GENDISK NAME REQUEST QUEUE TOTAL ASYNC SYNC DRV
94 0x1ea144a8 dasda 0x1ebcc2b8 0 0 0 0
9 0x1e93d9c8 md0 0x1ebcb560 0 0 0 0
---
dev.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/dev.c
+++ b/dev.c
@@ -4050,7 +4050,11 @@ void diskio_init(void)
MEMBER_OFFSET_INIT(request_list_count, "request_list", "count");
MEMBER_OFFSET_INIT(request_queue_in_flight, "request_queue",
"in_flight");
- MEMBER_OFFSET_INIT(request_queue_rq, "request_queue", "rq");
+ if (MEMBER_EXISTS("request_queue", "rq"))
+ MEMBER_OFFSET_INIT(request_queue_rq, "request_queue", "rq");
+ else
+ MEMBER_OFFSET_INIT(request_queue_rq,
+ "request_queue", "root_rl");
MEMBER_OFFSET_INIT(subsys_private_klist_devices, "subsys_private",
"klist_devices");
MEMBER_OFFSET_INIT(subsystem_kset, "subsystem", "kset");
11 years, 8 months
whatis: display full parameter name when symbol is function
by Lei Wen
Dave,
Here is the patch which add feature to whatis that would display full
parameter name
when it detect the symbol is a function.
And this patch already include previous fix for gdb_get_datatype,
please help review it.
Thanks,
Lei
>From 8ea80a2ddbd0ea524a715a5e188118c39a0ce311 Mon Sep 17 00:00:00 2001
From: Lei Wen <leiwen(a)marvell.com>
Date: Mon, 11 Mar 2013 10:34:15 +0800
Subject: [PATCH] whatis: display full parameter name when symbol is function
Signed-off-by: Lei Wen <leiwen(a)marvell.com>
---
defs.h | 1 +
gdb-7.3.1.patch | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
gdb_interface.c | 3 ++
symbols.c | 50 +++++++++++++++++++++++++++++++++++-
4 files changed, 130 insertions(+), 1 deletions(-)
diff --git a/defs.h b/defs.h
index 1f693c3..1b31d1f 100755
--- a/defs.h
+++ b/defs.h
@@ -3685,6 +3685,7 @@ struct gnu_request {
#define GNU_GET_SYMBOL_TYPE (15)
#define GNU_USER_PRINT_OPTION (16)
#define GNU_SET_CRASH_BLOCK (17)
+#define GNU_FUNCTION_NAMEARGS (18)
#define GNU_DEBUG_COMMAND (100)
/*
* GNU flags
diff --git a/gdb-7.3.1.patch b/gdb-7.3.1.patch
index a12d3d4..3b0f0d1 100644
--- a/gdb-7.3.1.patch
+++ b/gdb-7.3.1.patch
@@ -1821,3 +1821,80 @@ diff -up gdb-7.3.1/gdb/psymtab.c.orig
gdb-7.3.1/gdb/psymtab.c
break;
if (cur_sec == NULL)
+--- gdb-7.3.1/gdb/symtab.c.orig
++++ gdb-7.3.1/gdb/symtab.c
+@@ -4848,6 +4848,7 @@ static void gdb_get_symbol_type(struct gnu_request *);
+ static void gdb_command_exists(struct gnu_request *);
+ static void gdb_debug_command(struct gnu_request *);
+ static void gdb_function_numargs(struct gnu_request *);
++static void gdb_function_nameargs(struct gnu_request *);
+ static void gdb_add_symbol_file(struct gnu_request *);
+ static void gdb_delete_symbol_file(struct gnu_request *);
+ static void gdb_patch_symbol_values(struct gnu_request *);
+@@ -4952,6 +4953,10 @@ gdb_command_funnel(struct gnu_request *req)
+ gdb_set_crash_block(req);
+ break;
+
++ case GNU_FUNCTION_NAMEARGS:
++ gdb_function_nameargs(req);
++ break;
++
+ default:
+ req->flags |= GNU_COMMAND_FAILED;
+ break;
+@@ -5054,8 +5059,9 @@ gdb_get_datatype(struct gnu_request *req)
+ if (gdb_CRASHDEBUG(2))
+ console("expr->elts[0].opcode: OP_VAR_VALUE\n");
+ type = expr->elts[2].symbol->type;
++ req->typecode = TYPE_CODE(type);
++ req->length = TYPE_LENGTH(type);
+ if (TYPE_CODE(type) == TYPE_CODE_ENUM) {
+- req->typecode = TYPE_CODE(type);
+ req->value = SYMBOL_VALUE(expr->elts[2].symbol);
+ req->tagname = TYPE_TAG_NAME(type);
+ if (!req->tagname) {
+@@ -5243,6 +5249,44 @@ gdb_function_numargs(struct gnu_request *req)
+ req->value = (ulong)TYPE_NFIELDS(sym->type);
+ }
+
++static void
++gdb_function_nameargs(struct gnu_request *req)
++{
++ struct block *b;
++ struct dict_iterator iter;
++ struct symbol *sym = NULL;
++ int len;
++ char *buf = req->buf;
++
++ b = block_for_pc_sect(req->pc, find_pc_mapped_section(req->pc));
++ /* Get the lexical block, which is not a inline function */
++ while ((BLOCK_FUNCTION(b) == NULL || block_inlined_p(b))
++ && BLOCK_SUPERBLOCK(b) != NULL)
++ b = BLOCK_SUPERBLOCK(b);
++
++ ALL_BLOCK_SYMBOLS (b, iter, sym)
++ {
++ if (!SYMBOL_IS_ARGUMENT (sym))
++ continue;
++
++ if (*SYMBOL_LINKAGE_NAME (sym))
++ {
++ struct symbol *nsym;
++
++ nsym = lookup_symbol (SYMBOL_LINKAGE_NAME (sym),
++ b, VAR_DOMAIN, NULL);
++ gdb_assert (nsym != NULL);
++ if (SYMBOL_CLASS (nsym) != LOC_REGISTER
++ || SYMBOL_IS_ARGUMENT (nsym))
++ sym = nsym;
++ }
++
++ len = strlen(SYMBOL_PRINT_NAME(sym));
++ sprintf(buf, "%s,", SYMBOL_PRINT_NAME(sym));
++ buf += len + 1;
++ }
++}
++
+ struct load_module *gdb_current_load_module = NULL;
+
+ static void
diff --git a/gdb_interface.c b/gdb_interface.c
index afc197c..a460ea8 100755
--- a/gdb_interface.c
+++ b/gdb_interface.c
@@ -590,6 +590,9 @@ gdb_command_string(int cmd, char *buf, int live)
case GNU_SET_CRASH_BLOCK:
sprintf(buf, "GNU_SET_CRASH_BLOCK");
break;
+ case GNU_FUNCTION_NAMEARGS:
+ sprintf(buf, "GNU_FUNCTION_NAMEARGS");
+ break;
case 0:
buf[0] = NULLCHAR;
break;
diff --git a/symbols.c b/symbols.c
index 4fb397c..b38a2a3 100755
--- a/symbols.c
+++ b/symbols.c
@@ -6660,18 +6660,62 @@ whatis_datatype(char *st, ulong flags, FILE *ofp)
}
/*
+ * add the function argument to the function type showing
+ * The arg name input is seperated by comma
+ */
+static void
+add_function_name(char *argnames, char *func)
+{
+ char *arg, *seperator, *tmp;
+
+ tmp = func;
+ for (arg = strtok(argnames, ","); arg; ) {
+ seperator = strstr(tmp, ",");
+ if (!seperator)
+ seperator= strrchr(func, ')');
+
+ shift_string_right(seperator, strlen(arg) + 1);
+ BCOPY(arg, seperator + 1, strlen(arg));
+ tmp = seperator + 2 + strlen(arg);
+ arg = strtok(NULL, ",");
+ }
+}
+
+/*
* Scan the symbol file for a variable declaration.
*/
static void
whatis_variable(struct syment *sp)
{
+ struct datatype_member datatype_member, *dm;
+ struct gnu_request *req;
+ int ret;
char *p1;
char buf[BUFSIZE];
+ dm = &datatype_member;
+ strcpy(buf, sp->name);
+ if (!arg_to_datatype(buf, dm, RETURN_ON_ERROR|DATATYPE_QUERY))
+ return FALSE;
+
open_tmpfile();
sprintf(buf, "whatis %s", sp->name);
- if (!gdb_pass_through(buf, fp, GNU_RETURN_ON_ERROR)) {
+
+ req = (struct gnu_request *)GETBUF(sizeof(struct gnu_request));
+ req->buf = GETBUF(BUFSIZE);
+
+ ret = gdb_pass_through(buf, fp, GNU_RETURN_ON_ERROR);
+ if (ret && dm->type == FUNCTION) {
+ req->command = GNU_FUNCTION_NAMEARGS;
+ req->flags |= GNU_RETURN_ON_ERROR;
+ req->pc = symbol_value(sp->name);
+
+ gdb_interface(req);
+ }
+ if (!ret || req->flags & GNU_COMMAND_FAILED) {
close_tmpfile();
+ FREEBUF(req->buf);
+ FREEBUF(req);
error(FATAL, "gdb request failed: whatis %s\n", sp->name);
}
@@ -6693,6 +6737,7 @@ whatis_variable(struct syment *sp)
if (index(buf, '(') == rindex(buf, '(')) {
shift_string_right(p1, strlen(sp->name));
BCOPY(sp->name, p1, strlen(sp->name));
+ add_function_name(req->buf, p1 + strlen(sp->name));
} else {
p1 = strstr(buf, ")");
shift_string_right(p1, strlen(sp->name));
@@ -6705,6 +6750,9 @@ whatis_variable(struct syment *sp)
fprintf(fp, "%s%s%s;\n", p1, LASTCHAR(p1) == '*' ? "":" ",
sp->name);
}
+
+ FREEBUF(req->buf);
+ FREEBUF(req);
}
/*
--
1.7.5.4
11 years, 8 months
Re: [Crash-utility] SLES 9 Dump
by Ku, Eugene
I tried again using kerntypes and it failed with a different error.
# /RedHat/crash-6.1.0-X86/crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504 Kerntypes-2.6.5-7.321-bigsmp
...
crash: cannot resolve "_stext"
Eugene
-----Original Message-----
From: Ku, Eugene
Sent: Tuesday, March 05, 2013 6:04 PM
To: Dave Anderson
Cc: Ku, Eugene
Subject: RE: [Crash-utility] SLES 9 Dump
Dave,
I rebuilt 6.1.0 crash as you had suggested.
# file /RedHat/crash-6.1.0-X86/crash
/RedHat/crash-6.1.0-X86/crash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
I then ran it against the dump. I got the following error messages.
# /RedHat/crash-6.1.0-X86/crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504
...
crash: vmlinux-2.6.5-7.321-bigsmp: no debugging data available
I tried again with additional System.map but got the same error.
# /RedHat/crash-6.1.0-X86/crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504 System.map-2.6.5-7.321-bigsmp
...
crash: vmlinux-2.6.5-7.321-bigsmp: no debugging data available
Eugene
-----Original Message-----
From: Dave Anderson [mailto:anderson@redhat.com]
Sent: Tuesday, March 05, 2013 5:47 PM
To: Ku, Eugene
Cc: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] SLES 9 Dump
----- Original Message -----
> Dave,
>
> On both RHEL 5.2 X64 and RHEL 5.5 X64, it showed: (Additional
> argument such as System.map does not make any difference.)
>
> # crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504
> ...
> WARNING: machine type mismatch:
> crash utility: X86_64
> vmlinux-2.6.5-7.321-bigsmp: X86
>
> crash: vmlinux-2.6.5-7.321-bigsmp: not a supported file format
Right, as the message states, you're trying to analyze a 32-bit
x86 vmlinux/vmcore with the x86_64 version of the crash utility.
So just get the 32-bit x86 crash utility. If you can't find
one, then you can try building one on your x86_64 host:
$ wget http://people.redhat.com/anderson/crash-6.1.4.tar.gz
...
$ cd crash-6.1.4
$ make target=X86
...
$ ./crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504
If the build fails, you can wget the crash-6.1.4-0.src.rpm
file from the same location, and the rpmbuild -ba will alert
you to the additional packages you need.
Dave
>
>
>
>
> On an RHEL 4.7 X86, it showed:
>
> # crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504
> ...
> crash: vmlinux-2.6.5-7.321-bigsmp: no debugging data available
>
>
> # crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504
> System.map-2.6.5-7.321-bigsmp
> ...
> crash: vmlinux-2.6.5-7.321-bigsmp: no debugging data available
>
>
> # crash vmlinux-2.6.5-7.321-bigsmp dump-pts02504
> Kerntypes-2.6.5-7.321-bigsmp
> ...
> crash: cannot resolve "_stext"
>
>
> Thanks.
>
> Eugene
>
>
> -----Original Message-----
> From: Dave Anderson [mailto:anderson@redhat.com]
> Sent: Tuesday, March 05, 2013 5:22 PM
> To: Ku, Eugene
> Cc: Discussion list for crash utility usage, maintenance and
> development
> Subject: Re: [Crash-utility] SLES 9 Dump
>
>
>
> ----- Original Message -----
> > Dave,
> >
> > Thank you for getting back to me so quickly.
> >
> > I have tried different ways to start crash but none is working. I
> > have downloaded kernel-bigsmp-2.6.5-7.321.i586.rpm from Novell to
> > match the version of the dump. This package includes the following
> > files:
> >
> > config-2.6.5-7.321-bigsmp System.map-2.6.5-7.321-bigsmp
> > Kerntypes-2.6.5-7.321-bigsmp vmlinux-2.6.5-7.321-bigsmp
> > symtypes-2.6.5-7.321-bigsmp vmlinuz-2.6.5-7.321-bigsmp
> > symvers-2.6.5-7.321-i386-bigsmp
> >
> > I don't believe Novell provides a kernel-debuginfo package for SLES
> > 9
> > or earlier version and I could not find it on their web site.
> >
> > What I have tried so far are all done on RHEL systems because SLES
> > 9
> > does not come with crash. Do I need to run crash against an SLES
> > dump on a compatible SLES system? A compatible system I mean the
> > same architecture. When I tried it on RHEL X64, it complained
> > machine type mismatch.
>
> What is the mismatch error message?
>
> Dave
>
11 years, 8 months
