[lkml]   [2000]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BUG]: Ext2 Corruption in test10pre3 (incl. Oops)

On Tue, 17 Oct 2000, Udo A. Steinberg wrote:

> Kernel bug at ll_rw_blk.c: 713!

unmapped buffer got to the ll_rw_block()

> Trace; c0184d53 <ll_rw_block+163/1e0>
> Trace; c012fa31 <bread+31/70>

What? <thinking> OK, so we got a unmapped bh hashed at some point.
Either it was inserted into hash while it was unmapped or it had been
hashed and then unmapped. The latter could happen only if
block_flushpage() got a bh associated with page _and_ sitting in the hash.
That, in turn, means insertion of page-bound bh into hash at some
earlier point. IOW, __insert_into_queues() had been called on unmapped or
page-bound bh. That returns us to getblk(). OK, unmapped is out of
question and page-bound means that we got a page-bound bh on a freelist.
Very bad. And I don't believe that it's fs-related. Frankly, I don't see
where such thing might happen.

> Trace; c014efde <read_inode_bitmap+3e/90>
> Trace; c014f240 <load_inode_bitmap+210/230>
> Trace; c014f6af <ext2_new_inode+29f/700>
> Trace; c021e87e <unix_write_space+2e/50>
> Trace; c01523af <ext2_create+1f/c0>

The rest of trace is OK, but WTF is net/unix/*.c code is doing here?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.149 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site