Re: v2.1.48: OOPS! while "ls"

Linus Torvalds (torvalds@transmeta.com)
7 Aug 1997 19:17:58 GMT


In article <XFMail.970807190159.mccramer@solfire.ludwigsburg.netsurf.de>,
Meino Christian Cramer <mccramer@solfire.ludwigsburg.netsurf.de> wrote:
>
>I have got an OOPS with kernel 2.1.48.
>
>It happens after compiling. Suddenly there was
>no access to an specific part of an path anymore.
>It does not harm the filesystem (until now...)

What filesystems do you have in use?

>And now the oops-code from the syslog file
>
>Aug 7 17:07:03 solfire kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000004f
>Aug 7 17:07:03 solfire kernel: current->tss.cr3 = 01bc7000, <r3 = 01bc7000
>Aug 7 17:07:03 solfire kernel: *pde = 00000000
>Aug 7 17:07:03 solfire kernel: Oops: 0000
>Aug 7 17:07:03 solfire kernel: CPU: 0
>Aug 7 17:07:03 solfire kernel: EIP: 0010:[<c01296b6>]
>Aug 7 17:07:03 solfire kernel: EFLAGS: 00010286
>Aug 7 17:07:03 solfire kernel: eax: c1964660 ebx: c17c9300 ecx: 00000000 edx: ffffffff
>Aug 7 17:07:03 solfire kernel: esi: c1964660 edi: c1e5cd40 ebp: c1e5cd40 esp: c0d2df1c
>Aug 7 17:07:03 solfire kernel: ds: 0018 es: 0018 ss: 0018
>Aug 7 17:07:03 solfire kernel: Process ls (pid: 1209, process nr: 20, stackpage=c0d2d000)
>Aug 7 17:07:03 solfire kernel: Stack: c17c9300 c1964660 c1f8e00e c0129843 c1e5cd40 c1964660 c17c9300 000001b6
>Aug 7 17:07:03 solfire kernel: 00000001 000081a4 a7810601 c1f8e002 0000000c a7810634 c0129933 c1f8e000
>Aug 7 17:07:03 solfire kernel: 00000000 00000001 c17c9300 000001b6 c1f8e000 000001b6 c01a7ae0 40006000
>Aug 7 17:07:03 solfire kernel: Call Trace: [<c0129843>] [<c0129933>] [<c01221cf>] [<c0122383>] [<c010944a>]
>Aug 7 17:07:03 solfire kernel: Code: 8b 42 50 85 c0 74 5d 83 78 2c 00 74 57 89 e0 89 c3 81 e3 00
>
>Using `System.map' to map addresses to symbols.
>
>>>EIP: c01296b6 <do_follow_link+12/88>
>Trace: c0129843 <lookup_dentry+117/14c>
>Trace: c0129933 <open_namei+3f/2b0>
>Trace: c01221cf <do_open+4b/134>
>Trace: c0122383 <sys_open+3b/6c>
>Trace: c010944a <system_call+3a/40>
>
>Code: c01296b6 <do_follow_link+12/88>
>Code: c01296b6 <do_follow_link+12/88> 8b 42 50 movl 0x50(%edx),%eax

This is "inode->i_ops". And the "inode" pointer is "-1".

>Code: c01296b9 <do_follow_link+15/88> 85 c0 testl %eax,%eax
>Code: c01296bb <do_follow_link+17/88> 74 5d je c012971a <do_follow_link+76/88>
>Code: c01296bd <do_follow_link+19/88> 83 78 2c 00 cmpl $0x0,0x2c(%eax)
>Code: c01296c7 <do_follow_link+23/88> 74 57 je c012971a <do_follow_link+76/88>
>Code: c01296c9 <do_follow_link+25/88> 89 e0 movl %esp,%eax
>Code: c01296cb <do_follow_link+27/88> 89 c3 movl %eax,%ebx
>Code: c01296cd <do_follow_link+29/88> 81 e3 00 00 90 andl $0x90900000,%ebx
>Code: c01296d8 <do_follow_link+34/88> 90
>Code: c01296d9 <do_follow_link+35/88> 90 nop
>
>>>EIP: c01296b6 <do_follow_link+12/88>
>Trace: c0129843 <lookup_dentry+117/14c>
>Trace: c0129933 <open_namei+3f/2b0>
>Trace: c01221cf <do_open+4b/134>
>Trace: c0122383 <sys_open+3b/6c>
>Trace: c010944a <system_call+3a/40>
>
>If I can give more informations or help in other
>ways, please mail me.

This looks like a buggy low-level filesystem filling in buggy inode
information into the dcache. That's why I'd like to know what
filesystems you have, and preferably what you were doing at that point
("ls", obviously, but in which directory? What is the "correct" output
of "ls -l" in that directory, and what filesystem is it?)

Linus