From: Dave Hansen <haveblue@us.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@zip.com.au>, Alexander Viro <viro@math.psu.edu>
Subject: Oops on 2.5.6-pre2 in ext2 code
Date: Wed, 06 Mar 2002 18:26:12 -0800 [thread overview]
Message-ID: <3C86CFC4.6050800@us.ibm.com> (raw)
Andrew Morton was getting errors like this when running dbench:
__block_prepare_write: zeroing uptodate buffer!
http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.2/1585.html
His problems were on a uniproc machine, running a "dbench 64" on a
~120meg ext2 filesystem with 1k blocks. When running the same test on
my dual-proc machine, I always oops after a short period of time. The
presence of ext2_get_block in the trace seems to indicate that it could
be related to the recent ext2 locking changes in 2.5.
I haven't been able to reproduce the same errors in 2.4, even with the
ext2_get_block() BKL removal patch applied. It is probably influenced
by, but not caused exclusively by that patch from 2.5.
CPU: 0
EIP: 0010:[<c013b6c0>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: d695c080 ebx: c13e1bec ecx: d695c080 edx: 01010101
esi: c13e1bec edi: 00000400 ebp: 01000000 esp: d96d1eac
ds: 0018 es: 0018 ss: 0018
Stack: 0000000a c013b999 c13e1bec 00000400 00000000 d695c000 d96d1ed4
00000400
d6781b60 c013b056 d6781b60 c013bcb3 00000282 00001000 0001595c
00000282
c13e1bec 00001000 d56ed3c0 c13e1bec c013c251 d1cc3cd0 c13e1bec
00000000
Call Trace: [<c013b999>] [<c013b056>] [<c013bcb3>] [<c013c251>]
[<c015fc10>]
[<c012c6cb>] [<c015fc10>] [<c0138fa6>] [<c0114ac9>] [<c0108ce7>]
Code: c7 42 38 00 00 00 00 89 d1 8b 52 28 85 d2 75 f0 89 41 28 89
>>EIP; c013b6c0 <create_empty_buffers+30/50> <=====
Trace; c013b999 <__block_prepare_write+79/2e0>
Trace; c013b056 <balance_dirty+6/50>
Trace; c013bcb3 <__block_commit_write+b3/e0>
Trace; c013c251 <block_prepare_write+21/40>
Trace; c015fc10 <ext2_get_block+0/470>
Trace; c012c6cb <generic_file_write+4ab/710>
Trace; c015fc10 <ext2_get_block+0/470>
Trace; c0138fa6 <sys_write+96/110>
Trace; c0114ac9 <schedule+329/380>
Trace; c0108ce7 <syscall_call+7/b>
Code; c013b6c0 <create_empty_buffers+30/50>
00000000 <_EIP>:
Code; c013b6c0 <create_empty_buffers+30/50> <=====
0: c7 42 38 00 00 00 00 movl $0x0,0x38(%edx) <=====
Code; c013b6c7 <create_empty_buffers+37/50>
7: 89 d1 mov %edx,%ecx
Code; c013b6c9 <create_empty_buffers+39/50>
9: 8b 52 28 mov 0x28(%edx),%edx
Code; c013b6cc <create_empty_buffers+3c/50>
c: 85 d2 test %edx,%edx
Code; c013b6ce <create_empty_buffers+3e/50>
e: 75 f0 jne 0 <_EIP>
Code; c013b6d0 <create_empty_buffers+40/50>
10: 89 41 28 mov %eax,0x28(%ecx)
Code; c013b6d3 <create_empty_buffers+43/50>
--
Dave Hansen
haveblue@us.ibm.com
reply other threads:[~2002-03-07 2:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C86CFC4.6050800@us.ibm.com \
--to=haveblue@us.ibm.com \
--cc=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.