In accordance to the mail from
PSI-Systems [EMAIL PROTECTED]
Wed, 29 Dec 2004 21:50:21 +0100
I too have regular kernel oopses, after which the afs filesystem hasn't
become unreachable, but using it does result in segmentation faults and
more kernel oopses (seeing a "rm" command resulting in segmentation fault
IS scary).
I run a gentoo stable, kernel 2.6.9-gentoo-r1, openafs 1.3.77. My box is
a Pentium II celeron 300a.
Stefaan
ksymoops 2.4.9 on i686 2.6.9-gentoo-r1. Options used
-V (default)
-K (specified)
-l /proc/modules (default)
-o /lib/modules/2.6.9-gentoo-r1/ (default)
-m /usr/src/linux/System.map (default)
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address ffffffff
e9134f91
*pde = 00002067
Oops: 0002 [#1]
CPU: 0
EIP: 0060:[<e9134f91>] Tainted: P VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286 (2.6.9-gentoo-r1)
eax: 00000021 ebx: e9063a80 ecx: c0345ccc edx: c0345ccc
esi: e9076f80 edi: 00001094 ebp: 00000003 esp: dbb35f40
ds: 007b es: 007b ss: 0068
Stack: e9153f44 00000004 e9135eef 00000003 e9135dfc e9153f44 00000004 e9135eef
00000003 00002148 00001ba4 e9076f80 00000000 e913582a e9076f80 00001ba4
00000003 00000002 e7fd2ec0 00000000 00000000 ae5e040a db975080 e9076f80
Call Trace:
[<e9135eef>] rxi_AllocDataBuf+0x2f/0x70 [libafs]
[<e9135dfc>] allocCBuf+0x6c/0xd0 [libafs]
[<e9135eef>] rxi_AllocDataBuf+0x2f/0x70 [libafs]
[<e913582a>] rxk_ReadPacket+0x5a/0x140 [libafs]
[<e9135969>] rxk_Listener+0x59/0x1a0 [libafs]
[<e9146064>] afsd_thread+0x474/0x480 [libafs]
[<e9145bf0>] afsd_thread+0x0/0x480 [libafs]
[<c01042cd>] kernel_thread_helper+0x5/0x18
Code: 15 e9 8b 54 24 14 85 d2 0f 44 d0 8b 44 24 20 89 14 24 89 44 24 0c 8b 44
24 1c 89 44 24 08 8b 44 24 18 89 44 24 04 e8 ff 71 fe d6 <c6> 05 ff ff ff ff 2a
83 c4 10 c3 8d 74 26 00 55 b8 ff ff ff ff
>>EIP; e9134f91 <pg0+28d1bf91/3fbe5400> <=====
>>ebx; e9063a80 <pg0+28c4aa80/3fbe5400>
>>ecx; c0345ccc <log_wait+0/8>
>>edx; c0345ccc <log_wait+0/8>
>>esi; e9076f80 <pg0+28c5df80/3fbe5400>
>>esp; dbb35f40 <pg0+1b71cf40/3fbe5400>
Trace; e9135eef <pg0+28d1ceef/3fbe5400>
Trace; e9135dfc <pg0+28d1cdfc/3fbe5400>
Trace; e9135eef <pg0+28d1ceef/3fbe5400>
Trace; e913582a <pg0+28d1c82a/3fbe5400>
Trace; e9135969 <pg0+28d1c969/3fbe5400>
Trace; e9146064 <pg0+28d2d064/3fbe5400>
Trace; e9145bf0 <pg0+28d2cbf0/3fbe5400>
Trace; c01042cd <kernel_thread_helper+5/18>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; e9134f66 <pg0+28d1bf66/3fbe5400>
00000000 <_EIP>:
Code; e9134f66 <pg0+28d1bf66/3fbe5400>
0: 15 e9 8b 54 24 adc $0x24548be9,%eax
Code; e9134f6b <pg0+28d1bf6b/3fbe5400>
5: 14 85 adc $0x85,%al
Code; e9134f6d <pg0+28d1bf6d/3fbe5400>
7: d2 0f rorb %cl,(%edi)
Code; e9134f6f <pg0+28d1bf6f/3fbe5400>
9: 44 inc %esp
Code; e9134f70 <pg0+28d1bf70/3fbe5400>
a: d0 8b 44 24 20 89 rorb 0x89202444(%ebx)
Code; e9134f76 <pg0+28d1bf76/3fbe5400>
10: 14 24 adc $0x24,%al
Code; e9134f78 <pg0+28d1bf78/3fbe5400>
12: 89 44 24 0c mov %eax,0xc(%esp)
Code; e9134f7c <pg0+28d1bf7c/3fbe5400>
16: 8b 44 24 1c mov 0x1c(%esp),%eax
Code; e9134f80 <pg0+28d1bf80/3fbe5400>
1a: 89 44 24 08 mov %eax,0x8(%esp)
Code; e9134f84 <pg0+28d1bf84/3fbe5400>
1e: 8b 44 24 18 mov 0x18(%esp),%eax
Code; e9134f88 <pg0+28d1bf88/3fbe5400>
22: 89 44 24 04 mov %eax,0x4(%esp)
Code; e9134f8c <pg0+28d1bf8c/3fbe5400>
26: e8 ff 71 fe d6 call d6fe722a <_EIP+0xd6fe722a>
This decode from eip onwards should be reliable
Code; e9134f91 <pg0+28d1bf91/3fbe5400>
00000000 <_EIP>:
Code; e9134f91 <pg0+28d1bf91/3fbe5400> <=====
0: c6 05 ff ff ff ff 2a movb $0x2a,0xffffffff <=====
Code; e9134f98 <pg0+28d1bf98/3fbe5400>
7: 83 c4 10 add $0x10,%esp
Code; e9134f9b <pg0+28d1bf9b/3fbe5400>
a: c3 ret
Code; e9134f9c <pg0+28d1bf9c/3fbe5400>
b: 8d 74 26 00 lea 0x0(%esi),%esi
Code; e9134fa0 <pg0+28d1bfa0/3fbe5400>
f: 55 push %ebp
Code; e9134fa1 <pg0+28d1bfa1/3fbe5400>
10: b8 ff ff ff ff mov $0xffffffff,%eax
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000004
e9130c8f
*pde = 00000000
Oops: 0000 [#2]
CPU: 0
EIP: 0060:[<e9130c8f>] Tainted: P VLI
EFLAGS: 00010282 (2.6.9-gentoo-r1)
eax: 00000002 ebx: 00000000 ecx: 00000020 edx: e36081e0
esi: 00000000 edi: e7fd2ec0 ebp: e7fd2ec8 esp: dbacdf3c
ds: 007b es: 007b ss: 0068
Stack: e9141e98 e916fc40 000001f5 00000000 00000000 db529aa0 c01187c0 00000001
00000000 00000000 de98c800 e36081e0 00000000 db529aa0 c01187c0 c010bada
de98c06c e7c9bb20 e7c9bb2c dbacdfd0 e91348c4 de98c06c e7fd2ec0 00000000
Call Trace:
[<e9141e98>] osi_TimedSleep+0xc8/0x120 [libafs]
[<c01187c0>] default_wake_function+0x0/0x20
[<c01187c0>] default_wake_function+0x0/0x20
[<c010bada>] do_gettimeofday+0x1a/0xd0
[<e91348c4>] rxevent_RaiseEvents+0x94/0x1c0 [libafs]
[<e9135738>] afs_rxevent_daemon+0x18/0xb0 [libafs]
[<e9145f7f>] afsd_thread+0x38f/0x480 [libafs]
[<e9145bf0>] afsd_thread+0x0/0x480 [libafs]
[<c01042cd>] kernel_thread_helper+0x5/0x18
Code: 0c 66 89 47 76 39 dd 8b 73 04 0f 84 28 fa ff ff f6 83 c4 00 00 00 01 75
0e c7 43 0c 00 00 00 00 c7 43 08 00 00 00 00 89 f3 39 dd <8b> 76 04 75 e0 e9 03
fa ff ff 0f b7 c1 e9 77 ff ff ff b8 02 00
>>EIP; e9130c8f <pg0+28d17c8f/3fbe5400> <=====
>>edx; e36081e0 <pg0+231ef1e0/3fbe5400>
>>edi; e7fd2ec0 <pg0+27bb9ec0/3fbe5400>
>>ebp; e7fd2ec8 <pg0+27bb9ec8/3fbe5400>
>>esp; dbacdf3c <pg0+1b6b4f3c/3fbe5400>
Trace; e9141e98 <pg0+28d28e98/3fbe5400>
Trace; c01187c0 <default_wake_function+0/20>
Trace; c01187c0 <default_wake_function+0/20>
Trace; c010bada <do_gettimeofday+1a/d0>
Trace; e91348c4 <pg0+28d1b8c4/3fbe5400>
Trace; e9135738 <pg0+28d1c738/3fbe5400>
Trace; e9145f7f <pg0+28d2cf7f/3fbe5400>
Trace; e9145bf0 <pg0+28d2cbf0/3fbe5400>
Trace; c01042cd <kernel_thread_helper+5/18>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; e9130c64 <pg0+28d17c64/3fbe5400>
00000000 <_EIP>:
Code; e9130c64 <pg0+28d17c64/3fbe5400>
0: 0c 66 or $0x66,%al
Code; e9130c66 <pg0+28d17c66/3fbe5400>
2: 89 47 76 mov %eax,0x76(%edi)
Code; e9130c69 <pg0+28d17c69/3fbe5400>
5: 39 dd cmp %ebx,%ebp
Code; e9130c6b <pg0+28d17c6b/3fbe5400>
7: 8b 73 04 mov 0x4(%ebx),%esi
Code; e9130c6e <pg0+28d17c6e/3fbe5400>
a: 0f 84 28 fa ff ff je fffffa38 <_EIP+0xfffffa38>
Code; e9130c74 <pg0+28d17c74/3fbe5400>
10: f6 83 c4 00 00 00 01 testb $0x1,0xc4(%ebx)
Code; e9130c7b <pg0+28d17c7b/3fbe5400>
17: 75 0e jne 27 <_EIP+0x27>
Code; e9130c7d <pg0+28d17c7d/3fbe5400>
19: c7 43 0c 00 00 00 00 movl $0x0,0xc(%ebx)
Code; e9130c84 <pg0+28d17c84/3fbe5400>
20: c7 43 08 00 00 00 00 movl $0x0,0x8(%ebx)
Code; e9130c8b <pg0+28d17c8b/3fbe5400>
27: 89 f3 mov %esi,%ebx
Code; e9130c8d <pg0+28d17c8d/3fbe5400>
29: 39 dd cmp %ebx,%ebp
This decode from eip onwards should be reliable
Code; e9130c8f <pg0+28d17c8f/3fbe5400>
00000000 <_EIP>:
Code; e9130c8f <pg0+28d17c8f/3fbe5400> <=====
0: 8b 76 04 mov 0x4(%esi),%esi <=====
Code; e9130c92 <pg0+28d17c92/3fbe5400>
3: 75 e0 jne ffffffe5 <_EIP+0xffffffe5>
Code; e9130c94 <pg0+28d17c94/3fbe5400>
5: e9 03 fa ff ff jmp fffffa0d <_EIP+0xfffffa0d>
Code; e9130c99 <pg0+28d17c99/3fbe5400>
a: 0f b7 c1 movzwl %cx,%eax
Code; e9130c9c <pg0+28d17c9c/3fbe5400>
d: e9 77 ff ff ff jmp ffffff89 <_EIP+0xffffff89>
Code; e9130ca1 <pg0+28d17ca1/3fbe5400>
12: b8 .byte 0xb8
Code; e9130ca2 <pg0+28d17ca2/3fbe5400>
13: 02 00 add (%eax),%al
