All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Martin Diehl <lists@mdiehl.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.5.46: buffer layer error at fs/buffer.c:399
Date: Sun, 10 Nov 2002 16:53:14 -0800	[thread overview]
Message-ID: <3DCEFF7A.F7534A72@digeo.com> (raw)
In-Reply-To: Pine.LNX.4.44.0211101839380.1451-100000@notebook.home.mdiehl.de

Martin Diehl wrote:
> 
> Hi,
> 
> shortly after upgrading 2.5.45->2.5.46 I got this while cp'ing some
> regular file. Source and destination was both in rootfs, which is ext2.
> It's not exactly reproducible, however apparently triggered by files
> larger than about 500KB - at least I got a few with those but never from
> smaller one.
> 
> Despite this error/warning(?) the requested file was successfully copied
> (and diffed). A forced fsck on / didn't find any corruption. And it seems
> it doesn't occur if the target file exists, i.e. it's overwritten.
> 
> Kernel is 2.5.46 SMP running on UP box. The new extended attributes were
> not enabled for ext2.
> 
> Martin
> 
> -------------------
> 
> * this one was triggered by "cp file1 file2" (cwd=/root)
> 
> buffer layer error at fs/buffer.c:399
> Pass this trace through ksymoops for reporting
> Call Trace:
>  [<c0151db6>] __find_get_block_slow+0xe6/0x150
>  [<c0152ec6>] __find_get_block+0xd6/0xf0
>  [<c0153277>] unmap_underlying_metadata+0x17/0x50

This means that we had pagecache floating about which has buffers,
but those buffers had unexpected block numbers.  Possibly something
went wrong during an earlier invalidation of the device during the
mount process.  Do you remember if a fsck happened during that bootup?

Is there anything unusual about your setup?  Using initrd?  Is the
rootfs backed by a normal old disk?

Could I please see a `dumpe2fs -h' of that device?

Please, run with this patch and see if if happens again, thanks.


--- 25/fs/buffer.c~buffer-debug	Sun Nov 10 16:47:31 2002
+++ 25-akpm/fs/buffer.c	Sun Nov 10 16:49:59 2002
@@ -397,6 +397,9 @@ __find_get_block_slow(struct block_devic
 		bh = bh->b_this_page;
 	} while (bh != head);
 	buffer_error();
+	printk("block=%llu, b_blocknr=%llu\n",
+		(unsigned long long)block, (unsigned long long)bh->b_blocknr);
+	printk("b_state=0x%08lx, b_size=%u\n", bh->b_state, bh->b_size);
 out_unlock:
 	spin_unlock(&bd_mapping->private_lock);
 	page_cache_release(page);

_

  reply	other threads:[~2002-11-11  0:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-10 23:04 2.5.46: buffer layer error at fs/buffer.c:399 Martin Diehl
2002-11-11  0:53 ` Andrew Morton [this message]
2002-11-11 22:18   ` Martin Diehl

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=3DCEFF7A.F7534A72@digeo.com \
    --to=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists@mdiehl.de \
    /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.