[OpenAFS-devel] Linux 2.6.12 kernel BUG at fs/namei.c:1189
Russ Allbery
rra@stanford.edu
Sat, 10 Dec 2005 12:09:09 -0800
Has anyone seen this before? I was moving a volume mount point using mv
and got a segfault from mv and the following kernel BUG message in dmesg
(which I've run through ksymoops).
Since then, every process that touchs the same directory in AFS has gone
into uninterruptable disk wait.
Let me know if there's any other information I can gather before I reboot
the system.
ksymoops 2.4.9 on i686 2.6.12-1-686. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.12-1-686/ (default)
-m /boot/System.map-2.6.12-1-686 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
kernel BUG at fs/namei.c:1189!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c016a0c0>] Tainted: P VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206 (2.6.12-1-686)
eax: d27f8c04 ebx: ffffffd9 ecx: e8f99244 edx: 00000001
esi: d2d0b780 edi: e638462c ebp: e8f991ec esp: d167fedc
ds: 007b es: 007b ss: 0068
Stack: 00000000 ffffffea cf56a000 e8609000 00000001 ffffffd9 cf56a000 e8609000
d167ff68 c016a3b3 d2d0b780 e638462c d2d0b780 e8f991ec e0ccdc04 e0ccdc04
e638462c e8f991ec 00000000 e0ccdc04 dfff4d80 8fc50770 00000014 e8609000
Call Trace:
[<c016a3b3>] sys_rename+0x1f3/0x230
[<c01627d8>] sys_lstat64+0x18/0x40
[<c01030c5>] syscall_call+0x7/0xb
Code: 44 24 30 f6 80 0c 01 00 00 04 0f 84 7b fd ff ff ba 04 00 00 00 89 54 24 04 89 04 24 e8 da e2 01 00 e9 4f fd ff ff 90 8d 74 26 00 <0f> 0b a5 04 53 a6 2b c0 e9 20 fd ff ff c7 04 24 03 00 00 00 e8
>>EIP; c016a0c0 <vfs_rename+320/420> <=====
>>eax; d27f8c04 <pg0+1243ec04/3fc44400>
>>ebx; ffffffd9 <__kernel_rt_sigreturn+1b99/????>
>>ecx; e8f99244 <pg0+28bdf244/3fc44400>
>>esi; d2d0b780 <pg0+12951780/3fc44400>
>>edi; e638462c <pg0+25fca62c/3fc44400>
>>ebp; e8f991ec <pg0+28bdf1ec/3fc44400>
>>esp; d167fedc <pg0+112c5edc/3fc44400>
Trace; c016a3b3 <sys_rename+1f3/230>
Trace; c01627d8 <sys_lstat64+18/40>
Trace; c01030c5 <syscall_call+7/b>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; c016a095 <vfs_rename+2f5/420>
00000000 <_EIP>:
Code; c016a095 <vfs_rename+2f5/420>
0: 44 inc %esp
Code; c016a096 <vfs_rename+2f6/420>
1: 24 30 and $0x30,%al
Code; c016a098 <vfs_rename+2f8/420>
3: f6 80 0c 01 00 00 04 testb $0x4,0x10c(%eax)
Code; c016a09f <vfs_rename+2ff/420>
a: 0f 84 7b fd ff ff je fffffd8b <_EIP+0xfffffd8b>
Code; c016a0a5 <vfs_rename+305/420>
10: ba 04 00 00 00 mov $0x4,%edx
Code; c016a0aa <vfs_rename+30a/420>
15: 89 54 24 04 mov %edx,0x4(%esp)
Code; c016a0ae <vfs_rename+30e/420>
19: 89 04 24 mov %eax,(%esp)
Code; c016a0b1 <vfs_rename+311/420>
1c: e8 da e2 01 00 call 1e2fb <_EIP+0x1e2fb>
Code; c016a0b6 <vfs_rename+316/420>
21: e9 4f fd ff ff jmp fffffd75 <_EIP+0xfffffd75>
Code; c016a0bb <vfs_rename+31b/420>
26: 90 nop
Code; c016a0bc <vfs_rename+31c/420>
27: 8d 74 26 00 lea 0x0(%esi),%esi
This decode from eip onwards should be reliable
Code; c016a0c0 <vfs_rename+320/420>
00000000 <_EIP>:
Code; c016a0c0 <vfs_rename+320/420> <=====
0: 0f 0b ud2a <=====
Code; c016a0c2 <vfs_rename+322/420>
2: a5 movsl %ds:(%esi),%es:(%edi)
Code; c016a0c3 <vfs_rename+323/420>
3: 04 53 add $0x53,%al
Code; c016a0c5 <vfs_rename+325/420>
5: a6 cmpsb %es:(%edi),%ds:(%esi)
Code; c016a0c6 <vfs_rename+326/420>
6: 2b c0 sub %eax,%eax
Code; c016a0c8 <vfs_rename+328/420>
8: e9 20 fd ff ff jmp fffffd2d <_EIP+0xfffffd2d>
Code; c016a0cd <vfs_rename+32d/420>
d: c7 04 24 03 00 00 00 movl $0x3,(%esp)
Code; c016a0d4 <vfs_rename+334/420>
14: e8 .byte 0xe8
1 warning and 1 error issued. Results may not be reliable.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>