I have the following call tree:
Oct 22 22:35:36 goat kernel: rm D 00000246 0 615 387 (NOTLB)
Oct 22 22:35:36 goat kernel: Call Trace:
Oct 22 22:35:36 goat kernel: [<c0105ebf>] __down+0x67/0xb8
Oct 22 22:35:36 goat kernel: [<c0112a5c>] default_wake_function+0x0/0x34
Oct 22 22:35:36 goat kernel: [<c0106034>] __down_failed+0x8/0xc
Oct 22 22:35:36 goat kernel: [<c0143601>] .text.lock.namei+0x5/0x174
Oct 22 22:35:36 goat kernel: [<c0140768>] do_lookup+0x9c/0x1bc
Oct 22 22:35:36 goat kernel: [<c0140dde>] link_path_walk+0x556/0x868
Oct 22 22:35:36 goat kernel: [<c015bedc>] ext2_commit_chunk+0x38/0x6c
Oct 22 22:35:36 goat kernel: [<e08696a9>] name.810+0xd/0x10 [fscaps]
Oct 22 22:35:36 goat kernel: [<c015bf09>] ext2_commit_chunk+0x65/0x6c
Oct 22 22:35:36 goat kernel: [<e086969c>] name.810+0x0/0x10 [fscaps]
Oct 22 22:35:36 goat kernel: [<c0141117>] path_walk+0x27/0x28
Oct 22 22:35:36 goat kernel: [<e086909f>] __fscap_lookup+0x3f/0x40 [fscaps]
Oct 22 22:35:36 goat kernel: [<e0869266>] fscap_drop_op+0x1a/0x5c [fscaps]
Oct 22 22:35:36 goat kernel: [<c01424de>] vfs_unlink+0x14e/0x178
Oct 22 22:35:36 goat kernel: [<c01425b2>] sys_unlink+0xaa/0x120
Oct 22 22:35:36 goat kernel: [<c0106d93>] syscall_call+0x7/0xb
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?
Is there a way to get the line number out of these hex values?
TIA
Regards, Olaf.
Olaf Dietsche <olaf.dietsche#[email protected]> 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
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.
> 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
-Andi
On Wed, Oct 23, 2002 at 05:50:41AM +0200, Andi Kleen wrote:
> > 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
Also interesting is http://ds9a.nl/symoops
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
Andi Kleen <[email protected]> writes:
> Olaf Dietsche <olaf.dietsche#[email protected]> 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.
On Wed, Oct 23, 2002 at 12:33:25PM +0200, Olaf Dietsche wrote:
> 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.
Not really. Users shouldn't be overriding EXTRA_CFLAGS, it's for the
benefit of various parts of the kernel. Some other parts of the kernel
you break by doing this:
./arch/i386/mach-generic/Makefile:EXTRA_CFLAGS += -I../kernel
./drivers/ide/pci/Makefile:EXTRA_CFLAGS := -Idrivers/ide
./drivers/message/fusion/Makefile:EXTRA_CFLAGS += ${MPT_CFLAGS}
./drivers/usb/storage/Makefile:EXTRA_CFLAGS := -Idrivers/scsi
./fs/smbfs/Makefile:EXTRA_CFLAGS += -DSMBFS_PARANOIA
./fs/xfs/Makefile:EXTRA_CFLAGS += -Ifs/xfs -funsigned-char
./sound/oss/emu10k1/Makefile: EXTRA_CFLAGS += -DEMU10K1_DEBUG
The normal way to do what you want is to edit the Makefile and add -g
directly to CFLAGS.
--
Revolutions do not require corporate support.
Matthew Wilcox <[email protected]> writes:
> The normal way to do what you want is to edit the Makefile and add -g
> directly to CFLAGS.
Ok, thanks.
Regards, Olaf.
bert hubert <[email protected]> writes:
> On Wed, Oct 23, 2002 at 05:50:41AM +0200, Andi Kleen wrote:
>
>> > 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
>
> Also interesting is http://ds9a.nl/symoops
This is a real shortcut. Thanks.
Regards, Olaf.