Re: 2.5.44: How to decode call trace

Andi Kleen [off-list ref] writes:

Olaf Dietsche <olaf.dietsche#list.linux-kernel-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org> writes:

quoted

and this is the code:
static int __fscap_lookup(struct vfsmount *mnt, struct nameidata *nd)
{
	static char name[] = ".capabilities";
	nd->mnt = mntget(mnt);
	nd->dentry = dget(mnt->mnt_sb->s_root);
	nd->flags = 0;
	return path_walk(name, nd);
}

What does .text.lock.namei and name.810 mean?

.text.lock.namei means that it hung in the slow path of a spinlock that
is referenced from namei.c

I guess this is what __down_failed means.

name.810 is a static data variable, probably the static char name[]
shown above. Remember the kernel backtrace is not exact and can print
random stack junk that looks like return addresses too. You always have 
to sanity check each entry.

Ok, I'll keep that in mind.

quoted

Is there a way to get the line number out of these hex values?

addr2line -e vmlinux ... does this when you compile the kernel with -g 

Great! This is what I was searching for.

When I build with "make -k EXTRA_CFLAGS=-g EXTRA_LDFLAGS=-g bzImage",
I get a ton of error messages from drivers/acpi/include/actypes.h and
other acpi related stuff, starting with: #error ACPI_MACHINE_WIDTH not
defined. Maybe this is not the usual way to build with -g, but I don't
get these errors with "make -k bzImage". Maybe someone is interested
in this.

Anyway, I come around this by first building with "EXTRA_CFLAGS=-g
EXTRA_LDFLAGS=-g", ignoring the error messages and then a second try
with only EXTRA_LDFLAGS=-g.

Regards, Olaf.