lkml.org 
[lkml]   [1998]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.1.125 oops
Eyal Lebedinsky wrote:
>
> Almost every night when updatedb runs I get this. It does not
> happen with 2.0 (up to 2.0.36p15)
> [trimmed]

Further to the above, tonight I had it crash running the ususal
securitycheck.
The exact command that failed (and is now stuck status D) is:

find / /uu/sda2 /data2 /uu/sdb2 /uu/hdb3 /d /e -xdev \( -type f -perm
+06000 -o
-type b -o -type c \) -printf "%8i %5m %3n %-10u %-10g %9s %t
%h/%f\012n"

The crash is probably in a loaded module (I do I get addresses for
these? The
kew ksymoops does not work for me).

I now see that the crash is when find scans an ntfs partition. Running
it by hand
puts the 'find' into D state (no oops).

I now managed to run the new ksymoops and stragely enough I find that
out
of all the modules loaded, ntfs is missing from '/proc/ksyms' while all
the rest
are there.

So here is the latest oops. I think the 'cleanup_module+...' is bogus.

--------------------------- ksymoops start
Options used: -v /lib/modules/2.1.125/vmlinux -o /lib/modules/2.1.125/
-k /proc/
ksyms -m /lib/modules/2.1.125/System.map
Unable to handle kernel NULL pointer dereference at virtual address
00000000
current->tss.cr3 = 02e4d000, %cr3 = 02e4d000 *pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c4852131>]
EFLAGS: 00010212
eax: 00000038 ebx: 00000000 ecx: 0000000e edx: 0000000e
esi: c1eb7300 edi: 00000000 ebp: 00000038 esp: c2507e24
ds: 0018 es: 0018 ss: 0018
Process find (pid: 3112, process nr: 45, stackpage=c2507000)
Stack: c1eb7300 c4852ca5 00000000 c1eb7300 00000038 c2507edc c0d566e0
c48539b2
c2507edc c1eb7300 00000038 c2507edc c0d566e0 00000000 c1226b00
00000003
c0d566e0 c4852c8c c485305f c1f01780 c1eb7300 00000004 c2507edc
00000200
Call Trace: [<c4852ca5>] [<c48539b2>] [<c4852c8c>] [<c485305f>]
[<c4853bd9>] [<c
4855acf>] [<c48588d0>]
[<c4852c8c>] [<c4855b48>] [<c4851a00>] [<c012ee54>] [<c012a737>]
[<c012a8
f6>] [<c012a9d1>] [<c012896b>]
[<c0108908>]
Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 89 d8 5b 5e 5f c3 55
>>EIP: c4852131 <cleanup_module+30ad/afc8>
Trace: c4852ca5 <cleanup_module+3c21/afc8>
Trace: c48539b2 <cleanup_module+492e/afc8>
Trace: c4852c8c <cleanup_module+3c08/afc8>
Trace: c485305f <cleanup_module+3fdb/afc8>
Trace: c4853bd9 <cleanup_module+4b55/afc8>
Trace: c4855acf <cleanup_module+6a4b/afc8>
Trace: c48588d0 <cleanup_module+984c/afc8>
Trace: c4852c8c <cleanup_module+3c08/afc8>
Trace: c4855b48 <cleanup_module+6ac4/afc8>
Trace: c4851a00 <cleanup_module+297c/afc8>
Trace: c012ee54 <d_alloc+38/180>
Trace: c012a737 <real_lookup+47/70>
Trace: c012a8f6 <lookup_dentry+112/1c4>
Trace: c012a9d1 <__namei+29/5c>
Trace: c012896b <sys_newlstat+13/64>
Trace: c0108908 <system_call+34/38>
Code: c4852131 <cleanup_module+30ad/afc8> 00000000 <_EIP>:
Code: c4852131 <cleanup_module+30ad/afc8> 0: f3 a5
repz mov
sl %ds:(%esi),%es:(%edi)
Code: c4852133 <cleanup_module+30af/afc8> 2: a8 02
testb $
0x2,%al
Code: c4852135 <cleanup_module+30b1/afc8> 4: 74 02
je 8
<_EIP+0x8> c4852139 <cleanup_module+30b5/afc8>
Code: c4852137 <cleanup_module+30b3/afc8> 6: 66 a5
movsw %
ds:(%esi),%es:(%edi)
Code: c4852139 <cleanup_module+30b5/afc8> 8: a8 01
testb $
0x1,%al
Code: c485213b <cleanup_module+30b7/afc8> a: 74 01
je d
<_EIP+0xd> c485213e <cleanup_module+30ba/afc8>
Code: c485213d <cleanup_module+30b9/afc8> c: a4
movsb %
ds:(%esi),%es:(%edi)
Code: c485213e <cleanup_module+30ba/afc8> d: 89 d8
movl %
ebx,%eax
Code: c4852140 <cleanup_module+30bc/afc8> f: 5b
popl %
ebx
Code: c4852141 <cleanup_module+30bd/afc8> 10: 5e
popl %
esi
Code: c4852142 <cleanup_module+30be/afc8> 11: 5f
popl %
edi
Code: c4852143 <cleanup_module+30bf/afc8> 12: c3
ret
Code: c4852144 <cleanup_module+30c0/afc8> 13: 55
pushl %
ebp
Code: c4852145 <cleanup_module+30c1/afc8> 14:

665 warnings issued. Results may not be reliable.
------------------------------- ksymoops end
--
Eyal Lebedinsky (eyal@eyal.emu.id.au)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans