Skip to contentSkip to conversation

2.4.4 Kernel Oops and ls+rm segfaults

DISCUSSION Gregor Jasny 2 participants 3 messages Jun 1, 2001

lore
Share & tools
lore
#0 lore raw

Hi!

Can anyone tell me, where this oops came from?
The machine is a HP NetServer II lc (EISA+PCI architecture). The distribution is a slackware 7.0 with parts of 7.1 and current.
gcc: 2.95.4 20010319 (Debian prerelease)

I hope you can help me.

Regards,

-Gregor

ksymoops 2.4.1 on i586 2.4.4-csfddi. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.4-csfddi/ (default) -m /boot/System.map-2.4.4-csfddi (specified)

Unable to handle kernel paging request at virtual address c936d300
c0122d8c
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c0122d8c>]

Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010087
eax: 338b95ef ebx: 01f954ba ecx: c1518000 edx: 00000023
esi: c119fcdc edi: 00000202 ebp: c105be90 esp: c1ea1ec4
ds: 0018 es: 0018 ss: 0018
Process rm (pid: 3877, stackpage=c1ea1000)

Stack: c1518ba0 c1518360 c150dbc0 c105be90 c012e3d9 c119fcdc c1518ba0 c150dbc0 
       00001000 c150dbc0 00001000 00000000 00000001 c012ce08 c105be90 00000000 
       c105be90 000011c0 c5d264c4 00000000 c011d9fe c105be90 00000000 c1ea1f48 
Call Trace: [<c012e3d9>] [<c012ce08>] [<c011d9fe>] [<c011dacc>] [<c013dda6>] [<c013c398>] [<c0136194>] 
       [<c013626b>] [<c858b8cc>] [<c0106ac3>] 
Code: 89 44 99 18 89 59 14 8b 56 14 8b 41 10 ff 49 10 39 d0 74 08 
Quoted 1 line
Quoted 1 line

EIP; c0122d8c <kmem_cache_free+38/ac> <=====

Trace; c012e3d9 <try_to_free_buffers+c1/15c>
Trace; c012ce08 <block_flushpage+70/94>
Trace; c011d9fe <truncate_list_pages+f6/184>
Trace; c011dacc <truncate_inode_pages+40/6c>
Trace; c013dda6 <iput+96/15c>
Trace; c013c398 <d_delete+4c/6c>
Trace; c0136194 <vfs_unlink+114/144>
Trace; c013626b <sys_unlink+a7/11c>
Trace; c858b8cc <END_OF_CODE+1d48788/????>
Trace; c0106ac3 <system_call+33/40>
Code; c0122d8c <kmem_cache_free+38/ac>
0000000000000000 <_EIP>:
Code; c0122d8c <kmem_cache_free+38/ac> <=====
0: 89 44 99 18 mov %eax,0x18(%ecx,%ebx,4) <=====
Code; c0122d90 <kmem_cache_free+3c/ac>
4: 89 59 14 mov %ebx,0x14(%ecx)
Code; c0122d93 <kmem_cache_free+3f/ac>
7: 8b 56 14 mov 0x14(%esi),%edx
Code; c0122d96 <kmem_cache_free+42/ac>
a: 8b 41 10 mov 0x10(%ecx),%eax
Code; c0122d99 <kmem_cache_free+45/ac>
d: ff 49 10 decl 0x10(%ecx)
Code; c0122d9c <kmem_cache_free+48/ac>
10: 39 d0 cmp %edx,%eax
Code; c0122d9e <kmem_cache_free+4a/ac>
12: 74 08 je 1c <_EIP+0x1c> c0122da8 <kmem_cache_free+54/ac>

#1 lore raw
Quoted 8 lines · Gregor Jasny

Hi!

Can anyone tell me, where this oops came from?
The machine is a HP NetServer II lc (EISA+PCI architecture). The distribution is a slackware 7.0 with parts of 7.1 and current.
gcc: 2.95.4 20010319 (Debian prerelease)

I hope you can help me.

Pagecache corruption somewhere.
a) what filesystems do you have?
b) is the thing reproducable?

#2 lore raw

Am Freitag, 1. Juni 2001 10:52 schrieb Alexander Viro:

Quoted 10 lines · Gregor Jasny
Quoted 5 lines

Can anyone tell me, where this oops came from?
The machine is a HP NetServer II lc (EISA+PCI architecture). The distribution is a slackware 7.0 with parts of 7.1 and current.
gcc: 2.95.4 20010319 (Debian prerelease)

Pagecache corruption somewhere.
a) what filesystems do you have?
b) is the thing reproducable?

a) pure ext2-fs (sometimes a mounted nfs)
b) Not really. It happend with earlier kernel revisions, too.

I alredy replaced the fs-utils and compiled the kernel at my workstation (with gcc-2.95.3)

If it matters: we have the Compushack FDDI driver installed. It can be found
at: http://hell.wh8.tu-dresden.de/~gjadm/csfddi-3.0.0-5.diff.gz

Regards,
-Gregor