[Crash-utility] Re: crash enhancements proposal

[Dave Anderson]

Michael Holzheu wrote:

> > Among the high priority needs are:
> >
> > 1) Cross architecture support. It is really painful for me to have to
> find
> > a ppc64 or s390x system with enough dasd and other resources to perform
> > an analysis. Given that most of tthe problems I look at do not involve
> > architecture specific issues it would be really useful if I could analyze
> > ppc64 and s390(x) dumps on a x86 or x86_64 system.
>
> Right, this is something, we from Linux for zSeries desperately need.
> In Böblingen we currently only use cross lcrash on an intel dump server,
> which can debug s390 and s390x dumps.
>
> This is an important reason, why crash currently is no option for us.
>

I know I'm setting myself up for flames here, but
why not use NFS?  Prior to writing this, I was just
looking at an x86_64 vmcore file stored on, and
NFS-mounted from, an x86 netdump server, and have
done that many times.

>
> > 2) Scripting support. I'd prefer to see a commonly used scripting
> language
> > such as perl or python be integrated rather than something like SIAL be
> > invented. There is a project named "Alicia" that is working to integrate
> > perl with crash. But I haven't had time to play with it so I can't say
> how
> > well it works.
>

I really don't know much about this Alicia, other than
seeing their initial LKML offering and their web site.
Seems to completely sit on top of crash or lcrash.
Their mailing lists have been essentially unused.

Dave

>
> Right, we have kernel areas, where we are dependent on the scripting
> support
> in lcrash. One example is our s390x common IO layer, where we could have
> hunderds of device structures, which you can't parse by hand. Here
> we use lcrash sial scripts to do the analysis.
>
> But I would really vote for a C-like language. This is definitely a
> big advantage of sial, since you can copy kernel code and data
> structures 1:1 into your analysis scripts!
>
> >
> > 3) Making as much of the current crash initialization optional as
> possible
> > so that we have a hope of getting useful info (e.g., dmesg buffer) out of
> > the dump.
>
> I also agree here! Especially, if your kernel crashes at a very early
> time during booting or big memory areas are damaged, this feature is
> very important!
>
> Michael


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060508/0305580d/attachment.htm>