Re: [Crash-utility] Cell/B.E. SPU commands extension
by Lucio Correia
> Lucio Correia wrote:
> > Hi,
> >
> > I've developed this crash extension to analyze SPU specific data for
> > Cell/B.E. processor. This extension makes use of some important data
> > saved by this kernel patch (that is not mainline yet)
> > http://ozlabs.org/pipermail/cbe-oss-dev/2007-May/001848.html during the
> > crash dump.
> >
> > I would like to check if there is any issue with the code.
> >
>
> Functionally it looks fine.
>
> I changed the _init() function to just do an error(INFO, ...)
> so I could load the extensions, and the only suggestion
> I can make is purely aesthetic, which would be to make
> the "help" messages 80 characters or less like the regular
> commands are. In other words, the "DESCRIPTION" section
> outputs, and the sentences in in the "spuctx" EXAMPLE
> section are kind of ugly the way that they run on with
> no linefeeds.
>
> But like I said before, I don't see any issues/problems
> with the code -- pretty nifty extension...
>
> Dave
>
Thanks for the comments, Dave. I'm correcting these issues.
Regards,
--
Lucio Correia
Software Engineer
IBM LTC Brazil
16 years, 11 months
- 4
- 5
Re: Re: Re: crash and sles 9 dumps (Dave Anderson)
by Daniel Li
Hey Dave,
When you said this was something you never saw before, did you mean you
never tried to use crash on a dump of SLES9 guest with the nonstandard
ELF format, or that this scenario was working for you, thus you didn't
see this type of error message?
If the answer happen to be the first one, do you have any plan to
support SLES guest dumps? (with the new ELF format you incorporated in
the first half of this year to get crash working with Redhat guest dumps)
Later,
Daniel
Virtual Iron Software, Inc
www.virtualiron.com
crash-utility-request(a)redhat.com wrote:
> Send Crash-utility mailing list submissions to
> crash-utility(a)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(a)redhat.com
>
> You can reach the person managing the list at
> crash-utility-owner(a)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. Re: Re: crash and sles 9 dumps (Dave Anderson)
> 2. Re: crash and sles 9 GUEST dumps (Dave Anderson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 20 Aug 2007 15:49:47 -0400
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] Re: crash and sles 9 dumps
> To: holzheu(a)linux.vnet.ibm.com, "Discussion list for crash utility
> usage, maintenance and development" <crash-utility(a)redhat.com>
> Message-ID: <46C9F05B.2090800(a)redhat.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Michael Holzheu wrote:
>
>> Hi Cliff
>>
>> On Mon, 2007-08-13 at 11:33 -0500, Cliff Wickman wrote:
>>
>>
>>> On Fri, Aug 10, 2007 at 05:19:10PM +0200, Bernhard Walle wrote:
>>>
>>
>>> The kerntypes file that crash can use is built by the LKCD dwarfexract
>>> command. Types are extracted from a -g kernel and modules. And dwarfextract
>>> writes a magic ELF e_version that crash uses to distinguish a kerntypes from
>>> a vmlinux. So only such a kerntypes file will work.
>>>
>> Also the standard -g compiled lkcd Kerntypes file seems to work, if you
>> set the KERNTYPES flag. This can be useful, if you don't want to build a
>> full -g compiled vmlinux.
>>
>> I used the following simple patch which adds the "-k" option to force
>> crash using the kerntypes code path.
>>
>> diff -Naurp crash-4.0-4.5/main.c crash-4.0-4.5-kerntypes/main.c
>> --- crash-4.0-4.5/main.c 2007-08-13 15:07:20.000000000 +0200
>> +++ crash-4.0-4.5-kerntypes/main.c 2007-08-13 15:06:51.000000000 +0200
>> @@ -70,7 +70,7 @@ main(int argc, char **argv)
>> */
>> opterr = 0;
>> optind = 0;
>> - while((c = getopt_long(argc, argv, "Lgh::e:i:sSvc:d:tfp:m:",
>> + while((c = getopt_long(argc, argv, "Lkgh::e:i:sSvc:d:tfp:m:",
>> long_options, &option_index)) != -1) {
>> switch (c)
>> {
>> @@ -222,6 +222,9 @@ main(int argc, char **argv)
>> else
>> program_usage(LONG_FORM);
>> clean_exit(0);
>> + case 'k':
>> + pc->flags |= KERNTYPES;
>> + break;
>>
>> case 'e':
>> if (STREQ(optarg, "vi"))
>>
>>
>>
>
> This simple "-k" fix looks fine to me, presuming that there's
> nothing else obvious in the lkcd kerntypes file that distinguishes
> it -- i.e., like the unique ELF e_version that dwarfextract uses.
> (EV_DWARFEXTRACT 101010101)
>
> So unless anybody objects, or has a better idea, I'll put this -k
> option in the next release.
>
> Thanks,
> Dave
>
>
>
>> I attached the kerntypes file, which works for s390:
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> /*
>> * kerntypes.c
>> *
>> * Dummy module that includes headers for all kernel types of interest.
>> * The kernel type information is used by the lcrash utility when
>> * analyzing system crash dumps or the live system. Using the type
>> * information for the running system, rather than kernel header files,
>> * makes for a more flexible and robust analysis tool.
>> *
>> * This source code is released under the GNU GPL.
>> */
>>
>> /* generate version for this file */
>> typedef char *COMPILE_VERSION;
>>
>> /* General linux types */
>>
>> #include <linux/autoconf.h>
>> #include <linux/compile.h>
>> #include <linux/utsname.h>
>> #include <linux/module.h>
>> #include <linux/sched.h>
>> #include <linux/mm.h>
>> #include <linux/slab_def.h>
>> #include <linux/slab.h>
>> #include <linux/bio.h>
>> #include <linux/bitmap.h>
>> #include <linux/bitops.h>
>> #include <linux/bitrev.h>
>> #include <linux/blkdev.h>
>> #include <linux/blkpg.h>
>> #include <linux/bootmem.h>
>> #include <linux/buffer_head.h>
>> #include <linux/cache.h>
>> #include <linux/cdev.h>
>> #include <linux/cpu.h>
>> #include <linux/cpumask.h>
>> #include <linux/cpuset.h>
>> #include <linux/dcache.h>
>> #include <linux/debugfs.h>
>> #include <linux/elevator.h>
>> #include <linux/fd.h>
>> #include <linux/file.h>
>> #include <linux/fs.h>
>> #include <linux/futex.h>
>> #include <linux/genhd.h>
>> #include <linux/highmem.h>
>> #include <linux/if.h>
>> #include <linux/if_addr.h>
>> #include <linux/if_arp.h>
>> #include <linux/if_bonding.h>
>> #include <linux/if_ether.h>
>> #include <linux/if_tr.h>
>> #include <linux/if_tun.h>
>> #include <linux/if_vlan.h>
>> #include <linux/in.h>
>> #include <linux/in6.h>
>> #include <linux/in_route.h>
>> #include <linux/inet.h>
>> #include <linux/inet_diag.h>
>> #include <linux/inetdevice.h>
>> #include <linux/init.h>
>> #include <linux/initrd.h>
>> #include <linux/inotify.h>
>> #include <linux/interrupt.h>
>> #include <linux/ioctl.h>
>> #include <linux/ip.h>
>> #include <linux/ipsec.h>
>> #include <linux/ipv6.h>
>> #include <linux/ipv6_route.h>
>> #include <linux/irq.h>
>> #include <linux/irqflags.h>
>> #include <linux/irqreturn.h>
>> #include <linux/jbd.h>
>> #include <linux/jbd2.h>
>> #include <linux/jffs2.h>
>> #include <linux/jhash.h>
>> #include <linux/jiffies.h>
>> #include <linux/kallsyms.h>
>> #include <linux/kernel.h>
>> #include <linux/kernel_stat.h>
>> #include <linux/kexec.h>
>> #include <linux/kobject.h>
>> #include <linux/kthread.h>
>> #include <linux/ktime.h>
>> #include <linux/list.h>
>> #include <linux/memory.h>
>> #include <linux/miscdevice.h>
>> #include <linux/mm.h>
>> #include <linux/mm_inline.h>
>> #include <linux/mm_types.h>
>> #include <linux/mman.h>
>> #include <linux/mmtimer.h>
>> #include <linux/mmzone.h>
>> #include <linux/mnt_namespace.h>
>> #include <linux/module.h>
>> #include <linux/moduleloader.h>
>> #include <linux/moduleparam.h>
>> #include <linux/mount.h>
>> #include <linux/mpage.h>
>> #include <linux/mqueue.h>
>> #include <linux/mtio.h>
>> #include <linux/mutex.h>
>> #include <linux/namei.h>
>> #include <linux/neighbour.h>
>> #include <linux/net.h>
>> #include <linux/netdevice.h>
>> #include <linux/netfilter.h>
>> #include <linux/netfilter_arp.h>
>> #include <linux/netfilter_bridge.h>
>> #include <linux/netfilter_decnet.h>
>> #include <linux/netfilter_ipv4.h>
>> #include <linux/netfilter_ipv6.h>
>> #include <linux/netlink.h>
>> #include <linux/netpoll.h>
>> #include <linux/pagemap.h>
>> #include <linux/param.h>
>> #include <linux/percpu.h>
>> #include <linux/percpu_counter.h>
>> #include <linux/pfn.h>
>> #include <linux/pid.h>
>> #include <linux/pid_namespace.h>
>> #include <linux/poll.h>
>> #include <linux/posix-timers.h>
>> #include <linux/posix_acl.h>
>> #include <linux/posix_acl_xattr.h>
>> #include <linux/posix_types.h>
>> #include <linux/preempt.h>
>> #include <linux/prio_tree.h>
>> #include <linux/proc_fs.h>
>> #include <linux/profile.h>
>> #include <linux/ptrace.h>
>> #include <linux/radix-tree.h>
>> #include <linux/ramfs.h>
>> #include <linux/raw.h>
>> #include <linux/rbtree.h>
>> #include <linux/rcupdate.h>
>> #include <linux/reboot.h>
>> #include <linux/relay.h>
>> #include <linux/resource.h>
>> #include <linux/romfs_fs.h>
>> #include <linux/root_dev.h>
>> #include <linux/route.h>
>> #include <linux/rwsem.h>
>> #include <linux/sched.h>
>> #include <linux/sem.h>
>> #include <linux/seq_file.h>
>> #include <linux/seqlock.h>
>> #include <linux/shm.h>
>> #include <linux/shmem_fs.h>
>> #include <linux/signal.h>
>> #include <linux/signalfd.h>
>> #include <linux/skbuff.h>
>> #include <linux/smp.h>
>> #include <linux/smp_lock.h>
>> #include <linux/socket.h>
>> #include <linux/sockios.h>
>> #include <linux/spinlock.h>
>> #include <linux/stat.h>
>> #include <linux/statfs.h>
>> #include <linux/stddef.h>
>> #include <linux/swap.h>
>> #include <linux/swapops.h>
>> #include <linux/sys.h>
>> #include <linux/syscalls.h>
>> #include <linux/sysctl.h>
>> #include <linux/sysdev.h>
>> #include <linux/sysfs.h>
>> #include <linux/sysrq.h>
>> #include <linux/tc.h>
>> #include <linux/tcp.h>
>> #include <linux/thread_info.h>
>> #include <linux/threads.h>
>> #include <linux/tick.h>
>> #include <linux/time.h>
>> #include <linux/timer.h>
>> #include <linux/timerfd.h>
>> #include <linux/times.h>
>> #include <linux/timex.h>
>> #include <linux/topology.h>
>> #include <linux/transport_class.h>
>> #include <linux/tty.h>
>> #include <linux/tty_driver.h>
>> #include <linux/tty_flip.h>
>> #include <linux/tty_ldisc.h>
>> #include <linux/types.h>
>> #include <linux/uaccess.h>
>> #include <linux/unistd.h>
>> #include <linux/utime.h>
>> #include <linux/uts.h>
>> #include <linux/utsname.h>
>> #include <linux/utsrelease.h>
>> #include <linux/version.h>
>> #include <linux/vfs.h>
>> #include <linux/vmalloc.h>
>> #include <linux/vmstat.h>
>> #include <linux/wait.h>
>> #include <linux/watchdog.h>
>> #include <linux/workqueue.h>
>> #include <linux/zconf.h>
>> #include <linux/zlib.h>
>>
>> /*
>> * s390 specific includes
>> */
>>
>> #include <asm/lowcore.h>
>> #include <asm/debug.h>
>> #include <asm/ccwdev.h>
>> #include <asm/ccwgroup.h>
>> #include <asm/qdio.h>
>> #include <asm/zcrypt.h>
>> #include <asm/etr.h>
>> #include <asm/ipl.h>
>> #include <asm/setup.h>
>>
>> /* channel subsystem driver */
>> #include "drivers/s390/cio/cio.h"
>> #include "drivers/s390/cio/chsc.h"
>> #include "drivers/s390/cio/css.h"
>> #include "drivers/s390/cio/device.h"
>> #include "drivers/s390/cio/qdio.h"
>>
>> /* dasd device driver */
>> #include "drivers/s390/block/dasd_int.h"
>> #include "drivers/s390/block/dasd_diag.h"
>> #include "drivers/s390/block/dasd_eckd.h"
>> #include "drivers/s390/block/dasd_fba.h"
>>
>> /* networking drivers */
>> #include "drivers/s390/net/fsm.h"
>> #include "include/net/iucv/iucv.h"
>> #include "drivers/s390/net/lcs.h"
>> #include "drivers/s390/net/qeth.h"
>>
>> /* zfcp device driver */
>> #include "drivers/s390/scsi/zfcp_def.h"
>> #include "drivers/s390/scsi/zfcp_fsf.h"
>>
>> /* crypto device driver */
>> #include "drivers/s390/crypto/ap_bus.h"
>> #include "drivers/s390/crypto/zcrypt_api.h"
>> #include "drivers/s390/crypto/zcrypt_cca_key.h"
>> #include "drivers/s390/crypto/zcrypt_pcica.h"
>> #include "drivers/s390/crypto/zcrypt_pcicc.h"
>> #include "drivers/s390/crypto/zcrypt_pcixcc.h"
>> #include "drivers/s390/crypto/zcrypt_cex2a.h"
>>
>> /* sclp device driver */
>> #include "drivers/s390/char/sclp.h"
>> #include "drivers/s390/char/sclp_rw.h"
>> #include "drivers/s390/char/sclp_tty.h"
>>
>> /* vmur device driver */
>> #include "drivers/s390/char/vmur.h"
>>
>> /*
>> * include sched.c for types:
>> * - struct prio_array
>> * - struct runqueue
>> */
>> #include "kernel/sched.c"
>> /*
>> * include slab.c for struct kmem_cache
>> */
>> #include "mm/slab.c"
>>
>>
>> ------------------------------------------------------------------------
>>
>> --
>> Crash-utility mailing list
>> Crash-utility(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/crash-utility
>>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 20 Aug 2007 16:25:01 -0400
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] crash and sles 9 GUEST dumps
> To: "Discussion list for crash utility usage, maintenance and
> development" <crash-utility(a)redhat.com>
> Message-ID: <46C9F89D.1000301(a)redhat.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Daniel Li wrote:
>
>> After finding out how to get crash working with native sles 9 LKCD
>> format dumps -- namely, build and use a debug vmlinux with appropriate
>> flags to feed to crash -- I started looking into using crash on kernel
>> dumps created for sles 9 guest domains.
>>
>> As compared to the LKCD format of native sles 9 dumps, those dumps are
>> created using the new non-standard ELF format with section headers
>> instead of program headers, which is the case with the xenctrl library
>> now. Such formats are working for RHAS4U4 64bit guests, while I had to
>> make minor modification to make it work for RHAS4U4 32bit guests as
>> well. However, when it comes to sles 9 guests, crash seems to be having
>> problems locating the stacks for each thread, with the exception of the
>> CURRENT thread. (see below)
>>
>> It may well be that the stack pointers were not saved properly for sles
>> 9 guests by the Xen library in the dump. I'll take a look into the dump
>> and the xen library code to see if that is the case... Or is this the
>> case of crash not looking in the right places for those stack pointers?
>>
>>
>
> Looking at the data below, this is hard to decipher what's going on.
>
> The "ps" list -- except for the current task at ffffffff803d2800, shows
> seemingly legitimate tasks because the COMM ("task_struct.comm[16]")
> strings look OK. But the state (ST) fields and the PPID values are
> bogus?
>
> > crash> ps
> > PID PPID CPU TASK ST %MEM VSZ RSS COMM
> > > 0 0 0 ffffffff803d2800 RU 0.0 4399648058624
> > 4389578663200 [<80>^L]
> > 0 0 0 ffffffff803d2808 ?? 0.0 0 0 [swapper]
> > 1 0 0 10017e1f2c8 ?? 0.1 640 304 init
> > 2 -1 0 10017e1e9a8 ?? 0.0 0 0 [migration/0]
> > 3 -1 0 10017e1e088 ?? 0.0 0 0 [ksoftirqd/0]
> ...
>
> But the state (ST) field and the PPID values above are bogus.
>
> And that's all confirmed when you ran the "task 10015180208" command,
> which simply has gdb print the task_struct at that address:
>
> > crash> bt 10015180208
> > PID: 3696 TASK: 10015180208 CPU: 0 COMMAND: "klogd"
> > *bt: invalid kernel virtual address: 12 type: "stack contents"*
> > bt: read of stack at 12 failed
> > crash> task 10015180208
> > PID: 3696 TASK: 10015180208 CPU: 0 COMMAND: "klogd"
> > struct task_struct {
> > *state = 1099873050624,*
> > * thread_info = 0x12,*
> > usage = {
> > counter = 320
> > },
> > flags = 0,
> ...
> > comm = "klogd\000roc\000\000\000\000\000\000",
> ...
>
> The "state" and "thread_info" (i.e., the stack page pointer) fields
> make no sense, while the "comm" field, and many of the others (upon
> a quick examination) do seem correct.
>
> It's interesting that all of the task_struct addresses end in "8",
> though. If you were to enter "task_struct 10015180200", do those
> two fields look right, and perhaps due to structure padding (?),
> you'd still see the "klog" string in the correct place?
>
> I'm sure this is something I've never seen before, so I'm afraid I
> can't offer any answers or suggestions...
>
> Dave
>
>
>
>
>> Thanks,
>> Daniel
>>
>> /dumps/new/sles/64bit$ /home/dli/bin/crash vmlinux-2.6.5-7.244-smp
>> vmlinux.dbg DUMP10.1.230.112
>>
>> crash 4.0-4.5
>> Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 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"...
>>
>> WARNING: could not find MAGIC_START!
>> please wait... (gathering task table data)
>> crash: invalid kernel virtual address: 13 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: f type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 6 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: c type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 13 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: c type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 18 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: f type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 13 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 13 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 12 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 11 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 15 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: f type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 12 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 6e type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 22 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 13 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: f type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: c type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: c type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 13 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: f type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: f type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 11 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 10 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: c type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 14 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 13 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: 18 type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: f type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: e type: "fill_thread_info"
>>
>> crash: invalid kernel virtual address: f type: "fill_thread_info"
>> please wait... (determining panic task)
>> bt: invalid kernel virtual address: 13 type: "stack contents"
>>
>> bt: read of stack at 13 failed
>>
>>
>> bt: invalid kernel virtual address: f type: "stack contents"
>>
>> bt: read of stack at f failed
>>
>>
>> bt: invalid kernel virtual address: 6 type: "stack contents"
>>
>> bt: read of stack at 6 failed
>>
>>
>> bt: invalid kernel virtual address: c type: "stack contents"
>>
>> bt: read of stack at c failed
>>
>>
>> bt: invalid kernel virtual address: 13 type: "stack contents"
>>
>> bt: read of stack at 13 failed
>>
>>
>> bt: invalid kernel virtual address: c type: "stack contents"
>>
>> bt: read of stack at c failed
>>
>>
>> bt: invalid kernel virtual address: 18 type: "stack contents"
>>
>> bt: read of stack at 18 failed
>>
>>
>> bt: invalid kernel virtual address: f type: "stack contents"
>>
>> bt: read of stack at f failed
>>
>>
>> bt: invalid kernel virtual address: 13 type: "stack contents"
>>
>> bt: read of stack at 13 failed
>>
>>
>> bt: invalid kernel virtual address: 13 type: "stack contents"
>>
>> bt: read of stack at 13 failed
>>
>>
>> bt: invalid kernel virtual address: 12 type: "stack contents"
>>
>> bt: read of stack at 12 failed
>>
>>
>> bt: invalid kernel virtual address: 11 type: "stack contents"
>>
>> bt: read of stack at 11 failed
>>
>>
>> bt: invalid kernel virtual address: 15 type: "stack contents"
>>
>> bt: read of stack at 15 failed
>>
>>
>> bt: invalid kernel virtual address: f type: "stack contents"
>>
>> bt: read of stack at f failed
>>
>>
>> bt: invalid kernel virtual address: 12 type: "stack contents"
>>
>> bt: read of stack at 12 failed
>>
>>
>> bt: invalid kernel virtual address: 6e type: "stack contents"
>>
>> bt: read of stack at 6e failed
>>
>>
>> bt: invalid kernel virtual address: 22 type: "stack contents"
>>
>> bt: read of stack at 22 failed
>>
>>
>> bt: invalid kernel virtual address: 13 type: "stack contents"
>>
>> bt: read of stack at 13 failed
>>
>>
>> bt: invalid kernel virtual address: f type: "stack contents"
>>
>> bt: read of stack at f failed
>>
>>
>> bt: invalid kernel virtual address: c type: "stack contents"
>>
>> bt: read of stack at c failed
>>
>>
>> bt: invalid kernel virtual address: c type: "stack contents"
>>
>> bt: read of stack at c failed
>>
>>
>> bt: invalid kernel virtual address: 13 type: "stack contents"
>>
>> bt: read of stack at 13 failed
>>
>>
>> bt: invalid kernel virtual address: f type: "stack contents"
>>
>> bt: read of stack at f failed
>>
>>
>> bt: invalid kernel virtual address: f type: "stack contents"
>>
>> bt: read of stack at f failed
>>
>>
>> bt: invalid kernel virtual address: 11 type: "stack contents"
>>
>> bt: read of stack at 11 failed
>>
>>
>> bt: invalid kernel virtual address: 10 type: "stack contents"
>>
>> bt: read of stack at 10 failed
>>
>>
>> bt: invalid kernel virtual address: c type: "stack contents"
>>
>> bt: read of stack at c failed
>>
>>
>> bt: invalid kernel virtual address: 14 type: "stack contents"
>>
>> bt: read of stack at 14 failed
>>
>>
>> bt: invalid kernel virtual address: 13 type: "stack contents"
>>
>> bt: read of stack at 13 failed
>>
>>
>> bt: invalid kernel virtual address: 18 type: "stack contents"
>>
>> bt: read of stack at 18 failed
>>
>>
>> bt: invalid kernel virtual address: f type: "stack contents"
>>
>> bt: read of stack at f failed
>>
>>
>> bt: invalid kernel virtual address: e type: "stack contents"
>>
>> bt: read of stack at e failed
>>
>>
>> bt: invalid kernel virtual address: f type: "stack contents"
>>
>> bt: read of stack at f failed
>>
>> KERNEL: vmlinux-2.6.5-7.244-smp
>> DEBUG KERNEL: vmlinux.dbg (2.6.5-7.244-default)
>> DUMPFILE: DUMP10.1.230.112
>> CPUS: 1
>> DATE: Thu Jul 26 14:34:46 2007
>> UPTIME: 213503982284 days, 21:34:00
>> LOAD AVERAGE: 0.01, 0.12, 0.07
>> TASKS: 34
>> NODENAME: linux
>> RELEASE: 2.6.5-7.244-smp
>> VERSION: #1 SMP Mon Dec 12 18:32:25 UTC 2005
>> MACHINE: x86_64 (2793 Mhz)
>> MEMORY: 1015808 GB
>> PANIC: ""
>> PID: 0
>> COMMAND: "
>> "
>> TASK: ffffffff803d2800 (1 of 2) [THREAD_INFO: ffffffff80590000]
>> CPU: 0
>> STATE: TASK_RUNNING (ACTIVE)
>> WARNING: panic task not found
>>
>> crash> bt
>> PID: 0 TASK: ffffffff803d2800 CPU: 0 COMMAND: "<80>^L"
>> #0 [ffffffff80591ef0] schedule at ffffffff801394e4
>> #1 [ffffffff80591f98] default_idle at ffffffff8010f1c0
>> #2 [ffffffff80591fc8] cpu_idle at ffffffff8010f65a
>> crash> ps
>> PID PPID CPU TASK ST %MEM VSZ RSS COMM
>> > 0 0 0 ffffffff803d2800 RU 0.0 4399648058624
>> 4389578663200 [<80>^L]
>> 0 0 0 ffffffff803d2808 ?? 0.0 0 0 [swapper]
>> 1 0 0 10017e1f2c8 ?? 0.1 640 304 init
>> 2 -1 0 10017e1e9a8 ?? 0.0 0 0 [migration/0]
>> 3 -1 0 10017e1e088 ?? 0.0 0 0 [ksoftirqd/0]
>> 4 -1 0 10001b712d8 ?? 0.0 0 0 [events/0]
>> 5 -1 0 10001b709b8 ?? 0.0 0 0 [khelper]
>> 6 -1 0 10001b70098 ?? 0.0 0 0 [kacpid]
>> 25 -1 0 10017dd72e8 ?? 0.0 0 0 [kblockd/0]
>> 47 -1 0 10017dd69c8 ?? 0.0 0 0 [pdflush]
>> 48 -1 0 10017dd60a8 ?? 0.0 0 0 [pdflush]
>> 49 -1 0 100178272f8 ?? 0.0 0 0 [kswapd0]
>> 50 -1 0 100178269d8 ?? 0.0 0 0 [aio/0]
>> 1295 -1 0 100178260b8 ?? 0.0 0 0 [kseriod]
>> 2077 -1 0 10017897308 ?? 0.0 0 0 [reiserfs/0]
>> 2744 -1 0 10014de9488 ?? 0.0 0 0 [khubd]
>> 3077 -1 0 10015aa13c8 ?? 0.2 2560 608 hwscand
>> 3693 -1 0 100164e1348 ?? 0.2 3568 816 syslogd
>> 3696 -1 0 10015180208 ?? 0.3 2744 1112 klogd
>> 3721 -1 0 10015b0eab8 ?? 0.2 3536 628 resmgrd
>> 3722 -1 0 10015e6e1c8 ?? 0.2 4564 640 portmap
>> 3803 -1 0 10015d49368 ?? 0.6 20036 2340 master
>> 3814 -1 0 10015daea58 ?? 0.6 20100 2312 pickup
>> 3815 -1 0 10016c5a0d8 ?? 0.6 20144 2364 qmgr
>> 3861 -1 0 10016ca2a08 ?? 0.7 26800 2932 sshd
>> 4022 -1 0 10014c42b48 ?? 0.2 6804 924 cron
>> 4057 -1 0 100178960c8 ?? 0.2 2484 612 agetty
>> 4058 -1 0 10016c5b318 ?? 0.5 21864 1772 login
>> 4059 -1 0 10016ca3328 ?? 0.2 7012 936 mingetty
>> 4060 -1 0 10015fb5398 ?? 0.2 7012 936 mingetty
>> 4061 -1 0 10014cc6238 ?? 0.2 7012 936 mingetty
>> 4062 -1 0 10015b0f3d8 ?? 0.2 7012 936 mingetty
>> 4063 -1 0 100151e7458 ?? 0.2 7012 936 mingetty
>> 4152 -1 0 10016a180f8 ?? 0.8 12716 2992 bash
>> crash> bt 10015180208
>> PID: 3696 TASK: 10015180208 CPU: 0 COMMAND: "klogd"
>> *bt: invalid kernel virtual address: 12 type: "stack contents"*
>> bt: read of stack at 12 failed
>> crash> task 10015180208
>> PID: 3696 TASK: 10015180208 CPU: 0 COMMAND: "klogd"
>> struct task_struct {
>> *state = 1099873050624,*
>> * thread_info = 0x12,*
>> usage = {
>> counter = 320
>> },
>> flags = 0,
>> ptrace = 502511173631,
>> lock_depth = 120,
>> prio = 0,
>> static_prio = 1048832,
>> run_list = {
>> next = 0x200200,
>> prev = 0x0
>> },
>> array = 0x50fe72e6,
>> sleep_avg = 1,
>> interactive_credit = 67616128664,
>> timestamp = 67616128664,
>> last_ran = 0,
>> activated = 0,
>> policy = 18446744073709551615,
>> cpus_allowed = 18446744073709551615,
>> time_slice = 150,
>> first_time_slice = 0,
>> tasks = {
>> next = 0x10015b0eb48,
>> prev = 0x100164e13d8
>> },
>> ptrace_children = {
>> next = 0x100151802a8,
>> prev = 0x100151802a8
>> },
>> ptrace_list = {
>> next = 0x100151802b8,
>> prev = 0x100151802b8
>> },
>> mm = 0x1001546c500,
>> active_mm = 0x1001546c500,
>> binfmt = 0xffffffff803e70c0,
>> exit_state = 0,
>> exit_code = 0,
>> exit_signal = 17,
>> pdeath_signal = 0,
>> personality = 0,
>> did_exec = 0,
>> pid = 3696,
>> tgid = 3696,
>> real_parent = 0x10017e1f2c0,
>> parent = 0x10017e1f2c0,
>> children = {
>> next = 0x10015180320,
>> prev = 0x10015180320
>> },
>> sibling = {
>> next = 0x10015b0ebe0,
>> prev = 0x100164e1470
>> },
>> group_leader = 0x10015180200,
>> pids = {{
>> pid_chain = {
>> next = 0x10015180370,
>> prev = 0x10015180370
>> },
>> pidptr = 0x10015180360,
>> pid = {
>> nr = 3696,
>> count = {
>> counter = 1
>> },
>> task = 0x10015180200,
>> task_list = {
>> next = 0x10015180348,
>> prev = 0x10015180348
>> },
>> hash_chain = {
>> next = 0x10017827470,
>> prev = 0x10016ca2b80
>> }
>> }
>> }, {
>> pid_chain = {
>> next = 0x100151803b8,
>> prev = 0x100151803b8
>> },
>> pidptr = 0x100151803a8,
>> pid = {
>> nr = 3696,
>> count = {
>> counter = 1
>> },
>> task = 0x10015180200,
>> task_list = {
>> next = 0x10015180390,
>> prev = 0x10015180390
>> },
>> hash_chain = {
>> next = 0x100178274b8,
>> prev = 0x10016ca2bc8
>> }
>> }
>> }, {
>> pid_chain = {
>> next = 0x10015180400,
>> prev = 0x10015180400
>> },
>> pidptr = 0x100151803f0,
>> pid = {
>> nr = 3696,
>> count = {
>> counter = 1
>> },
>> task = 0x10015180200,
>> task_list = {
>> next = 0x100151803d8,
>> prev = 0x100151803d8
>> },
>> hash_chain = {
>> next = 0x10001949240,
>> prev = 0x10016ca2c10
>> }
>> }
>> }, {
>> pid_chain = {
>> next = 0x10015180448,
>> prev = 0x10015180448
>> },
>> pidptr = 0x10015180438,
>> pid = {
>> nr = 3696,
>> count = {
>> counter = 1
>> },
>> task = 0x10015180200,
>> task_list = {
>> next = 0x10015180420,
>> prev = 0x10015180420
>> },
>> hash_chain = {
>> next = 0x10001949340,
>> prev = 0x10016ca2c58
>> }
>> }
>> }},
>> wait_chldexit = {
>> lock = {
>> lock = 1
>> },
>> task_list = {
>> next = 0x10015180470,
>> prev = 0x10015180470
>> }
>> },
>> vfork_done = 0x0,
>> set_child_tid = 0x2a95894b90,
>> clear_child_tid = 0x2a95894b90,
>> rt_priority = 0,
>> it_real_value = 0,
>> it_prof_value = 0,
>> it_virt_value = 0,
>> it_real_incr = 0,
>> it_prof_incr = 0,
>> it_virt_incr = 0,
>> real_timer = {
>> entry = {
>> next = 0x100100,
>> prev = 0x200200
>> },
>> expires = 29143,
>> lock = {
>> lock = 1
>> },
>> magic = 1267182958,
>> function = 0xffffffff80141b50 <it_real_fn>,
>> data = 1099865522688,
>> base = 0x0
>> },
>> utime = 0,
>> stime = 4,
>> cutime = 0,
>> cstime = 0,
>> nvcsw = 13,
>> nivcsw = 2,
>> cnvcsw = 0,
>> cnivcsw = 0,
>> start_time = 53888910424,
>> min_flt = 105,
>> maj_flt = 0,
>> cmin_flt = 0,
>> cmaj_flt = 0,
>> uid = 0,
>> euid = 0,
>> suid = 0,
>> fsuid = 0,
>> gid = 0,
>> egid = 0,
>> sgid = 0,
>> fsgid = 0,
>> group_info = 0xffffffff803e2a00,
>> cap_effective = 4294967039,
>> cap_inheritable = 0,
>> cap_permitted = 4294967039,
>> keep_capabilities = 0,
>> user = 0xffffffff803e29a0,
>> rlim = {{
>> rlim_cur = 18446744073709551615,
>> rlim_max = 18446744073709551615
>> }, {
>> rlim_cur = 18446744073709551615,
>> rlim_max = 18446744073709551615
>> }, {
>> rlim_cur = 18446744073709551615,
>> rlim_max = 18446744073709551615
>> }, {
>> rlim_cur = 8388608,
>> rlim_max = 18446744073709551615
>> }, {
>> rlim_cur = 0,
>> rlim_max = 18446744073709551615
>> }, {
>> rlim_cur = 18446744073709551615,
>> rlim_max = 18446744073709551615
>> }, {
>> rlim_cur = 3071,
>> rlim_max = 3071
>> }, {
>> rlim_cur = 1024,
>> rlim_max = 1024
>> }, {
>> rlim_cur = 18446744073709551615,
>> rlim_max = 18446744073709551615
>> }, {
>> rlim_cur = 18446744073709551615,
>> rlim_max = 18446744073709551615
>> }, {
>> rlim_cur = 18446744073709551615,
>> rlim_max = 18446744073709551615
>> }, {
>> rlim_cur = 1024,
>> rlim_max = 1024
>> }, {
>> rlim_cur = 819200,
>> rlim_max = 819200
>> }},
>> used_math = 0,
>> rcvd_sigterm = 0,
>> oomkilladj = 0,
>> comm = "klogd\000roc\000\000\000\000\000\000",
>> link_count = 0,
>> total_link_count = 0,
>> sysvsem = {
>> undo_list = 0x0
>> },
>> thread = {
>> rsp0 = 1099873058120,
>> rsp = 548682070920,
>> userrsp = 182897429248,
>> fs = 0,
>> gs = 0,
>> es = 0,
>> ds = 0,
>> fsindex = 0,
>> gsindex = 0,
>> debugreg0 = 0,
>> debugreg1 = 0,
>> debugreg2 = 0,
>> debugreg3 = 0,
>> debugreg6 = 0,
>> debugreg7 = 0,
>> cr2 = 0,
>> trap_no = 0,
>> error_code = 0,
>> i387 = {
>> fxsave = {
>> cwd = 0,
>> swd = 0,
>> twd = 0,
>> fop = 0,
>> rip = 0,
>> rdp = 281470681751424,
>> mxcsr = 0,
>> mxcsr_mask = 0,
>> st_space = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0},
>> xmm_space = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
>> , 0, 0, 0},
>> padding = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0}
>> }
>> },
>> ioperm = 0,
>> io_bitmap_ptr = 0x0,
>> tls_array = {0, 0, 0}
>> },
>> fs = 0x10014c7a180,
>> files = 0x10001a114c0,
>> namespace = 0x100154fb900,
>> signal = 0x10015184600,
>> sighand = 0x0,
>> blocked = {
>> sig = {0}
>> },
>> real_blocked = {
>> sig = {1099865524632}
>> },
>> pending = {
>> list = {
>> next = 0x10015180998,
>> prev = 0x0
>> },
>> signal = {
>> sig = {0}
>> }
>> },
>> sas_ss_sp = 0,
>> sas_ss_size = 0,
>> notifier = 0,
>> notifier_data = 0x0,
>> notifier_mask = 0x0,
>> security = 0x600000005,
>> parent_exec_id = 1,
>> self_exec_id = 1,
>> alloc_lock = {
>> lock = 1
>> },
>> proc_lock = {
>> lock = 0
>> },
>> switch_lock = {
>> lock = 0
>> },
>> journal_info = 0x0,
>> reclaim_state = 0x10015469180,
>> proc_dentry = 0x0,
>> backing_dev_info = 0x10015b40940,
>> io_context = 0x0,
>> ptrace_message = 0,
>> last_siginfo = 0x0,
>> io_wait = 0xac9,
>> rchar = 2292,
>> wchar = 3,
>> syscr = 32,
>> syscw = 475,
>> acct_rss_mem1 = 2743,
>> acct_vm_mem1 = 4,
>> acct_stimexpd = 4294967297,
>> ckrm_tsklock = {
>> lock = 0
>> },
>> ckrm_celock = {
>> lock = 0
>> },
>> ce_data = 0xffffffff804f3f20,
>> taskclass = 0x100164e1bc8,
>> taskclass_link = {
>> next = 0x10015b0f338,
>> prev = 0xffffffff80537940
>> },
>> cpu_class = 0x0,
>> demand_stat = {
>> run = 0,
>> total = 61218488692,
>> last_sleep = 32000000,
>> recalc_interval = 0,
>> cpu_demand = 105133020
>> },
>> delays = {
>> waitcpu_total = 3647587,
>> runcpu_total = 23603870,
>> iowait_total = 0,
>> mem_iowait_total = 4294967311,
>> runs = 0,
>> num_iowaits = 0,
>> num_memwaits = 0,
>> splpar_total = 1431654400
>> },
>> map_base = 0,
>> mempolicy = 0x0,
>> il_next = 0,
>> audit = 0x10
>> }
>>
>> crash>
>>
>>
>> --
>> Crash-utility mailing list
>> Crash-utility(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/crash-utility
>>
>
>
>
>
> ------------------------------
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> End of Crash-utility Digest, Vol 23, Issue 8
> ********************************************
>
>
17 years
- 2
- 6
[PATCH] fix read size in xendump.c
by Isaku Yamahata
Hi.
Recently I twisted the xen xm dump-core format so that the section
order was changed for optimization.
Although it shouldn't affect analysis tools, it revealed a bug.
The crash utility tries to read the file beyond EOF.
So far it wasn't issue because of section ordering.
This patch fixes it by calculating read size correctly
Dave,
Although I don't think that it causes serious issues,
Could you check whether the minor update of the format affects
the crash utility?
http://article.gmane.org/gmane.comp.emulators.xen.ia64/7531
http://article.gmane.org/gmane.comp.emulators.xen.devel/42996
--- crash-4.0-4.6-ORIG/xendump.c 2007-08-28 00:51:11.000000000 +0900
+++ ./crash-4.0-4.6/xendump.c 2007-08-29 18:14:05.000000000 +0900
@@ -1289,9 +1289,8 @@ xc_core_mfn_to_page(ulong mfn, char *pgb
for (b = 0, idx = -1, done = FALSE;
!done && (b < nr_pages); b += MAX_BATCH_SIZE) {
-
- if (read(xd->xfd, tmp, sizeof(ulong) * MAX_BATCH_SIZE) !=
- (MAX_BATCH_SIZE * sizeof(ulong))) {
+ size_t size = sizeof(ulong) * MIN(MAX_BATCH_SIZE, nr_pages - b);
+ if (read(xd->xfd, tmp, size) != size) {
error(INFO, "cannot read index page %d\n", b);
return NULL;
}
@@ -1348,13 +1347,11 @@ xc_core_elf_mfn_to_page(ulong mfn, char
{
int i, b, idx, done;
off_t offset;
- size_t size;
uint nr_pages;
ulong tmp;
struct xen_dumpcore_p2m p2m_batch[MAX_BATCH_SIZE];
offset = xd->xc_core.header.xch_index_offset;
- size = sizeof(struct xen_dumpcore_p2m) * MAX_BATCH_SIZE;
nr_pages = xd->xc_core.header.xch_nr_pages;
if (lseek(xd->xfd, offset, SEEK_SET) == -1)
@@ -1362,7 +1359,8 @@ xc_core_elf_mfn_to_page(ulong mfn, char
for (b = 0, idx = -1, done = FALSE;
!done && (b < nr_pages); b += MAX_BATCH_SIZE) {
-
+ size_t size = sizeof(struct xen_dumpcore_p2m) *
+ MIN(MAX_BATCH_SIZE, nr_pages - b);
if (read(xd->xfd, &p2m_batch[0], size) != size) {
error(INFO, "cannot read index page %d\n", b);
return NULL;
@@ -1437,9 +1435,9 @@ xc_core_mfn_to_page_index(ulong mfn)
nr_pages *= 2;
for (b = 0; b < nr_pages; b += MAX_BATCH_SIZE) {
-
- if (read(xd->xfd, tmp, sizeof(ulong) * MAX_BATCH_SIZE) !=
- (MAX_BATCH_SIZE * sizeof(ulong))) {
+ size_t size =
+ sizeof(ulong) * MIN(MAX_BATCH_SIZE, nr_pages - b);
+ if (read(xd->xfd, tmp, size) != size) {
error(INFO, "cannot read index page %d\n", b);
return MFN_NOT_FOUND;
}
@@ -1469,20 +1467,19 @@ xc_core_elf_mfn_to_page_index(ulong mfn)
{
int i, b;
off_t offset;
- size_t size;
uint nr_pages;
ulong tmp;
struct xen_dumpcore_p2m p2m_batch[MAX_BATCH_SIZE];
offset = xd->xc_core.header.xch_index_offset;
- size = sizeof(struct xen_dumpcore_p2m) * MAX_BATCH_SIZE;
nr_pages = xd->xc_core.header.xch_nr_pages;
if (lseek(xd->xfd, offset, SEEK_SET) == -1)
error(FATAL, "cannot lseek to page index\n");
for (b = 0; b < nr_pages; b += MAX_BATCH_SIZE) {
-
+ size_t size = sizeof(struct xen_dumpcore_p2m) *
+ MIN(MAX_BATCH_SIZE, nr_pages - b);
if (read(xd->xfd, &p2m_batch[0], size) != size) {
error(INFO, "cannot read index page %d\n", b);
return MFN_NOT_FOUND;
@@ -1563,8 +1560,9 @@ check_next_4:
nr_pages = xd->xc_core.header.xch_nr_pages;
for (b = 0; b < nr_pages; b += MAX_BATCH_SIZE) {
- if (read(xd->xfd, tmp, sizeof(ulong) * MAX_BATCH_SIZE) !=
- (MAX_BATCH_SIZE * sizeof(ulong))) {
+ size_t size = sizeof(ulong) *
+ MIN(MAX_BATCH_SIZE, nr_pages - b);
+ if (read(xd->xfd, tmp, size) != size) {
error(INFO, "cannot read index page %d\n", b);
return FALSE;
}
@@ -1595,8 +1593,9 @@ show_64bit_mfns:
nr_pages = xd->xc_core.header.xch_nr_pages;
for (b = 0; b < nr_pages; b += MAX_BATCH_SIZE) {
- if (read(xd->xfd, tmp64, sizeof(ulonglong) * MAX_BATCH_SIZE) !=
- (MAX_BATCH_SIZE * sizeof(ulonglong))) {
+ size_t size = sizeof(ulonglong) *
+ MIN(MAX_BATCH_SIZE, nr_pages - b);
+ if (read(xd->xfd, tmp64, size) != size) {
error(INFO, "cannot read index page %d\n", b);
return FALSE;
}
@@ -1709,13 +1708,11 @@ xc_core_elf_pfn_to_page_index(ulong pfn)
{
int i, b, start_index;
off_t offset;
- size_t size;
uint nr_pages;
ulong tmp;
struct xen_dumpcore_p2m p2m_batch[MAX_BATCH_SIZE];
offset = xd->xc_core.header.xch_index_offset;
- size = sizeof(struct xen_dumpcore_p2m) * MAX_BATCH_SIZE;
nr_pages = xd->xc_core.header.xch_nr_pages;
/*
@@ -1744,7 +1741,8 @@ xc_core_elf_pfn_to_page_index(ulong pfn)
error(FATAL, "cannot lseek to page index\n");
for (b = start_index; b < nr_pages; b += MAX_BATCH_SIZE) {
-
+ size_t size = sizeof(struct xen_dumpcore_p2m) *
+ MIN(MAX_BATCH_SIZE, nr_pages - b);
if (read(xd->xfd, &p2m_batch[0], size) != size) {
error(INFO, "cannot read index page %d\n", b);
return PFN_NOT_FOUND;
@@ -1838,13 +1836,11 @@ xc_core_elf_pfn_valid(ulong pfn)
{
int i, b, start_index;
off_t offset;
- size_t size;
uint nr_pages;
ulong tmp;
uint64_t pfn_batch[MAX_BATCH_SIZE];
offset = xd->xc_core.header.xch_index_offset;
- size = sizeof(uint64_t) * MAX_BATCH_SIZE;
nr_pages = xd->xc_core.header.xch_nr_pages;
/*
@@ -1873,7 +1869,8 @@ xc_core_elf_pfn_valid(ulong pfn)
error(FATAL, "cannot lseek to page index\n");
for (b = start_index; b < nr_pages; b += MAX_BATCH_SIZE) {
-
+ size_t size = sizeof(uint64_t) *
+ MIN(MAX_BATCH_SIZE, nr_pages - b);
if (read(xd->xfd, &pfn_batch[0], size) != size) {
error(INFO, "cannot read index page %d\n", b);
return PFN_NOT_FOUND;
--
yamahata
17 years
- 2
- 2
How to examine Xen in a crash dump?
by Markus Armbruster
I got some Xen crash dumps. I can easily examine dom0's kernel. I'd
like to examine the hypervisor. Possibly dumb question: how do I do
that?
17 years
- 2
- 2
crash version 4.0-4.6 is available
by Dave Anderson
- Implemented the "runq" command for 2.6.20 and later kernels that have
replaced the O(1) scheduler with the CFS scheduler. If the kernel
was configured to use CFS, the command will display the tasks queued
in each cpu's RT and CFS runqueues. (anderson(a)redhat.com)
- The initial support put in place for the usage of "kerntypes"
debuginfo files only recognized files created by the LKCD
"dwarfextract" utility run against a -g built vmlinux kernel.
This version adds a new "-k" command line option that allows the
usage of standard -g compiled LKCD Kerntypes files.
(holzheu(a)linux.vnet.ibm.com)
- Update of "xencrash" support to properly handle dom0/hypervisor
kdumps taken under xen version 3.1 in addition to those taken under
xen 3.0.x. Without this patch, the following warning message
would be displayed during initialization of a xen-syms hypervisor
session: "WARNING: unsupported elf note format". Fixes x86 "bt"
command segmentation violation when running against a xen-syms
hypervisor. Fixes x86_64 session initialization failure when running
against a xen-syms hypervisor, which would display the error
message "crash: invalid structure member offset: tss_struct_rsp0".
(oda(a)valinux.co.jp)
Download from: http://people.redhat.com/anderson
17 years
- 1
- 0
xencrash for xen 3.1
by Itsuro ODA
Hi,
Since some structures in the xen 3.1 are changed from
the xen 3.0.x, xencrash fails to open session with a
vmcore taken under the xen 3.1 (ex. RHEL5.1).
The attached patch fixes this problem. xencrash supports
a vmcore taken under the xen 3.1 in addition to a vmcore
taken under the xen 3.0.x.
This patch is for crash-4.0-4.5.
Thanks.
--
Itsuro ODA <oda(a)valinux.co.jp>
17 years
- 2
- 1
Can anyone give me a hint as to what's likely going wrong here?
by James Washer
This is a SLES9sp3 lcrash dump... on and x86_64 box... Should I expect crash to work here (using a -g kernel)?
Any/all help/hints are appreciated.
- jim
~/crash-4.0-4.5/crash -d 9 /usr/src/linux-2.6.5-7.244/vmlinux ~/dale/dump.1
crash 4.0-4.5
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 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.
crash: xc_core_elf_verify: not a xen ELF core file
crash: diskdump: dump does not have panic dump header
dump_header:
dh_magic_number: a8190173618f23ed (DUMP_MAGIC_NUMBER)
dh_version: 9 (LKCD_DUMP_V9)
dh_header_size: 742
dh_dump_level: f (DUMP_LEVEL_HEADER|DUMP_LEVEL_KERN|DUMP_LEVEL_USED|DUMP_LEVEL_ALL)
dh_page_size: 4096
dh_memory_size: 1010052
dh_memory_start: 10000000000
dh_memory_end: a8190173618f23ed
dh_num_pages: 1031926
dh_panic_string: NMI watchdog detected
dh_time: Wed Aug 1 13:39:37 2007
dh_utsname_sysname: Linux
dh_utsname_nodename: ibmdyn2038
dh_utsname_release: 2.6.5-7.244-smp
dh_utsname_version: #1 SMP Mon Dec 12 18:32:25 UTC 2005
dh_utsname_machine: x86_64
dh_utsname_domainname: cae_ibmdy
dh_current_task: 10002c7e9b0
dh_dump_compress: 2 (DUMP_COMPRESS_GZIP)
dh_dump_flags: 80000000 ()
dh_dump_device: 0
found DUMP_DH_END
gdb /usr/src/linux-2.6.5-7.244/vmlinux
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"...
GETBUF(248 -> 0)
GETBUF(1500 -> 1)
FREEBUF(1)
FREEBUF(0)
<readmem: ffffffff8036cda0, KVADDR, "kernel_config_data", 32768, (ROE), 13535a0>
WARNING: could not find MAGIC_START!
<readmem: ffffffff8058f210, KVADDR, "xtime", 16, (FOE), 9062b0>
<readmem: ffffffff803d42e0, KVADDR, "system_utsname", 390, (ROE), 90689c>
<readmem: ffffffff803d42c8, KVADDR, "linux_banner", 8, (FOE), 7fbfffd5d8>
WARNING: invalid linux_banner pointer: 0
<readmem: 0, KVADDR, "accessible check", 8, (ROE|Q), 7fbfffd250>
crash: invalid kernel virtual address: 0 type: "accessible check"
crash: /usr/src/linux-2.6.5-7.244/vmlinux and /root/dale/dump.1 do not match!
Usage:
crash [-h [opt]][-v][-s][-i file][-d num] [-S] [mapfile] [namelist] [dumpfile]
Enter "crash -h" for details.
17 years
- 3
- 2
Crash Port for ARM
by Indraneel
Hi,
We want to port Crash for ARM. AFAIK there is no support available for ARM.
So,
1. Is there any porting guide available for Crash?
2. If any of the people on this ML have ported crash to another
architecture, can they please broadly outline the work that needs to be
done?
TIA,
Indro
17 years
- 2
- 1
crash and sles 9 GUEST dumps
by Daniel Li
After finding out how to get crash working with native sles 9 LKCD
format dumps -- namely, build and use a debug vmlinux with appropriate
flags to feed to crash -- I started looking into using crash on kernel
dumps created for sles 9 guest domains.
As compared to the LKCD format of native sles 9 dumps, those dumps are
created using the new non-standard ELF format with section headers
instead of program headers, which is the case with the xenctrl library
now. Such formats are working for RHAS4U4 64bit guests, while I had to
make minor modification to make it work for RHAS4U4 32bit guests as
well. However, when it comes to sles 9 guests, crash seems to be having
problems locating the stacks for each thread, with the exception of the
CURRENT thread. (see below)
It may well be that the stack pointers were not saved properly for sles
9 guests by the Xen library in the dump. I'll take a look into the dump
and the xen library code to see if that is the case... Or is this the
case of crash not looking in the right places for those stack pointers?
Thanks,
Daniel
/dumps/new/sles/64bit$ /home/dli/bin/crash vmlinux-2.6.5-7.244-smp
vmlinux.dbg DUMP10.1.230.112
crash 4.0-4.5
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 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"...
WARNING: could not find MAGIC_START!
please wait... (gathering task table data)
crash: invalid kernel virtual address: 13 type: "fill_thread_info"
crash: invalid kernel virtual address: f type: "fill_thread_info"
crash: invalid kernel virtual address: 6 type: "fill_thread_info"
crash: invalid kernel virtual address: c type: "fill_thread_info"
crash: invalid kernel virtual address: 13 type: "fill_thread_info"
crash: invalid kernel virtual address: c type: "fill_thread_info"
crash: invalid kernel virtual address: 18 type: "fill_thread_info"
crash: invalid kernel virtual address: f type: "fill_thread_info"
crash: invalid kernel virtual address: 13 type: "fill_thread_info"
crash: invalid kernel virtual address: 13 type: "fill_thread_info"
crash: invalid kernel virtual address: 12 type: "fill_thread_info"
crash: invalid kernel virtual address: 11 type: "fill_thread_info"
crash: invalid kernel virtual address: 15 type: "fill_thread_info"
crash: invalid kernel virtual address: f type: "fill_thread_info"
crash: invalid kernel virtual address: 12 type: "fill_thread_info"
crash: invalid kernel virtual address: 6e type: "fill_thread_info"
crash: invalid kernel virtual address: 22 type: "fill_thread_info"
crash: invalid kernel virtual address: 13 type: "fill_thread_info"
crash: invalid kernel virtual address: f type: "fill_thread_info"
crash: invalid kernel virtual address: c type: "fill_thread_info"
crash: invalid kernel virtual address: c type: "fill_thread_info"
crash: invalid kernel virtual address: 13 type: "fill_thread_info"
crash: invalid kernel virtual address: f type: "fill_thread_info"
crash: invalid kernel virtual address: f type: "fill_thread_info"
crash: invalid kernel virtual address: 11 type: "fill_thread_info"
crash: invalid kernel virtual address: 10 type: "fill_thread_info"
crash: invalid kernel virtual address: c type: "fill_thread_info"
crash: invalid kernel virtual address: 14 type: "fill_thread_info"
crash: invalid kernel virtual address: 13 type: "fill_thread_info"
crash: invalid kernel virtual address: 18 type: "fill_thread_info"
crash: invalid kernel virtual address: f type: "fill_thread_info"
crash: invalid kernel virtual address: e type: "fill_thread_info"
crash: invalid kernel virtual address: f type: "fill_thread_info"
please wait... (determining panic task)
bt: invalid kernel virtual address: 13 type: "stack contents"
bt: read of stack at 13 failed
bt: invalid kernel virtual address: f type: "stack contents"
bt: read of stack at f failed
bt: invalid kernel virtual address: 6 type: "stack contents"
bt: read of stack at 6 failed
bt: invalid kernel virtual address: c type: "stack contents"
bt: read of stack at c failed
bt: invalid kernel virtual address: 13 type: "stack contents"
bt: read of stack at 13 failed
bt: invalid kernel virtual address: c type: "stack contents"
bt: read of stack at c failed
bt: invalid kernel virtual address: 18 type: "stack contents"
bt: read of stack at 18 failed
bt: invalid kernel virtual address: f type: "stack contents"
bt: read of stack at f failed
bt: invalid kernel virtual address: 13 type: "stack contents"
bt: read of stack at 13 failed
bt: invalid kernel virtual address: 13 type: "stack contents"
bt: read of stack at 13 failed
bt: invalid kernel virtual address: 12 type: "stack contents"
bt: read of stack at 12 failed
bt: invalid kernel virtual address: 11 type: "stack contents"
bt: read of stack at 11 failed
bt: invalid kernel virtual address: 15 type: "stack contents"
bt: read of stack at 15 failed
bt: invalid kernel virtual address: f type: "stack contents"
bt: read of stack at f failed
bt: invalid kernel virtual address: 12 type: "stack contents"
bt: read of stack at 12 failed
bt: invalid kernel virtual address: 6e type: "stack contents"
bt: read of stack at 6e failed
bt: invalid kernel virtual address: 22 type: "stack contents"
bt: read of stack at 22 failed
bt: invalid kernel virtual address: 13 type: "stack contents"
bt: read of stack at 13 failed
bt: invalid kernel virtual address: f type: "stack contents"
bt: read of stack at f failed
bt: invalid kernel virtual address: c type: "stack contents"
bt: read of stack at c failed
bt: invalid kernel virtual address: c type: "stack contents"
bt: read of stack at c failed
bt: invalid kernel virtual address: 13 type: "stack contents"
bt: read of stack at 13 failed
bt: invalid kernel virtual address: f type: "stack contents"
bt: read of stack at f failed
bt: invalid kernel virtual address: f type: "stack contents"
bt: read of stack at f failed
bt: invalid kernel virtual address: 11 type: "stack contents"
bt: read of stack at 11 failed
bt: invalid kernel virtual address: 10 type: "stack contents"
bt: read of stack at 10 failed
bt: invalid kernel virtual address: c type: "stack contents"
bt: read of stack at c failed
bt: invalid kernel virtual address: 14 type: "stack contents"
bt: read of stack at 14 failed
bt: invalid kernel virtual address: 13 type: "stack contents"
bt: read of stack at 13 failed
bt: invalid kernel virtual address: 18 type: "stack contents"
bt: read of stack at 18 failed
bt: invalid kernel virtual address: f type: "stack contents"
bt: read of stack at f failed
bt: invalid kernel virtual address: e type: "stack contents"
bt: read of stack at e failed
bt: invalid kernel virtual address: f type: "stack contents"
bt: read of stack at f failed
KERNEL: vmlinux-2.6.5-7.244-smp
DEBUG KERNEL: vmlinux.dbg (2.6.5-7.244-default)
DUMPFILE: DUMP10.1.230.112
CPUS: 1
DATE: Thu Jul 26 14:34:46 2007
UPTIME: 213503982284 days, 21:34:00
LOAD AVERAGE: 0.01, 0.12, 0.07
TASKS: 34
NODENAME: linux
RELEASE: 2.6.5-7.244-smp
VERSION: #1 SMP Mon Dec 12 18:32:25 UTC 2005
MACHINE: x86_64 (2793 Mhz)
MEMORY: 1015808 GB
PANIC: ""
PID: 0
COMMAND: "
"
TASK: ffffffff803d2800 (1 of 2) [THREAD_INFO: ffffffff80590000]
CPU: 0
STATE: TASK_RUNNING (ACTIVE)
WARNING: panic task not found
crash> bt
PID: 0 TASK: ffffffff803d2800 CPU: 0 COMMAND: "<80>^L"
#0 [ffffffff80591ef0] schedule at ffffffff801394e4
#1 [ffffffff80591f98] default_idle at ffffffff8010f1c0
#2 [ffffffff80591fc8] cpu_idle at ffffffff8010f65a
crash> ps
PID PPID CPU TASK ST %MEM VSZ RSS COMM
> 0 0 0 ffffffff803d2800 RU 0.0 4399648058624
4389578663200 [<80>^L]
0 0 0 ffffffff803d2808 ?? 0.0 0 0 [swapper]
1 0 0 10017e1f2c8 ?? 0.1 640 304 init
2 -1 0 10017e1e9a8 ?? 0.0 0 0 [migration/0]
3 -1 0 10017e1e088 ?? 0.0 0 0 [ksoftirqd/0]
4 -1 0 10001b712d8 ?? 0.0 0 0 [events/0]
5 -1 0 10001b709b8 ?? 0.0 0 0 [khelper]
6 -1 0 10001b70098 ?? 0.0 0 0 [kacpid]
25 -1 0 10017dd72e8 ?? 0.0 0 0 [kblockd/0]
47 -1 0 10017dd69c8 ?? 0.0 0 0 [pdflush]
48 -1 0 10017dd60a8 ?? 0.0 0 0 [pdflush]
49 -1 0 100178272f8 ?? 0.0 0 0 [kswapd0]
50 -1 0 100178269d8 ?? 0.0 0 0 [aio/0]
1295 -1 0 100178260b8 ?? 0.0 0 0 [kseriod]
2077 -1 0 10017897308 ?? 0.0 0 0 [reiserfs/0]
2744 -1 0 10014de9488 ?? 0.0 0 0 [khubd]
3077 -1 0 10015aa13c8 ?? 0.2 2560 608 hwscand
3693 -1 0 100164e1348 ?? 0.2 3568 816 syslogd
3696 -1 0 10015180208 ?? 0.3 2744 1112 klogd
3721 -1 0 10015b0eab8 ?? 0.2 3536 628 resmgrd
3722 -1 0 10015e6e1c8 ?? 0.2 4564 640 portmap
3803 -1 0 10015d49368 ?? 0.6 20036 2340 master
3814 -1 0 10015daea58 ?? 0.6 20100 2312 pickup
3815 -1 0 10016c5a0d8 ?? 0.6 20144 2364 qmgr
3861 -1 0 10016ca2a08 ?? 0.7 26800 2932 sshd
4022 -1 0 10014c42b48 ?? 0.2 6804 924 cron
4057 -1 0 100178960c8 ?? 0.2 2484 612 agetty
4058 -1 0 10016c5b318 ?? 0.5 21864 1772 login
4059 -1 0 10016ca3328 ?? 0.2 7012 936 mingetty
4060 -1 0 10015fb5398 ?? 0.2 7012 936 mingetty
4061 -1 0 10014cc6238 ?? 0.2 7012 936 mingetty
4062 -1 0 10015b0f3d8 ?? 0.2 7012 936 mingetty
4063 -1 0 100151e7458 ?? 0.2 7012 936 mingetty
4152 -1 0 10016a180f8 ?? 0.8 12716 2992 bash
crash> bt 10015180208
PID: 3696 TASK: 10015180208 CPU: 0 COMMAND: "klogd"
*bt: invalid kernel virtual address: 12 type: "stack contents"*
bt: read of stack at 12 failed
crash> task 10015180208
PID: 3696 TASK: 10015180208 CPU: 0 COMMAND: "klogd"
struct task_struct {
*state = 1099873050624,*
* thread_info = 0x12,*
usage = {
counter = 320
},
flags = 0,
ptrace = 502511173631,
lock_depth = 120,
prio = 0,
static_prio = 1048832,
run_list = {
next = 0x200200,
prev = 0x0
},
array = 0x50fe72e6,
sleep_avg = 1,
interactive_credit = 67616128664,
timestamp = 67616128664,
last_ran = 0,
activated = 0,
policy = 18446744073709551615,
cpus_allowed = 18446744073709551615,
time_slice = 150,
first_time_slice = 0,
tasks = {
next = 0x10015b0eb48,
prev = 0x100164e13d8
},
ptrace_children = {
next = 0x100151802a8,
prev = 0x100151802a8
},
ptrace_list = {
next = 0x100151802b8,
prev = 0x100151802b8
},
mm = 0x1001546c500,
active_mm = 0x1001546c500,
binfmt = 0xffffffff803e70c0,
exit_state = 0,
exit_code = 0,
exit_signal = 17,
pdeath_signal = 0,
personality = 0,
did_exec = 0,
pid = 3696,
tgid = 3696,
real_parent = 0x10017e1f2c0,
parent = 0x10017e1f2c0,
children = {
next = 0x10015180320,
prev = 0x10015180320
},
sibling = {
next = 0x10015b0ebe0,
prev = 0x100164e1470
},
group_leader = 0x10015180200,
pids = {{
pid_chain = {
next = 0x10015180370,
prev = 0x10015180370
},
pidptr = 0x10015180360,
pid = {
nr = 3696,
count = {
counter = 1
},
task = 0x10015180200,
task_list = {
next = 0x10015180348,
prev = 0x10015180348
},
hash_chain = {
next = 0x10017827470,
prev = 0x10016ca2b80
}
}
}, {
pid_chain = {
next = 0x100151803b8,
prev = 0x100151803b8
},
pidptr = 0x100151803a8,
pid = {
nr = 3696,
count = {
counter = 1
},
task = 0x10015180200,
task_list = {
next = 0x10015180390,
prev = 0x10015180390
},
hash_chain = {
next = 0x100178274b8,
prev = 0x10016ca2bc8
}
}
}, {
pid_chain = {
next = 0x10015180400,
prev = 0x10015180400
},
pidptr = 0x100151803f0,
pid = {
nr = 3696,
count = {
counter = 1
},
task = 0x10015180200,
task_list = {
next = 0x100151803d8,
prev = 0x100151803d8
},
hash_chain = {
next = 0x10001949240,
prev = 0x10016ca2c10
}
}
}, {
pid_chain = {
next = 0x10015180448,
prev = 0x10015180448
},
pidptr = 0x10015180438,
pid = {
nr = 3696,
count = {
counter = 1
},
task = 0x10015180200,
task_list = {
next = 0x10015180420,
prev = 0x10015180420
},
hash_chain = {
next = 0x10001949340,
prev = 0x10016ca2c58
}
}
}},
wait_chldexit = {
lock = {
lock = 1
},
task_list = {
next = 0x10015180470,
prev = 0x10015180470
}
},
vfork_done = 0x0,
set_child_tid = 0x2a95894b90,
clear_child_tid = 0x2a95894b90,
rt_priority = 0,
it_real_value = 0,
it_prof_value = 0,
it_virt_value = 0,
it_real_incr = 0,
it_prof_incr = 0,
it_virt_incr = 0,
real_timer = {
entry = {
next = 0x100100,
prev = 0x200200
},
expires = 29143,
lock = {
lock = 1
},
magic = 1267182958,
function = 0xffffffff80141b50 <it_real_fn>,
data = 1099865522688,
base = 0x0
},
utime = 0,
stime = 4,
cutime = 0,
cstime = 0,
nvcsw = 13,
nivcsw = 2,
cnvcsw = 0,
cnivcsw = 0,
start_time = 53888910424,
min_flt = 105,
maj_flt = 0,
cmin_flt = 0,
cmaj_flt = 0,
uid = 0,
euid = 0,
suid = 0,
fsuid = 0,
gid = 0,
egid = 0,
sgid = 0,
fsgid = 0,
group_info = 0xffffffff803e2a00,
cap_effective = 4294967039,
cap_inheritable = 0,
cap_permitted = 4294967039,
keep_capabilities = 0,
user = 0xffffffff803e29a0,
rlim = {{
rlim_cur = 18446744073709551615,
rlim_max = 18446744073709551615
}, {
rlim_cur = 18446744073709551615,
rlim_max = 18446744073709551615
}, {
rlim_cur = 18446744073709551615,
rlim_max = 18446744073709551615
}, {
rlim_cur = 8388608,
rlim_max = 18446744073709551615
}, {
rlim_cur = 0,
rlim_max = 18446744073709551615
}, {
rlim_cur = 18446744073709551615,
rlim_max = 18446744073709551615
}, {
rlim_cur = 3071,
rlim_max = 3071
}, {
rlim_cur = 1024,
rlim_max = 1024
}, {
rlim_cur = 18446744073709551615,
rlim_max = 18446744073709551615
}, {
rlim_cur = 18446744073709551615,
rlim_max = 18446744073709551615
}, {
rlim_cur = 18446744073709551615,
rlim_max = 18446744073709551615
}, {
rlim_cur = 1024,
rlim_max = 1024
}, {
rlim_cur = 819200,
rlim_max = 819200
}},
used_math = 0,
rcvd_sigterm = 0,
oomkilladj = 0,
comm = "klogd\000roc\000\000\000\000\000\000",
link_count = 0,
total_link_count = 0,
sysvsem = {
undo_list = 0x0
},
thread = {
rsp0 = 1099873058120,
rsp = 548682070920,
userrsp = 182897429248,
fs = 0,
gs = 0,
es = 0,
ds = 0,
fsindex = 0,
gsindex = 0,
debugreg0 = 0,
debugreg1 = 0,
debugreg2 = 0,
debugreg3 = 0,
debugreg6 = 0,
debugreg7 = 0,
cr2 = 0,
trap_no = 0,
error_code = 0,
i387 = {
fxsave = {
cwd = 0,
swd = 0,
twd = 0,
fop = 0,
rip = 0,
rdp = 281470681751424,
mxcsr = 0,
mxcsr_mask = 0,
st_space = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0},
xmm_space = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0
, 0, 0, 0},
padding = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0}
}
},
ioperm = 0,
io_bitmap_ptr = 0x0,
tls_array = {0, 0, 0}
},
fs = 0x10014c7a180,
files = 0x10001a114c0,
namespace = 0x100154fb900,
signal = 0x10015184600,
sighand = 0x0,
blocked = {
sig = {0}
},
real_blocked = {
sig = {1099865524632}
},
pending = {
list = {
next = 0x10015180998,
prev = 0x0
},
signal = {
sig = {0}
}
},
sas_ss_sp = 0,
sas_ss_size = 0,
notifier = 0,
notifier_data = 0x0,
notifier_mask = 0x0,
security = 0x600000005,
parent_exec_id = 1,
self_exec_id = 1,
alloc_lock = {
lock = 1
},
proc_lock = {
lock = 0
},
switch_lock = {
lock = 0
},
journal_info = 0x0,
reclaim_state = 0x10015469180,
proc_dentry = 0x0,
backing_dev_info = 0x10015b40940,
io_context = 0x0,
ptrace_message = 0,
last_siginfo = 0x0,
io_wait = 0xac9,
rchar = 2292,
wchar = 3,
syscr = 32,
syscw = 475,
acct_rss_mem1 = 2743,
acct_vm_mem1 = 4,
acct_stimexpd = 4294967297,
ckrm_tsklock = {
lock = 0
},
ckrm_celock = {
lock = 0
},
ce_data = 0xffffffff804f3f20,
taskclass = 0x100164e1bc8,
taskclass_link = {
next = 0x10015b0f338,
prev = 0xffffffff80537940
},
cpu_class = 0x0,
demand_stat = {
run = 0,
total = 61218488692,
last_sleep = 32000000,
recalc_interval = 0,
cpu_demand = 105133020
},
delays = {
waitcpu_total = 3647587,
runcpu_total = 23603870,
iowait_total = 0,
mem_iowait_total = 4294967311,
runs = 0,
num_iowaits = 0,
num_memwaits = 0,
splpar_total = 1431654400
},
map_base = 0,
mempolicy = 0x0,
il_next = 0,
audit = 0x10
}
crash>
17 years
- 2
- 1
Re: crash and sles 9 dumps
by Daniel Li
I got it working with vmlinux.dbg rebuilt with SMP flag turned on.
I wonder what was going on with crash and the kerntypes file, which was
working with lcrash.
The updates in the first half of this year enabled crash to work with
the (non-standard) ELF format dump generated for RedHat guests. It would
be great when the gust is SLES 9, the same non-standard ELF format dump
generated could also work with crash, since the mechanism for generating
such dumps are already in place.
Later,
Daniel
17 years
- 5
- 4