<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Michael Holzheu wrote: <blockquote TYPE=CITE>> 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. </blockquote> <tt>I know I'm setting myself up for flames here, but</tt> <tt>why not use NFS? Prior to writing this, I was just</tt> <tt>looking at an x86_64 vmcore file stored on, and</tt> <tt>NFS-mounted from, an x86 netdump server, and have</tt> <tt>done that many times.</tt> <blockquote TYPE=CITE> > 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. </blockquote> <tt>I really don't know much about this Alicia, other than</tt> <tt>seeing their initial LKML offering and their web site.</tt> <tt>Seems to completely sit on top of crash or lcrash.</tt> <tt>Their mailing lists have been essentially unused.</tt><tt></tt> <tt>Dave</tt> <blockquote TYPE=CITE> 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</blockquote> <tt></tt> </html>