Dear ,The place is at value_search in symbols.c line 4252,I must apologize for my careless.*
2012/7/5 <crash-utility-request@redhat.com>
Send Crash-utility mailing list submissions to
* * * * crash-utility@redhat.com
To subscribe or unsubscribe via the World Wide Web, visit
* * * * https://www.redhat.com/mailman/listinfo/crash-utility
or, via email, send a message with subject or body 'help' to
* * * * crash-utility-request@redhat.com
You can reach the person managing the list at
* * * * crash-utility-owner@redhat.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Crash-utility digest..."
Today's Topics:
* *1. crash read symbols bug (chenbo lee)
* *2. ptov command (Karlsson, Jan)
* *3. Re: ptov command (Dave Anderson)
* *4. Re: crash seek error, * * kernel_config_data and
* * * cpu_possible_mask (Dave Anderson)
----------------------------------------------------------------------
Message: 1
Date: Thu, 5 Jul 2012 15:37:41 +0800
From: chenbo lee <lee.chenbo@gmail.com>
To: crash-utility@redhat.com
Subject: [Crash-utility] crash read symbols bug
Message-ID:
* * * * <CAFvkxTjC7JJrs4RVCPMc81sVx=VepqUaNov9pi3Mx1DQzE9K QA@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
>
>
> Dear ,
* * *I ported crash tool to Loongson platform which is a Mips-like CPU
developed by Institute of Computing Technology,Chinese Academic of science.
* * *In my work process,I found a bug in crash when run on Loongson
platform.but the bug doesn't happen in x86 platform. Funcation name
is value_search_base_kernel in symbols.c ,line 4302,version
is crash-6.0.8. code segments as follow:
* * * *for ( ; sp < st->symend; sp++) {
* * * * * * * * if (value == sp->value) {
* * * * * * * * * * * * if (offset)
* * * * * * * * * * * * * * * * *offset = 0;
* * * * * * * * * * * * return((struct syment *)sp);
* * * * * * * * }
* * * * * * * * if (sp->value > value) {
* * * * * * * * * * * * if (offset)
* * * * * * * * * * * * * * * * *offset = value - ((sp-1)->value);
* * * * * * * * * * * * return((struct syment *)(sp-1));
* * * * * * * * }
* * * * }
* * *sp-1 will be NULL if sp pointer the first element in symbol table, *so
(sp-1)->value will cause segment fault.
* * *So I modify the code segment as follow:
* * * * * * * * * * *if (sp->value > value) {
* * * * * * * * * * * * if (sp - st->symtable == 0) return NULL;
* * * * * * * * * * * * if (offset)
* * * * * * * * * * * * * * * * *offset = value - ((sp-1)->value);
* * * * * * * * * * * * *return((struct syment *)(sp-1));
* * * * * * * * * * * }
* * *Is that OK?
* * * I wish you all the best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/crash-utility/attachments/20120705/84260549/attachment.html>
------------------------------
Message: 2
Date: Thu, 5 Jul 2012 13:01:45 +0200
From: "Karlsson, Jan" <Jan.Karlsson@sonymobile.com>
To: "Discussion list for crash utility usage, * maintenance and
* * * * development" * *<crash-utility@redhat.com>
Subject: [Crash-utility] ptov command
Message-ID:
* * * * <6DFA1B20D858A14488A66D6EEDF26AA35D6D7D4A25@seldmb x03.corpusers.net>
Content-Type: text/plain; charset="us-ascii"
Hi Dave
I have a question about the ptov command. Ptov only handles kernel virtual addresses and their corresponding physical addresses. However if you give ptov a physical address that does not correspond to a kernel virtual address it still answers with an address. Users might get confused and do not know when to trust ptov, especially as the inverse command vtop always works.
So I would like to restrict ptov to give a result only when it is valid. The idea I have is that if ptov returns a valid virtual address then vtop on that address should give the same physical address back again. True??
cmd_ptov() in memory.c
* ....
* vaddr = PTOV(paddr);
* kvtop(0, vaddr, &paddr_tst, 0);
* if (paddr != paddr_tst) ... invalid vaddr, do not print it ...
Any comments?
Jan
Jan Karlsson
Senior Software Engineer
MIB
Sony Mobile Communications
Tel: +46703062174
sonymobile.com<http://sonymobile.com/>
[cid:image001.jpg@01CD5AAD.EB8A3DC0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/crash-utility/attachments/20120705/cc8774a6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2843 bytes
Desc: image001.jpg
URL: <https://www.redhat.com/archives/crash-utility/attachments/20120705/cc8774a6/attachment.jpg>
------------------------------
Message: 3
Date: Thu, 05 Jul 2012 09:47:57 -0400 (EDT)
From: Dave Anderson <anderson@redhat.com>
To: "Discussion list for crash utility usage, * maintenance and
* * * * development" <crash-utility@redhat.com>
Subject: Re: [Crash-utility] ptov command
Message-ID:
* * * * <0105f7e9-971b-4fcf-a69c-5d187cb3e73b@zmail15.collab.prod.int.phx2.redhat.c om>
Content-Type: text/plain; charset=utf-8
----- Original Message -----
>
> Hi Dave
>
> I have a question about the ptov command. Ptov only handles kernel
> virtual addresses and their corresponding physical addresses.
> However if you give ptov a physical address that does not correspond
> to a kernel virtual address it still answers with an address. Users
> might get confused and do not know when to trust ptov, especially as
> the inverse command vtop always works.
>
> So I would like to restrict ptov to give a result only when it is
> valid. The idea I have is that if ptov returns a valid virtual
> address then vtop on that address should give the same physical
> address back again. True??
>
> cmd_ptov() in memory.c
>
> ....
>
> vaddr = PTOV(paddr);
> kvtop(0, vaddr, &paddr_tst, 0);
> if (paddr != paddr_tst) ... invalid vaddr, do not print it ...
>
> Any comments?
>
> Jan
Sounds reasonable, at least for the 32-bit arches. *I don't think it's
necessary for any 64-bit arch. *And you'd also need to account for kvtop()
failing outright (and returning FALSE).
Dave
------------------------------
Message: 4
Date: Thu, 05 Jul 2012 10:06:59 -0400 (EDT)
From: Dave Anderson <anderson@redhat.com>
To: "Discussion list for crash utility usage, * maintenance and
* * * * development" <crash-utility@redhat.com>
Subject: Re: [Crash-utility] crash seek error, *kernel_config_data and
* * * * cpu_possible_mask
Message-ID:
* * * * <5e0f87a1-291e-46b1-9410-8bbce0293c89@zmail15.collab.prod.int.phx2.redhat.c om>
Content-Type: text/plain; charset=utf-8
----- Original Message -----
>
> Hi, I'm happy to ask developers for help , I'm really confused for my
> crash error.
>
> My computer room is running 60 nodes,OS: suse 11 sp1 x86_64
> Kernel:2.6.32.12-0.7-default Crash:crash-5.0.1-1.5.5
>
> recently , server often kernel crash, Kdump service dump the vmcore
> in /var/crash/happen-date/vmcore,
>
> I installed the kernel-debuginfo so that check out why crash ,but I
> got this:
>
>
>
> linux:~/bb # crash -d8 vmlinux-2.6.32.12-0.7-default vmlinux-2.6.32.12-0.7-default.debug vmcore
>
> crash 5.0.1
> Copyright (C) 2002-2010 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.
>
> compressed kdump: header->utsname.machine:
> diskdump_data:
> filename: (null)
> flags: 6 (KDUMP_CMPRS_LOCAL|ERROR_EXCLUDED)
> dfd: 3
> ofp: 0
> machine_type: 62 (EM_X86_64)
>
> header: ccdfe0
> signature: "KDUMP "
> header_version: 1
> utsname:
> sysname:
> nodename:
> release:
> version:
> machine:
> domainname:
> timestamp:
> tv_sec: 0
> tv_usec: 0
> status: 0 ()
> block_size: 4096
> sub_hdr_size: 1
> bitmap_blocks: 400
> max_mapnr: 6553600
> total_ram_blocks: 0
> device_blocks: 0
> written_blocks: 0
> current_cpu: 0
> nr_cpus: 1
> tasks[nr_cpus]: 0
>
> sub_header: 0 (n/a)
>
> sub_header_kdump: cceff0
> phys_base: 0
> dump_level: 0 (0x0)
>
> data_offset: 192000
> block_size: 4096
> block_shift: 12
> bitmap: 7fcca1e01010
> bitmap_len: 1638400
> dumpable_bitmap: 7fcca1002010
> byte: 0
> bit: 0
> compressed_page: ce3220
> curbufptr: 0
>
> page_cache_hdr[0]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cd3210
> pg_hit_count: 0
> page_cache_hdr[1]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cd4210
> pg_hit_count: 0
> page_cache_hdr[2]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cd5210
> pg_hit_count: 0
> page_cache_hdr[3]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cd6210
> pg_hit_count: 0
> page_cache_hdr[4]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cd7210
> pg_hit_count: 0
> page_cache_hdr[5]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cd8210
> pg_hit_count: 0
> page_cache_hdr[6]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cd9210
> pg_hit_count: 0
> page_cache_hdr[7]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cda210
> pg_hit_count: 0
> page_cache_hdr[8]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cdb210
> pg_hit_count: 0
> page_cache_hdr[9]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cdc210
> pg_hit_count: 0
> page_cache_hdr[10]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cdd210
> pg_hit_count: 0
> page_cache_hdr[11]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cde210
> pg_hit_count: 0
> page_cache_hdr[12]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: cdf210
> pg_hit_count: 0
> page_cache_hdr[13]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: ce0210
> pg_hit_count: 0
> page_cache_hdr[14]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: ce1210
> pg_hit_count: 0
> page_cache_hdr[15]:
> pg_flags: 0 ()
> pg_addr: 0
> pg_bufptr: ce2210
> pg_hit_count: 0
>
> page_cache_buf: cd3210
> evict_index: 0
> evictions: 0
> accesses: 0
> cached_reads: 0
> valid_pages: cd0000
> crash: pv_init_ops exists: ARCH_PVOPS
> compressed kdump: phys_base: 0
> gdb vmlinux-2.6.32.12-0.7-default.debug
> 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"...
> GETBUF(248 -> 0)
> GETBUF(1500 -> 1)
>
> FREEBUF(1)
> FREEBUF(0)
> <readmem: ffffffff8141ae40, KVADDR, "kernel_config_data", 32768, ROE), 1ab66b0>
> addr: ffffffff8141ae40 paddr: 141ae40 cnt: 448
> crash: seek error: kernel virtual address: ffffffff8141ae40 type: "kernel_config_data"
> WARNING: cannot read kernel_config_data
> GETBUF(248 -> 0)
> FREEBUF(0)
> GETBUF(512 -> 0)
> <readmem: ffffffff81413640, KVADDR, "cpu_possible_mask", 8, (FOE), 7fff84995368>
> addr: ffffffff81413640 paddr: 1413640 cnt: 8
> crash: seek error: kernel virtual address: ffffffff81413640 type: "cpu_possible_mask"
>
> if I use --minimal can got crash> but It limits a lot..
>
> something like crash can't find cpu_possible_mask and
> cpu_possible_mask in vmcore I guess,
>
> I Google it and find some email talking about this , read the
> whitepaper writed by anderson, but I can't resolve it.
>
> any help I am really appreciated . Any other infomation need I
> provide, please tell me ,I'll reply as soon as possible.
Well for starters, crash-5.0.1 is quite old, and crash-5.0.1-1.5.5 is
a SUSE derivative, and typically I prefer to not get involved too
deeply into debugging issues with (1) older, and (2) derivative versions
of crash.
That being said, for some reason, when trying to access the physical pages
at 141ae40 and 1413640, the compressed kdump is returning SEEK_ERRORs,
which means that those two pages could not be found in the dumpfile.
Since they are both static kernel symbols that are below "edata", one
would expect that they would be there, even if the compressed kdump
had filtered out user pages, cache pages, zero-pages, etc.
A couple things you can try:
(1) Run "crash --minimal ..." on the vmcore, and enter:
* crash> rd linux_banner 30
When I run it on RHEL6 2.6.32-based system it looks like this:
* crash> rd linux_banner 30
* ffffffff81600020: *65762078756e694c 2e32206e6f697372 * Linux version 2.
* ffffffff81600030: *3032322d32332e36 3638782e366c652e * 6.32-220.el6.x86
* ffffffff81600040: *636f6d282034365f 7840646c6975626b * _64 (mockbuild@x
* ffffffff81600050: *622e3430302d3638 736f622e646c6975 * 86-004.build.bos
* ffffffff81600060: *2e7461686465722e 63672820296d6f63 * .redhat.com) (gc
* ffffffff81600070: *6f69737265762063 20352e342e34206e * c version 4.4.5
* ffffffff81600080: *3431323031313032 6148206465522820 * 20110214 (Red Ha
* ffffffff81600090: *2d352e342e342074 2943434728202936 * t 4.4.5-6) (GCC)
* ffffffff816000a0: *4d53203123202920 6f4e206465572050 * *) #1 SMP Wed No
* ffffffff816000b0: *303a383020392076 5453452033313a33 * v 9 08:03:13 EST
* ffffffff816000c0: *00000a3131303220 0000000000000000 * *2011...........
* ffffffff816000d0: *0000000000000000 0000000000000000 * ................
* ffffffff816000e0: *6973726576207325 6d28207325206e6f * %s version %s (m
* ffffffff816000f0: *646c6975626b636f 3430302d36387840 * ockbuild@x86-004
* ffffffff81600100: *622e646c6975622e 61686465722e736f * .build.bos.redha
* crash>
The "Linux version..." string should line up as shown above. *What happens
when you do that?
(2) Log onto the machine that crashed -- which is still presumably running
* * the vmlinux-2.6.32.12-0.7-default kernel -- and try to bring up crash
* * on the live system:
*$ crash vmlinux-2.6.32.12-0.7-default vmlinux-2.6.32.12-0.7-default.debug
What happens then?
Dave
------------------------------
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
End of Crash-utility Digest, Vol 82, Issue 6
********************************************
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Crash-utility Digest, Vol 82, Issue 6
