On 29/08/13 20:10, Rushikesh Jadhav wrote:

The problematic spinlock is at address 0xffff831960e72e90, which is sadly a dynamically allocated one so cant be traced back to a symbol using the symbol table.

Thanks. How easy or hard it is to trace such thing ? I tried google for xen crash analyze and came up with https://github.com/xenserver/xen-crashdump-analyser & http://xenbits.xen.org/people/andrewcoop/.

The xen crashdump analyser is my new replacement to an old tool we used, although my xenbits page is a tad out of date. For now, github should be considered the canonical source, although there has been interest in getting it into the main Xen tree (perhaps when I gain enough tuits).

Having said that, you are using Xen 3.4 which is ages out of date, and in fact, probably using XenServer 5.6SP2 (so shouldn't be using xen-devel anyway).

It is quite an old yet stable host with trusted guests. I wanted more information about Xen stack traces and whats the best way to read them hence sent on the list.

Current crash did not generate a core dump, hence I tried crashdump analyzer from xenbits.xen.org on other core dumps but that fails with

INFO Elf CORE crash file: /tmp/core.kdump.1405

ERROR Unexpected class 1

ERROR Failed to parse the crash file

in xen-crashdump-analyser.log.

There is a reason I threw kdump away and wrote the crashdump analyser; It would crash all over the place. That crash file is from the kdump utility, not from Xen. The crashdump analyser will not be able to parse it.

~Andrew