Messages in this thread | | | Subject | Re: 2.5.44: How to decode call trace | From | Olaf Dietsche <olaf.dietsche#> | Date | Wed, 23 Oct 2002 12:33:25 +0200 |
| |
Andi Kleen <ak@suse.de> writes:
> Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de> writes: >> 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.
>> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |