Re: [Crash-utility] Miscellaneous fixes/enhancements to crash 4.0-2.10
by Dave Anderson
There were a couple things in this patch set which I did not
accept, or changed a bit. One minor, one major...
One thing was this proposed patch to x86.c:
--- crash-4.0-2.10/x86.c 2005-11-07 07:44:06 -08:00
+++ crash-4.0-2.10-new/x86.c 2005-11-07 18:57:19 -08:00
@@ -683,8 +683,7 @@
if ((machdep->flags & OMIT_FRAME_PTR) ||
bt->debug ||
- (bt->flags & BT_FRAMESIZE_DEBUG) ||
- !(bt->flags & BT_OLD_BACK_TRACE)) {
+ (bt->flags & BT_FRAMESIZE_DEBUG)) {
lkcd_x86_back_trace(bt, 0, fp);
return;
}
Regardless whether the kernel was built with -fomit-frame-pointer
or not, the LKCD-derived backtrace code is used by default, unless
the "bt -o" flag is used. That fact was not advertised in the bt
help page, but it is now. However, the old backtrace code will never
be used if the kernel was build with the -fomit-frame-pointer flag,
because it simply fails miserably. So int that case, "bt -o" is
ignored.
However, in a case where the target kernel was built without the
-fomit-frame-pointer flag, and you'd like to use the "old" backtrace
code without having to enter the -o option every time, I have added
a "bt -O" option, which will toggle the backtrace behavior flag;
the first time that it's entered, all backtrace commands will use
the old backtrace code automatically; subsequent "bt -O" commands
will toggle it back and forth. Again, this feature is useless
and ignored if the kernel was built with -fomit-frame-pointer.
I also did not feel comfortable accepting the extension-keyword
stuff. While I do recognize that it would be useful to be
able to dynamically determine what extension modules to load,
I don't feel the extend command should be encumbered with the
job, but rather such an implementation-specific chore should
be handled by an instance of extension library code.
For that reason I exported both the load_extension() and
unload_extension() functions so that extension library code
could use them to in turn load other extension libraries.
The call to load_extension() could be made from either the
_init() function or from an extension command. At those
points in time, the "first" extension library will have all
the information (kernel version, crash version, dumpfile,
etc.) at its disposal, and then can make the decision as to
what additional libraries to load.
The first extension library can either be left in place,
or, if all of the load_extension() calls are made during its
_init() function -- and its register_function() neglected --
that first library will be immediately unloaded. For example,
the default _init() function looks like this:
_init() /* Register the command set. */
{
register_extension(command_table);
}
It could be changed to do this:
_init() /* Don't register a command set -- load other extensions... */
{
/* figure out what extensions to load here */
go_figure();
/* and then load them... */
load_extension("this.so");
load_extension("that.so");
}
Since the "extend" of the initial library above is being
done with doing a register_extension(), then crash will
immediately unload it. So one "extend" command can lead
to a chain of library loads.
Alternatively, the command within the initial extension
library can be called, and based upon what is passed
into to it, it can load further libraries.
Dave
18 years, 10 months
NEC's dminfo extension
by Dave Anderson
This is the help page for the new dminfo extension:
-------------------------------------------------------------------
NAME
dminfo - device mapper (dm) information
SYNOPSIS
dminfo [-b bio | -d | -l | -q | -s | -t]
DESCRIPTION
This command displays information about device-mapper mapped
devices (dm devices).
If no argument is entered, displays lists of existing dm devices.
It's same as -l option.
-b bio displays the information of the dm device which the bio
is submitted in. If the bio isn't for dm devices,
results will be error.
-d displays dependency information for existing dm devices.
-l displays lists of existing dm devices.
-q displays queued I/O information for each target of
existing dm devices.
-s displays status information for each target of existing
dm devices.
-t displays table information for each target of existing
dm devices.
EXAMPLE
Display lists of dm devices. "MAP_DEV" is the address of the
struct mapped_device. "DM_TABLE" is the address of the struct
dm_table. "TARGETS" is the number of targets which are in
the struct dm_table.
crash> dminfo
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 8 c4866c80 c4866280 1 vg0-snap0
253 6 f6a04a80 f6a04580 1 vg0-lv0-real
253 0 c4840380 c4841880 1 mp0
253 5 f7c50c80 c488e480 1 via_cbeheddbdd
253 7 c4866a80 c4866380 1 vg0-snap0-cow
253 4 d441e280 c919ed80 1 dummy1
253 3 f5dc4280 cba81d80 1 dummy0
253 2 f7c53180 c4866180 1 vg0-lv0
253 1 f746d280 f746cd80 1 mp0p1
Display the dm device information which the bio is submitted in.
The bio (ceacee80) is a clone of the bio (ceacee00) which is
submitted in the dm-3 (dummy0). And the bio (ceacee00) is a clone
of the bio (ceaced80) which is submitted in the dm-4 (dummy1), too.
The bio (ceaced80) is the original bio.
crash> dminfo -b ceacee80
DM_BIO_ADDRESS MAJ MIN MAP_DEV DEVNAME
ceacee00 253 3 f5dc4280 dm-3
crash> dminfo -b ceacee00
DM_BIO_ADDRESS MAJ MIN MAP_DEV DEVNAME
ceaced80 253 4 d441e280 dm-4
crash> dminfo -b ceaced80
dminfo: invalid kernel virtual address: 64 type: "GET_VALUE: dm_io.bio"
Display dependency information for each target.
The vg0-snap0 depends on thd dm-6 (vg0-lv0-real) and the dm-7
(vg0-snap0-cow)
crash> dminfo -d
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 8 c4866c80 c4866280 1 vg0-snap0
MAJ MIN GENDISK COUNT DEVNAME
253 7 c4866980 1 dm-7
253 6 f6a04280 1 dm-6
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 6 f6a04a80 f6a04580 1 vg0-lv0-real
MAJ MIN GENDISK COUNT DEVNAME
8 0 f7f24c80 1 sda
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 7 c4866a80 c4866380 1 vg0-snap0-cow
MAJ MIN GENDISK COUNT DEVNAME
8 0 f7f24c80 1 sda
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 2 f7c53180 c4866180 1 vg0-lv0
MAJ MIN GENDISK COUNT DEVNAME
253 6 f6a04280 1 dm-6
Display queued I/O information for each target.
The information is displayed under the "PRIVATE_DATA" column.
crash> dminfo -q
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 5 f7c50c80 c488e480 1 via_cbeheddbdd
TARGET TARGET_TYPE PRIVATE_DATA
f8961080 mirror (reads) (writes) (quiesced) (recovered)
--------------------------------------------------------------
"reads/writes" are members of the struct mirror_set, and
"quiesced/recovered" are members of the struct region_hash.
If the list is empty, the member is bracketed by "()".
--------------------------------------------------------------
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 0 c4840380 c4841880 1 mp0
TARGET TARGET_TYPE PRIVATE_DATA
f8802080 multipath queue_size:0
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 1 f746d280 f746cd80 1 mp0p1
TARGET TARGET_TYPE PRIVATE_DATA
f8821080 linear No queue info
Display status information for each target.
The information is displayed under the "PRIVATE_DATA" column.
crash> dminfo -s
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 0 c4840380 c4841880 1 mp0
TARGET TARGET_TYPE PRIVATE_DATA
f8802080 multipath queue_if_no_path:0 hwh:none nr_pgs:1
PG PG_STATUS NR_PATHS PATHS
1 active 2 8:16(A,0) 8:32(A,0)
--------------------------------------------------------------
Format of "PATHS": <major>:<minor>(<status>,<fail_count>)
Status: A:active, F:faulty
Fail_count: the value of the struct pgpath.fail_count
--------------------------------------------------------------
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 5 f7c50c80 c488e480 1 via_cbeheddbdd
TARGET TARGET_TYPE PRIVATE_DATA
f8961080 mirror in_sync:1 dev:8:16(A,0),8:32(A,0)
--------------------------------------------------------------
Format of "dev": <major>:<minor>(<status>,<error_count>)
Status: A:active, D:degraded
Error_count: the value of the struct mirror.error_count
--------------------------------------------------------------
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 1 f746d280 f746cd80 1 mp0p1
TARGET TARGET_TYPE PRIVATE_DATA
f8821080 linear No status info
Display table information for each target.
The information is displayed under the "PRIVATE_DATA" column.
crash> dminfo -t
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 8 c4866c80 c4866280 1 vg0-snap0
TARGET TARGET_TYPE PRIVATE_DATA
f89b4080 snapshot orig:253:6 cow:253:7 type:P chunk_size:16
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 6 f6a04a80 f6a04580 1 vg0-lv0-real
TARGET TARGET_TYPE PRIVATE_DATA
f890f080 linear begin:0 len:204800 dev:8:5 offset:384
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 0 c4840380 c4841880 1 mp0
TARGET TARGET_TYPE PRIVATE_DATA
f8802080 multipath queue_if_no_path:0 hwh:none nr_pgs:1
PG PATH_SELECTOR NR_PATHS PATHS
1 round-robin 2 8:16 8:32
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 5 f7c50c80 c488e480 1 via_cbeheddbdd
TARGET TARGET_TYPE PRIVATE_DATA
f8961080 mirror log:core dev:8:16(0),8:32(0)
--------------------------------------------------------------
Format of "dev": <major>:<minor>(<offset>)
Offset: the value of the struct mirror.offset
--------------------------------------------------------------
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 7 c4866a80 c4866380 1 vg0-snap0-cow
TARGET TARGET_TYPE PRIVATE_DATA
f899d080 linear begin:0 len:8192 dev:8:5 offset:205184
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 2 f7c53180 c4866180 1 vg0-lv0
TARGET TARGET_TYPE PRIVATE_DATA
f8bbc080 snapshot-origin orig_dev:253:6
MAJ MIN MAP_DEV DM_TABLE TARGETS MAPNAME
253 1 f746d280 f746cd80 1 mp0p1
TARGET TARGET_TYPE PRIVATE_DATA
f8821080 linear begin:0 len:2040192 dev:253:0 offset:63
18 years, 10 months
Re: [Crash-utility] crash and the "hugemem" kernel
by Dave Anderson
"Kurtis D. Rader" wrote:
> Should crash be able to read a RHEL 3 hugemem dump? I've got a x86 14 GiB
> netdump vmcore taken under controlled conditions (e.g., system was booted
> and a crash dump manually invoked) that the crash(1) command doesn't like:
>
> vmcore: initialization failed
>
>
Hi Kurt,
As it turns out, this is most definitely due to the new kdump support.
I ran into it by mistake, and only when inadvertently including another
argument in addition to the vmcore and vmlinux arguments on the crash
command line. Perhaps you were using a System.map file, or maybe a
vmlinux file and a vmlinux.debug file on the command line? Anyway,
it has to do with is_kdump() passing its work on to is_netdump(),
which failed on the extra argument and erroneously cleared the valid
bit. (With just vmlinux and vmcore file arguments, it works OK.)
In any case, I'll have a fix for it in the next release, which I'm
hoping to do today.
Thanks,
Dave
18 years, 10 months
Miscellaneous fixes/enhancements to crash 4.0-2.10
by Castor Fu
Hi guys:
We're trying to bring in a newer version of crash, and have
some changes which we've made since going to version 4.0-2.10
which I'll outline below, and have attached a patch:
1. Makefile, help.c, extensions.c, new file kw.c
Add a keyword expansion mechanism to the 'extend' command.
We did this primarily to let us load different extensions
based on the dump file itself or the version of crash.
+"\n The named <shared-object> is subjected to a simple keyword expansion",
+" scheme with the following rules:",
+" $(crash_version) version of crash",
+" $(corestr-<varname>) string named <varname> taken from the core file",
+" $(builddir) build directory for the kernel",
2. defs.h
Provide nominal recognition of the LKCD V10 dump format which does
not appear to have changed much.
3. kernel.c
Make compile under gcc 2.x compilers
Provide additional information with bad stack addresses.
4. lkcd_common.c
Handle single-bit errors in LKCD compressed pages by trying out
all possible single-bit errors.
5. lkcd_v7.c
If dh_memory_end is set in the dump header, use that to determine the
index file size. (Note that this is not initialized in the main-line
LKCD code yet...)
6. task.c
Be more defensive about the value of tc->processor
Also, try to set the panic string correctly in when decoding dump.
7. x86.c
Be a little more liberal deciding that the frame pointer has been included.
gcc 3.x can re-schedule code so that instead of
push bp
mov esp, bp
we sometimes see
push bp
xor eax,eax
move esp, bp
so detect both sequences.
If y'all could consider this for inclusion I would appreciate it.
-castor
--
18 years, 10 months
gcc 2.96 diskdump.c compile failure
by Dave Anderson
Castor's patch fixed a 2.x gcc compiler failure here because
of the inadvertant double semi-colon:
@@ -52,7 +52,7 @@
kernel_init(int when)
{
int i;
- char *p1, *p2, buf[BUFSIZE];;
+ char *p1, *p2, buf[BUFSIZE];
struct syment *sp1, *sp2;
...which I wasn't aware of, since I haven't been testing builds with
that era compiler for a some time now. But in doing so, I see that
gcc 2.96 won't compile diskdump.c either:
cc -c -g -DX86 -D_FILE_OFFSET_BITS=64 diskdump.c
In file included from diskdump.c:24:
diskdump.h:49: array size missing in `tasks'
make[3]: *** [diskdump.o] Error 1
because of the tasks member at the end of this struct:
struct disk_dump_header {
char signature[SIG_LEN]; /* = "DISKDUMP" */
int header_version; /* Dump header version */
struct new_utsname utsname; /* copy of system_utsname */
struct timeval timestamp; /* Time stamp */
unsigned int status; /* Above flags */
int block_size; /* Size of a block in byte */
int sub_hdr_size; /* Size of arch dependent
header in blocks */
unsigned int bitmap_blocks; /* Size of Memory bitmap in
block */
unsigned int max_mapnr; /* = max_mapnr */
unsigned int total_ram_blocks;/* Number of blocks should be
written */
unsigned int device_blocks; /* Number of total blocks in
* the dump device */
unsigned int written_blocks; /* Number of written blocks */
unsigned int current_cpu; /* CPU# which handles dump */
int nr_cpus; /* Number of CPUs */
struct task_struct *tasks[];
};
Can this be changed to: struct task_struct **tasks;
and get away with it?
Dave
18 years, 10 months
crash-4.0-2.10 ppc64 4-level pagetable fixes
by Badari Pulavarty
Hi Dave,
Here are the fixes to make crash understand PPC64 4-level pagetable
layout.
I am not a PPC64 expert, I coded up looking at the ppc64 kernel
pagetable handling code. It seems to work fine for most part.
But I do get occasional, "user virtual" translation failures.
I think I screwed up PMD calculations. I am not able to spot
the problem. Can some one help ?
Thanks,
Badari
elm3b157:~/crash-4.0-2.10.new # ./crash
crash 4.0-2.10
Copyright (C) 2002, 2003, 2004, 2005 Red Hat, Inc.
Copyright (C) 2004, 2005 IBM Corporation
Copyright (C) 1999-2005 Hewlett-Packard Co
Copyright (C) 2005 Fujitsu Limited
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002 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 "powerpc64-unknown-linux-gnu"...
KERNEL: /usr/src/linux-2.6.14/vmlinux
DUMPFILE: /dev/mem
CPUS: 4
DATE: Tue Nov 8 11:02:01 2005
UPTIME: 06:41:51
LOAD AVERAGE: 0.08, 0.03, 0.06
TASKS: 103
NODENAME: elm3b157
RELEASE: 2.6.14
VERSION: #1 SMP Thu Nov 3 13:22:57 PST 2005
MACHINE: ppc64 (1655 Mhz)
MEMORY: 3.7 GB
PID: 32605
COMMAND: "crash"
TASK: c0000000e304e040 [THREAD_INFO: c0000000934c8000]
CPU: 0
STATE: TASK_RUNNING (ACTIVE)
crash> set
PID: 32605
COMMAND: "crash"
TASK: c0000000e304e040 [THREAD_INFO: c0000000934c8000]
CPU: 1
STATE: TASK_RUNNING (ACTIVE)
crash> vm
PID: 32605 TASK: c0000000e304e040 CPU: 1 COMMAND: "crash"
MM PGD RSS TOTAL_VM
c0000000dc048080 c000000093e2f000 137464k 76800k
VMA START END FLAGS FILE
c0000000e3c16ee8 100000 103000 75
c0000000d7b92ee8 10000000 10590000
1875 /root/crash-4.0-2.10.new/crash
c0000000d7b92870 1059f000 1069a000
101873 /root/crash-4.0-2.10.new/crash
c0000000d7b92420 1069a000 11858000 100073
c0000000e3979cc0 40000000000 4000001d000
875 /lib64/ld-2.3.3.so
c0000000e23f57b8 4000001d000 40000022000 100073
c0000000e23f5700 4000002d000 40000030000
100873 /lib64/ld-2.3.3.so
c0000000ebf55648 40000048000 400000ba000
75 /lib64/tls/libm.so.6
c0000000e3c162b0 400000ba000 400000c8000
70 /lib64/tls/libm.so.6
c0000000ebf554d8 400000c8000 400000cf000
100073 /lib64/tls/libm.so.6
c0000000ebf55368 400000cf000 40000130000
75 /lib64/libncurses.so.5.4
c0000000ebf55d78 40000130000 4000013f000
70 /lib64/libncurses.so.5.4
c0000000ebf55a98 4000013f000 40000156000
100073 /lib64/libncurses.so.5.4
c0000000ebf55420 40000156000 40000159000 100073
c0000000ebf552b0 40000159000 4000015d000
75 /lib64/libdl.so.2
c0000000ebf55e30 4000015d000 40000169000
70 /lib64/libdl.so.2
c0000000ebf55870 40000169000 4000016d000
100073 /lib64/libdl.so.2
c0000000e3979d78 4000016d000 40000184000
75 /lib64/libz.so.1.2.1
c0000000ebf55590 40000184000 4000018d000
70 /lib64/libz.so.1.2.1
c0000000e39791f8 4000018d000 40000194000
100073 /lib64/libz.so.1.2.1
c0000000ebf557b8 40000194000 40000195000 100073
c0000000e3979590 40000195000 400002d6000
75 /lib64/tls/libc.so.6
c0000000e39797b8 400002d6000 400002e5000
70 /lib64/tls/libc.so.6
c0000000e23f5870 400002e5000 40000303000
100073 /lib64/tls/libc.so.6
c0000000e3979c08 40000303000 40000307000 100073
c0000000e1308e30 40000307000 4000033a000
71 /usr/lib/locale/en_US.utf8/LC_CTYPE
c0000000d7b92700 4000033a000 4000035a000 100073
c0000000eb825b50 4000035a000 40000361000
75 /lib64/tls/libthread_db.so.1
c0000000eb825368 40000361000 4000036a000
70 /lib64/tls/libthread_db.so.1
c0000000eb825870 4000036a000 40000372000
100073 /lib64/tls/libthread_db.so.1
crash> rd -u 100000
100000: 7f454c4602020100 .ELF....
crash> rd -u 40000169000
rd: invalid user virtual address: 40000169000 type: "64-bit UVADDR"
18 years, 10 months
crash version 4.0-2.10 is available
by Dave Anderson
Adapted a patch set created by Badari Pulavarty of IBM, that
addresses a fatal initialization-time crash error that indicated
"crash: invalid structure member offset: x8664_pda_level4_pgt"
when run against post-2.6.10 x86_64 kernels. But more importantly,
Badari's patch adds support for these x86_64 kernel changes that
were introduced in 2.6.11:
- x86_64 kernel virtual address range changes, and
- x86_64 user virtual address space usage of 4-level page tables
18 years, 10 months
Re: [Crash-utility] [PATCH} crash 4.0-2.8 fixes to make it workonx86_64 for 2.6.14
by Dave Anderson
> crash> rd -u 0x400000
> rd: invalid user virtual address: 400000 type: "64-bit UVADDR"
Ah, damn it -- it would also be printed later on in
readmem() if uvtop() fails:
while (size > 0) {
switch (memtype)
{
case UVADDR:
if (!uvtop(CURRENT_CONTEXT(), addr, &paddr, 0)) {
if (PRINT_ERROR_MESSAGE)
error(INFO, INVALID_UVADDR, addr, type);
goto readmem_error;
}
break;
That's probably where it's happening...
I would guess that x86_64_uvtop() needs to immediately
recognize if the new VM scheme is in place, and if so
it should veer off to a new "x86_64_uvtop_lev4()" routine.
We definitely want to keep the current one untouched, while
the new one must need a 4th layer of page table translation.
Note that x86_64_kvtop() has the extra FILL_PML4() stuff
before the 3-level breakdown -- I guess that's why vmalloc
addresses still translate. But there must be another layer
user virtual addresses need to go through.
Dave
18 years, 10 months
crash version 4.0-2.9 is available
by Dave Anderson
Adapted a patch set from NEC and Fujitsu that introduces support
for an alternative compressed dumpfile format created by the
diskdump facility. When the diskdump facility is configured to
use compression, the dumpfile will not be an ELF vmcore file,
but rather a compressed dumpfile image, derived from the LKCD
dumpfile format.
(11/03/05)
18 years, 11 months
Re: [Crash-utility] [PATCH} crash 4.0-2.8 fixes to make it work onx86_64 for 2.6.14
by Dave Anderson
> So, the key will be to find a difference between 2.6.10 and
> 2.6.11's symbol contents.
Hi Badari,
Looking at what appears to be Andi's wholesale patch set that
made the VM changes, I think it may be possible to use
"boot_vmalloc_pgt" as a qualifier, because it went away with
the new scheme. Also, "vmalloc_fault" was added, but since
it's a static function, its only caller may have inlined it
in the new kernel.
Also, given the VM changes, I'm still amazed that the virtual
to physical translation of vmalloc and user page addresses
still works. Are you sure that "vtop" on vmalloc and user
space addresses works correctly?
To verify user-space address translation is working, you
should be able to do something like this. Run crash in a
live session, and look at the very beginning of its address
space, and read the first few bytes:
crash> set
PID: 8052
COMMAND: "crash"
TASK: 10018e1f7f0 [THREAD_INFO: 100189e4000]
CPU: 3
STATE: TASK_RUNNING (ACTIVE)
crash> vm
PID: 8052 TASK: 10018e1f7f0 CPU: 3 COMMAND: "crash"
MM PGD RSS TOTAL_VM
1002fc08040 10018286000 63376k 121176k
VMA START END FLAGS FILE
1002b8269f8 400000 788000 1875 /usr/bin/crash
1002bb5d3c8 888000 8ab000 101873 /usr/bin/crash
100288d9408 8ab000 8f8000 100077
100302a0688 9aa000 9c2000 101873 /usr/bin/crash
10028f49b98 9c2000 1b50000 100077
10028f49358 2a95556000 2a95558000 100073
1002edad688 2a95584000 2a95587000 100073
...
crash> rd -u 0x400000
400000: 00010102464c457f .ELF....
crash>
You should see the first bytes of the executable's ELF header,
as verified by the "ELF" string there.
To verify module virtual addresses translation, try disassembling
a module text address, say some ext3 function, and verifying that
it makes sense?
Thanks,
Dave
18 years, 11 months