[Crash-utility] crash 4.0-2.8 fails on 2.6.14-rc5 (EM64T)
Dave Anderson
anderson at redhat.com
Thu Oct 27 18:36:25 UTC 2005
Badari Pulavarty wrote:
> Okay, I did a crude fix and "crash" now works fine :)
>
Well - not so fast! I wouldn't call it "just fine" just yet! ;-)
See below...
>
> It looks like, we need to teach crash/gdb about
>
> ffff81010bca1100
>
> kind of address for x86-64.
>
> Here is the hack, I did in memory.c:
>
> readmem(ulonglong addr, int memtype, void *buffer, long size,
> char *type, ulong error_handle)
> {
> ....
>
> case KVADDR:
> if (LKCD_DUMPFILE())
> addr = fix_lkcd_address(addr);
>
> if (!((addr & 0xffffffff00000000) ==
> 0xffffffff00000000)) {
> addr = addr & 0x00000fffffffffff;
> }
> if (!IS_KVADDR(addr)) {
> if (PRINT_ERROR_MESSAGE)
> error(INFO, INVALID_KVADDR, addr, type);
> goto readmem_error;
> }
> break;
>
> }
>
> Crash output:
> =============
>
> elm3a242:~/crash-4.0-2.8 # ./crash
>
> crash 4.0-2.8
> Copyright (C) 2002, 2003, 2004, 2005 Red Hat, Inc.
> Copyright (C) 2004, 2005 IBM Corporation
> Copyright (C) 1999-2005 Hewlett-Packard Co
> 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 "x86_64-unknown-linux-gnu"...
>
> WARNING: cannot access vmalloc'd module memory
That's not so good -- again, see below...
>
>
> KERNEL: /usr/src/linux-2.6.14-rc5/vmlinux
> DUMPFILE: /dev/mem
> CPUS: 2
> DATE: Thu Oct 27 06:02:01 2005
> UPTIME: 00:04:53
> LOAD AVERAGE: 0.18, 0.08, 0.07
> TASKS: 60
> NODENAME: elm3a242
> RELEASE: 2.6.14-rc5
> VERSION: #1 SMP PREEMPT Thu Oct 27 05:27:10 PDT 2005
> MACHINE: x86_64 (3000 Mhz)
> MEMORY: 4.6 GB
> PID: 11678
> COMMAND: "crash"
> TASK: ffff810124263760 [THREAD_INFO: ffff81010b584000]
> CPU: 1
> STATE: TASK_RUNNING (ACTIVE)
>
> crash> ps
> PID PPID CPU TASK ST %MEM VSZ RSS COMM
> 0 0 0 ffffffff8050ba80 RU 0.0 0 0 [swapper]
> 0 1 1 ffff810037ea4080 RU 0.0 0 0 [swapper]
> 1 0 1 ffff810037e974e0 IN 0.0 716 312 init
> 2 1 0 ffff810037e96e00 IN 0.0 0 0
> [migration/0]
> 3 1 0 ffff810037e96720 IN 0.0 0 0
> [ksoftirqd/0]
> 4 1 0 ffff810037e96040 IN 0.0 0 0
> [watchdog/0]
> 5 1 1 ffff810037ea5520 IN 0.0 0 0
> [migration/1]
> 6 1 1 ffff810037ea4e40 IN 0.0 0 0
> [ksoftirqd/1]
> 7 1 1 ffff810037ea4760 IN 0.0 0 0
> [watchdog/1]
> 8 1 0 ffff8100d7e1b560 IN 0.0 0 0
> [events/0]
> 9 1 1 ffff8100d7e1ae80 IN 0.0 0 0
> [events/1]
> 10 1 0 ffff8100d7e1a7a0 IN 0.0 0 0 [khelper]
> 11 1 0 ffff8100d7e1a0c0 IN 0.0 0 0 [kthread]
> 15 11 0 ffff8100d7e495a0 IN 0.0 0 0
> [kblockd/0]
> 16 11 1 ffff8100d7e48ec0 IN 0.0 0 0
> [kblockd/1]
> 19 11 0 ffff8100d7e487e0 IN 0.0 0 0 [khubd]
> 122 11 0 ffff8100d7e48100 IN 0.0 0 0 [pdflush]
> 123 11 1 ffff8100d7dff5e0 IN 0.0 0 0 [pdflush]
> 124 1 1 ffff810037c05620 IN 0.0 0 0 [kswapd0]
> 125 11 0 ffff8100d7dfef00 IN 0.0 0 0 [aio/0]
> 126 11 1 ffff8100d7dfe820 IN 0.0 0 0 [aio/1]
> 200 11 0 ffff8100d7dfe140 IN 0.0 0 0 [kseriod]
> 259 11 0 ffff810037c91660 IN 0.0 0 0
> [scsi_eh_0]
> 292 11 0 ffff810037c901c0 IN 0.0 0 0
> [scsi_eh_1]
> 570 1 1 ffff810127751760 IN 0.0 0 0
> [kjournald]
> 1177 1 1 ffff810037c04f40 IN 0.0 2532 464
> irqbalance
> 2274 1 0 ffff810122ff38a0 IN 0.0 3608 760 syslogd
> 2316 1 0 ffff810122ca49a0 IN 0.0 2664 736 klogd
> 2361 1 0 ffff81012529a380 IN 0.0 3584 388 resmgrd
> 2363 1 0 ffff810122875860 IN 0.0 4620 500 portmap
> 2403 1 0 ffff8101232cd6a0 IN 0.0 12700 1328 slpd
> 2505 1 1 ffff810123a2c100 IN 0.1 24152 6636 cupsd
> 2601 1 0 ffff810122ff31c0 IN 0.0 26824 1788 sshd
> 2615 1 1 ffff810122ca77e0 IN 0.1 71188 4240 slapd
> 2622 1 0 ffff810122ca6a20 IN 0.1 71188 4240 slapd
> 2825 1 0 ffff810120c5d8e0 IN 0.1 71188 4240 slapd
> 3113 1 0 ffff810124d98e00 IN 0.0 2544 600 hwscand
> 4120 1 0 ffff810123c68a20 IN 0.0 20080 2344 master
> 4196 4120 0 ffff81011d9c07a0 IN 0.0 20140 2296 pickup
> 4197 4120 0 ffff81011d9c00c0 IN 0.0 20188 2348 qmgr
> 9513 1 1 ffff8101099a77a0 IN 0.0 48912 912 nscd
> 9514 1 1 ffff8101099a69e0 IN 0.0 48912 912 nscd
> 9515 1 1 ffff8101099a6300 IN 0.0 48912 912 nscd
> 9516 1 0 ffff8101095777e0 IN 0.0 48912 912 nscd
> 9517 1 0 ffff810109577100 IN 0.0 48912 912 nscd
> 9518 1 0 ffff810109576a20 IN 0.0 48912 912 nscd
> 9525 1 1 ffff81010a49e440 IN 0.0 2544 632 cron
> 10329 1 0 ffff810109dfa920 IN 0.0 8984 768 kdm
> 10347 10329 1 ffff81010ab11860 IN 0.6 40656 27528 X
> 10348 10329 0 ffff81010af477a0 ?? 0.0 12200 1356 kdm
> 10388 1 0 ffff81012762e9e0 IN 0.0 2760 724 mingetty
> 10389 1 0 ffff8101242622c0 IN 0.0 2756 708 mingetty
> 10390 1 0 ffff81010cabce40 IN 0.0 2756 716 mingetty
> 10392 1 0 ffff81010c2bb0c0 IN 0.0 2760 724 mingetty
> 10393 1 1 ffff81011fd176e0 IN 0.0 2756 708 mingetty
> 10394 1 1 ffff81010bca1100 IN 0.0 2760 724 mingetty
> 10967 10348 1 ffff81011edee760 IN 0.4 69108 18472 kdm_greet
> 10979 2601 0 ffff8101099a70c0 IN 0.1 40268 3028 sshd
> 10981 10979 0 ffff81010ab103c0 IN 0.1 8432 2864 bash
> > 11678 10981 1 ffff810124263760 RU 3.0 86304 147740 crash
> > 11690 11678 0 ffff81010c2ba9e0 RU 0.0 0 0 crash
> crash>
Ok -- so there has been a wholesale change in the virtual address
space ranges used. In 2.6.9 (and 2.4 as well), you see:
crash> mach
MACHINE TYPE: x86_64
MEMORY SIZE: 1 GB
CPUS: 4
PROCESSOR SPEED: 2793 Mhz
HZ: 1000
PAGE SIZE: 4096
L1 CACHE SIZE: 64
KERNEL VIRTUAL BASE: 10000000000
KERNEL VMALLOC BASE: ffffff0000000000
KERNEL START MAP: ffffffff80000000
KERNEL MODULES BASE: ffffffffa0000000
KERNEL STACK SIZE: 8192
crash>
...and there's no unity mapping for anything in the "new" range
like those seen above for the task addresses (ffff81...). And
the fact that you can't access modules also implies that something
there has changed as well.
The values for all of the above are pretty much hard-coded,
and now need to be dynamically determined. Note crash's "defs.h"
has these values in place, which have been the case for 2.4
and 2.6 kernels -- well, at least until 2.6.10:
#ifdef X86_64
#define _64BIT_
#define MACHINE_TYPE "X86_64"
#define USERSPACE_TOP 0x0000008000000000
#define __START_KERNEL_map 0xffffffff80000000
#define PAGE_OFFSET 0x0000010000000000
#define VMALLOC_START 0xffffff0000000000
#define VMALLOC_END 0xffffff7fffffffff
#define MODULES_VADDR 0xffffffffa0000000
#define MODULES_END 0xffffffffafffffff
#define MODULES_LEN (MODULES_END - MODULES_VADDR)
So I believe the place to start would be to make these
values into x86_64-specific variables that get initialized
early on based upon the symbol values gathered during
symtab_init(), which is called by main(). After it
completes, machdep_init(PRE_GDB) is called, i.e. x86_64_init():
/*
* Initialize various subsystems.
*/
fd_init();
buf_init();
cmdline_init();
mem_init();
machdep_init(PRE_SYMTAB);
symtab_init();
machdep_init(PRE_GDB);
kernel_init(PRE_GDB);
verify_version();
datatype_init();
In x86_64_init(PRE_GDB), the former hardwired #defines would need
to be variables, initialized properly based upon clues in the symbol
list.
Interested in taking a look into this?
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20051027/eb6551b4/attachment.htm>
More information about the Crash-utility
mailing list