lkml.org 
[lkml]   [2005]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: How to interpret a kernel bug output from dmesg?
On Fri, 7 Oct 2005 17:53:34 -0700 Joshua Hudson wrote:

> I got this. Probably I caused it. Kernel is 2.6.13, slightly modified
> (weird new psuedo filesystem).
> Problem is I don't know how to read it. I wouldn't recommend looking
> for it yourself: I doubt
> you will find anything.
> Yes, I compiled with DEBUG_DCACHE (or something similar, uncommented the
> debug define at the top of dcache.c). I ran dmesg -c just before the ls that
> crashed, and dmesg right afterwards. Nothing else present.

Begin by looking at Documentation/oops-tracing.txt in the kernel tree.

> ------------[ cut here ]------------
> kernel BUG at include/linux/dcache.h:294!
* Kernel did a BUG_ON() at that spot. ~~~~~

> invalid operand: 0000 [#1]
* That's what BUG_ON() causes.

> PREEMPT
* A few of the kernel config options are listed here...

> Modules linked in:
* You have no loadable modules loaded (or you edited this part :).

> CPU: 0
* processor ID

> EIP: 0060:[<c0160723>] Not tainted VLI
* instruction pointer (selector:offset) + kernel is not tainted and
instructions use Variable Length Instructions.

> EFLAGS: 00010246 (2.6.13c1)
* processor eflags register + kernel version

> EIP is at __link_path_walk+0xd03/0xe60
* Code that called the inline dget() that did the BUG_ON() is here.

> eax: 00000000 ebx: ce054014 ecx: 00000001 edx: cdd392fc
> esi: ce1b7000 edi: ce1ffecc ebp: ce1b7f10 esp: ce1b7e24
* processor "general purpose" registers

> ds: 007b es: 007b ss: 0068
* processor selector registers

> Process ls (pid: 258, threadinfo=ce1b7000 task=ce2eaae0)
* current process

> Stack: 00000001 ce1b7e50 ce1b7e48 cdd392fc ce1b7e5c ce1b7e54 c02ac704 00000000
> 00000000 cfee48c0 ce1ffecc 00017c88 00000002 ce054012 c0169a73 ce1b7f10
> ce1b7f50 ce1b7ebc ce1b7e7c c01608c7 ce00b294 ce054000 ce00b294 cfee48c0
* raw kernel stack at time of trap

> Call Trace:
> [<c0169a73>] dput+0x33/0x280
> [<c01608c7>] link_path_walk+0x47/0xe0
> [<c0160c1c>] path_lookup+0x8c/0x160
> [<c0160eb3>] __user_walk+0x33/0x60
> [<c015ae9c>] vfs_lstat+0x1c/0x60
> [<c015b5cb>] sys_lstat64+0x1b/0x40
> [<c016416d>] sys_fcntl+0x2d/0x60
> [<c0102ab5>] syscall_call+0x7/0xb
* call stack at time of trap (this is just a lookup of raw stack addresses
into kernel symbols)

> Code: 2a ff 02 89 55 00 b8 01 00 00 00 e8 78 de fa ff 8b 46 08 a8 08
> 75 0d 89 3c 24 e8 29 93 00 00 e9 75 ff ff ff e8 8f 22 11 00 eb ec <0f>
> 0b 26 01 8e e6 27 c0 eb cc e8 7e 22 11 00 e9 97 fe ff ff 8b
* Next instructions that would be executed (i.e., where EIP points to).

> <6>note: ls[258] exited with preempt_count 1
* This is usually not good. The preempt logic should balance
number of entries/exits but something has mucked it up.

---
~Randy
-
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/

\
 
 \ /
  Last update: 2005-10-08 05:09    [W:0.120 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site