2000-10-30 17:16:25

by Mikael Pettersson

[permalink] [raw]
Subject: 2.2.18pre15 oops in find_buffer()

Is there any known bug in 2.2.18pre15 that could cause the
following oops in fs/buffer.c:find_buffer() ?

=== snip ===
ksymoops 0.7c on i586 2.2.18pre15. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.18pre15/ (default)
-m /boot/System.map-2.2.18pre15 (specified)

Unable to handle kernel paging request at virtual address 80000000
current->tss.cr3 = 01a29000, %cr3 = 01a29000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0125ef6>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 80000000 ebx: 00000004 ecx: 00006ec2 edx: 80000000
esi: 0000000a edi: 00000305 ebp: 000a4fc1 esp: c350de4c
ds: 0018 es: 0018 ss: 0018
Process fgrep (pid: 13207, process nr: 39, stackpage=c350d000)
Stack: 00000000 00000400 00006ec2 c0125f2f 00000305 000a4fc1 00001000 c0126c2c
00000305 000a4fc1 00001000 0000287a c246e3cc 00000000 c350deec 00000305
00000000 c114a7e0 c114a900 00000000 000a4fc1 c0139c2a c114a900 00002879
Call Trace: [<c0125f2f>] [<c0126c2c>] [<c0139c2a>] [<c0126f12>] [<c011c99a>] [<c011cd29>] [<c011d0b7>]
[<c011d00c>] [<c0124a9e>] [<c0109eb4>]
Code: 8b 12 39 68 04 75 f3 8b 4c 24 20 39 48 08 75 ea 66 39 78 0c

>>EIP; c0125ef6 <find_buffer+6a/8c> <=====
Trace; c0125f2f <get_hash_table+17/24>
Trace; c0126c2c <brw_page+128/334>
Trace; c0139c2a <ext2_bmap+66/80>
Trace; c0126f12 <generic_readpage+86/94>
Trace; c011c99a <try_to_read_ahead+ee/104>
Trace; c011cd29 <do_generic_file_read+299/57c>
Trace; c011d0b7 <generic_file_read+5b/74>
Trace; c011d00c <file_read_actor+0/50>
Trace; c0124a9e <sys_read+ae/c4>
Trace; c0109eb4 <system_call+34/40>
Code; c0125ef6 <find_buffer+6a/8c>
00000000 <_EIP>:
Code; c0125ef6 <find_buffer+6a/8c> <=====
0: 8b 12 mov (%edx),%edx <=====
Code; c0125ef8 <find_buffer+6c/8c>
2: 39 68 04 cmp %ebp,0x4(%eax)
Code; c0125efb <find_buffer+6f/8c>
5: 75 f3 jne fffffffa <_EIP+0xfffffffa> c0125ef0 <find_buffer+64/8c>
Code; c0125efd <find_buffer+71/8c>
7: 8b 4c 24 20 mov 0x20(%esp,1),%ecx
Code; c0125f01 <find_buffer+75/8c>
b: 39 48 08 cmp %ecx,0x8(%eax)
Code; c0125f04 <find_buffer+78/8c>
e: 75 ea jne fffffffa <_EIP+0xfffffffa> c0125ef0 <find_buffer+64/8c>
Code; c0125f06 <find_buffer+7a/8c>
10: 66 39 78 0c cmp %di,0xc(%eax)
=== snip ===

The instruction that failed is the "next = tmp->b_next" statement in
fs/buffer.c:find_buffer(). From the edx register, we see that "tmp"
(struct buffer_head *) got the value 0x80000000, an invalid pointer.

This happended after 16 days uptime with 2.2.18pre15. Any attempt to
read() a large file would die with the above oops.

memtest86 finds nothing wrong with the memory modules.
The machine seems fine after a reboot and upgrade to 2.2.18pre18.

/Mikael


2000-10-30 17:52:08

by adrian

[permalink] [raw]
Subject: Re: 2.2.18pre15 oops in find_buffer()


I also just got this Oops, but with 2.2.18pre18.

Note: vmware was not loaded :)


Unable to handle kernel paging request at virtual address 009e0000
current->tss.cr3 = 108e5000, %cr3 = 108e5000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0125f1c>]
EFLAGS: 00010206
eax: 009e0000 ebx: 00000007 ecx: 000189d0 edx: 009e0000
esi: 0000000d edi: 00000307 ebp: 002a00a9 esp: c7a97e60
ds: 0018 es: 0018 ss: 0018
Process enlightenment (pid: 5551, process nr: 75, stackpage=c7a97000)
Stack: 00000004 c3885860 000189d0 c0125f5b 00000307 002a00a9 00000400 c0126c50
00000307 002a00a9 00000400 00000000 c7a97f18 00000004 c6330288 c7a97ea4
c7a97ed8 d0ebd000 00000307 00000000 c3885860 00000010 c01431df c6330288
Call Trace: [<c0125f5b>] [<c0126c50>] [<c01431df>] [<c0126f45>] [<c011cb20>] [<c011cc8f>] [<c011cbdc>]
[<c0124a66>] [<c0109044>]
Code: 8b 00 39 6a 04 75 15 8b 4c 24 20 39 4a 08 75 0c 66 39 7a 0c

>>EIP; c0125f1c <find_buffer+68/90> <=====
Trace; c0125f5b <get_hash_table+17/24>
Trace; c0126c50 <brw_page+14c/36c>
Trace; c01431df <ext2_bmap+1b/84>
Trace; c0126f45 <generic_readpage+81/90>
Trace; c011cb20 <do_generic_file_read+52c/5e8>
Trace; c011cc8f <generic_file_read+63/7c>
Trace; c011cbdc <file_read_actor+0/50>
Trace; c0124a66 <sys_read+ae/c4>
Trace; c0109044 <system_call+34/38>
Code; c0125f1c <find_buffer+68/90>
00000000 <_EIP>:
Code; c0125f1c <find_buffer+68/90> <=====
0: 8b 00 mov (%eax),%eax <=====
Code; c0125f1e <find_buffer+6a/90>
2: 39 6a 04 cmp %ebp,0x4(%edx)
Code; c0125f21 <find_buffer+6d/90>
5: 75 15 jne 1c <_EIP+0x1c> c0125f38 <find_buffer+84/90>
Code; c0125f23 <find_buffer+6f/90>
7: 8b 4c 24 20 mov 0x20(%esp,1),%ecx
Code; c0125f27 <find_buffer+73/90>
b: 39 4a 08 cmp %ecx,0x8(%edx)
Code; c0125f2a <find_buffer+76/90>
e: 75 0c jne 1c <_EIP+0x1c> c0125f38 <find_buffer+84/90>
Code; c0125f2c <find_buffer+78/90>
10: 66 39 7a 0c cmp %di,0xc(%edx)

On Mon, 30 Oct 2000, Mikael Pettersson wrote:

> Is there any known bug in 2.2.18pre15 that could cause the
> following oops in fs/buffer.c:find_buffer() ?
>


Regards,
Adrian