update for xen hypervisor analysis
by Itsuro ODA
Hi,
This is an update for xen hypervisor analysis.
This patch is diff from crash-4.0-3.13.
Note that xen hypervisor analysis in the crash-4.0-3.13
works with a dump taken by before xen-unstable-12502.
The format of crash-notes saved in the xen hypervisor
changed at xen-unstable-12502 and xen-unstable-12733
(by Magnus).
This patch support both before 12502 and after 12502
and after 12733. (ie. all)
(support architecture: x86, x86_64)
Thanks.
--
Itsuro ODA <oda(a)valinux.co.jp>
17 years, 9 months
RE: [Crash-utility] Crash extensions and GPL
by Castor Fu
Good point... well, I guess we've lived with it this long... ;-)
________________________________
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
Sent: Wednesday, December 13, 2006 5:32 AM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] Crash extensions and GPL
Castor Fu wrote:
Would it be possible to modify the license for crash so
extensions
would not be subject to the GPL? Our developers create
extensions
which use our proprietary source code, and while they are most
useful in-house, it'd be nice to be able to ship them to
customers.
I am not a lawyer, nor am I an open source zealot, but the
crash utility is subject to the GPL due to the embedded gdb
module. Given that any extension would be in all probability
require a gdb service, how could you work around that?
Dave
We're certainly interested in contributing back generically
useful code,
but this would be a 'nice to have'.
I'm not a lawyer, so I'm not sure how to modify the license, but
I could
ask people here for help if this seems reasonable.
-castor
________________________________
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
17 years, 9 months
trouble builing crash 4.0-3.14
by Guy Streeter
I get errors trying to build crash 4.0-3.14 on a RHEL4u4 x86_64 system.
Here are the errors I see:
+ /usr/lib/rpm/find-debuginfo.sh /home/hsv/streeter/redhat/BUILD/crash-4.0-3.14
extracting debug info from /var/tmp/crash-root/usr/bin/crash
cpio: crash-4.0-3.14/gdb-6.1/bfd/<internal>: No such file or directory
cpio: crash-4.0-3.14/gdb-6.1/gdb/<internal>: No such file or directory
cpio: crash-4.0-3.14/gdb-6.1/libiberty/<internal>: No such file or
directory
cpio: crash-4.0-3.14/gdb-6.1/readline/<internal>: No such file or
directory
21666 blocks
+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
/var/tmp/rpm-tmp.13189: line 37: /usr/lib/rpm/check-rpaths: No such file
or directory
error: Bad exit status from /var/tmp/rpm-tmp.13189 (%install)
I'm attaching the log of the build.
thanks,
--Guy
17 years, 9 months
Re: [Crash-utility] ANN: Pykdump - Python scripting for Crash
by Dave Anderson
Alex Sidorenko wrote:
> Hi Dave,
>
> sorry for mischief - I joined the mailing-list today using my short email
> address <asid(a)hp.com>, but sent email from another mailer which was
> configured to use my long email address, <alexandre.sidorenko(a)hp.com>.
>
> I posted again, this time using <asid(a)hp.com>
>
> BTW - would it be possible to change in crash sourcefile extensions.c the way
> you do dlopen:
>
> ext->handle = dlopen(ext->filename, RTLD_NOW);
>
> adding RTLD_GLOBAL flag, i.e.
>
> ext->handle = dlopen(ext->filename, RTLD_NOW|RTLD_GLOBAL);
>
> Python is usually shipped with extensions built as dynamically-loadable
> modules, so we need RTLD_GLOBAL to make this work ('extend' loads Python
> extension, it loads another extension...)
>
> Without this, I need to patch extensions.c myself every time I compile the new
> version of crash from sources.
>
> Regards,
> Alex
>
No problem -- I've queued it for the next release...
Thanks,
Dave
>
> ------------------------------------------------------------------
> Alexandre Sidorenko email: alexs(a)hplinux.canada.hp.com
> Global Solutions Engineering: Unix Networking
> Hewlett-Packard (Canada)
> ------------------------------------------------------------------
17 years, 9 months
Re: How about an enumerated list of issues with the existing kgdb patches?
by Piet Delaney
On Wed, 2006-08-30 at 20:00 -0700, Andrew Morton wrote:
> On Wed, 30 Aug 2006 19:42:32 -0700
> Piet Delaney <piet(a)bluelane.com> wrote:
>
> > On Wed, 2006-08-30 at 15:57 -0700, Andrew Morton wrote:
> > > On Wed, 30 Aug 2006 14:48:22 -0700
> > > Andrew Morton <akpm(a)osdl.org> wrote:
> > >
> > > > Plus: I'd want to see a maintainance person or team who
> > > > respond promptly to email and who remain reasonably engaged with what's
> > > > going on in the mainline kernel. Because if problems crop up (and they
> > > > will), I don't want to have to be the bunny who has to worry about them...
> > >
> > > umm, clarification needed here.
> > >
> > > No criticism of the present maintainers intended! Last time I grabbed the
> > > kgdb patches from sf.net they applied nicely, worked quite reliably (much
> > > better than the old ones I'd been trying to sustain) and had been
> > > tremendously cleaned up.
> >
> > So why did you stop including them in the mm patch?
>
> Some change in 2.6.17-pre caused it to all stop working.
>
> > I recall your quality issue and Tom was all in favor
> > of resolving them. Was it too much work cleaning up the
> > patches to meet your needs that lead to the patch being
> > dropped from the mm series?
>
> It all seems reasonably clean now, but I haven't looked closely (nor have I
> had to)
Any suggestions on how to progress?
>
> > kgdb over ethernet is working great, and it looks like there
> > is plenty of support on the SF mailing list.
>
> good.
>
> > >
> > > It's a big step.
> >
> > How about a concrete list of patch quality issues that the group
> > can address to allow your weekly addition to the mm patch as a
> > set toward eventually integration.
>
> >From whom? me?
>
> > Wouldn't getting kgdb back into the mm patch series be a reasonable
> > first step eventual maintenance in kernel.org?
>
> Is on my todo list somewhere.
--
Piet Delaney Phone: (408) 200-5256
Blue Lane Technologies Fax: (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014 Email: piet(a)bluelane.com
17 years, 9 months
ANN: Pykdump - Python scripting for Crash
by Alex Sidorenko
Pykdump-0.1 - Python extension and scripting support
LinuxDump-0.1 - Extra modules and examples for Pykdump
------------------------------------------------------------------
This is the initial release of framework that embeds the Python interpeter in
a dynamically-loadable 'crash' extension and lets you run Python scripts,
e.g.
crash32> extend /usr/local/lib/pykdump32.so
/usr/local/lib/pykdump32.so: shared object loaded
crash32> epython test.py
...
'Pykdump' module provides basic functionality and consists of C-extension and
pure Python module. 'LinuxDump' includes an additional library and some
examples: emulating 'dev' command, printing routing table and
emulating 'netstat -an'.
This is an early release - documentation is not complete yet, some
functionality is missing (e.g. proper access to multidimensional arrays),
performance can be further improved. But it is already quite usable for
practical purposes (as demonstrated by several real cases we worked on in
HP).
There are functions to execute GDB/crash commands and get their output, but it
is better to use highlevel API that maps C-structures to Python objects, here
is an example:
--------------------test.py------------------------------------------
#!/usr/bin/env python
# This imports all the functions you can use from pykdump
from pykdump.API import *
# Check whether symbol exists
if (symbol_exists('all_bdevs')):
print "all_bdevs exists"
# Read the contents of 'tcp_hashinfo' table. The result type is chosen
# automatically according to symbol definition
tcp_hashinfo = readSymbol('tcp_hashinfo')
# Print the size of ESTABLISHED hash-table
print tcp_hashinfo.tcp_ehash_size
---------------------------------------------------------------------
You can download the packages (sources only, no binaries yet) from
http://sourceforge.net/projects/pykdump
The framework has been successfully built and used on IA32, AMD64 (64-bit) and
IA64, adding support for other platforms should be easy but has not been done
yet. The documentation is included in Pykdump module (written using LyX,
converted to HTML and PDF).
Any help/feedback will be appreciated.
Regards,
Alex
------------------------------------------------------------------
Alexandre Sidorenko email: alexs(a)hplinux.canada.hp.com
Global Solutions Engineering: Unix Networking
Hewlett-Packard (Canada)
------------------------------------------------------------------
17 years, 9 months
Identifying structures related to memory , semaphores using crash utility
by ram ba
Hi all,
I was running crash to analyse a vmcore generated by a 2.6.16.21-0.8.uis.1-smp kernel ( on x86_64 architecture). During this I came to know that we get a list of all kernel symbols with the help of "sym -l" command. With the help of "whatis" command we can know the symbol definition.But applying "whatis" command to each symbol and checking its definition appears to be tedious. Is there any other way to identify as to which symbols represent structures?
Also I wanted to isolate the structures related to memory, semaphores, tasks. Since I am new to crash utility, I couldn't get much information. Could you please provide some suggestions as to how to go about it.
Thanks,
Ramya
---------------------------------
Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers.
17 years, 9 months
crash can not read ia64 lkcd v9 dump
by Olaf Hering
crash 4.0-3.9 can not read a dump file from an ia64 box running 2.6.5.
Is this supposed to work?
crash -s boot/System.map-2.6.5-7.267-sn2 boot/Kerntypes-2.6.5-7.267-sn2 dump.3
crash: diskdump: dump does not have panic dump header
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: 3 (DUMP_LEVEL_HEADER|DUMP_LEVEL_KERN)
dh_page_size: 16384
dh_memory_size: 20993310
dh_memory_start: e000000000000000
dh_memory_end: a8190173618f23ed
dh_num_pages: 336091
dh_panic_string: sysrq
dh_time: Mon Aug 21 08:32:07 2006
dh_utsname_sysname: Linux
dh_utsname_nodename: cognac
dh_utsname_release: 2.6.5-7.267-sn2
dh_utsname_version: #1 SMP Wed Jun 21 10:50:51 UTC 2006
dh_utsname_machine: ia64
dh_utsname_domainname:
dh_current_task: e00009b0287a8000
dh_dump_compress: 2 (DUMP_COMPRESS_GZIP)
dh_dump_flags: 80000004 ()
dh_dump_device: 0
crash: LKCD machine specific dump header doesn't match crash version: 3b200 761f8
crash: traceback of currently executing threads may not work
gdb boot/Kerntypes-2.6.5-7.267-sn2
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 "ia64-unknown-linux-gnu"...
GETBUF(248 -> 0)
GETBUF(1500 -> 1)
please wait... (patching 20920 gdb minimal_symbol values) ^M ^M FREEBUF(1)
FREEBUF(0)
<readmem: a0000001005fa0d0, KVADDR, "kernel_config_data", 32768, (ROE), 60000000002e8310>
crash: seek error: kernel virtual address: a0000001005fa0d0 type: "kernel_config_data"
WARNING: cannot read kernel_config_data
<readmem: a000000100acea80, KVADDR, "xtime", 16, (FOE), 600000000006fc70>
crash: seek error: kernel virtual address: a000000100acea80 type: "xtime"
17 years, 9 months
Simple patch for 'crash -s'
by Castor Fu
On LKCD dumps, the 'silent' option for crash has a little
'spinner' which looks pretty ugly in the output.
This patch turns that off.
-castor
<<crash-4.0-3.14-hush.patch>>
17 years, 9 months
