lkml.org 
[lkml]   [2009]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: XFS kernel BUG at fs/buffer.c:470! with 2.6.28.4
  Argh, forgot the patch...

> > On Tue, 2009-02-10 at 21:43 +1100, Dave Chinner wrote:
> > > On Mon, Feb 09, 2009 at 02:53:08AM -0500, Christoph Hellwig wrote:
> > > > On Sun, Feb 08, 2009 at 11:45:20PM +0100, Alessandro Bono wrote:
> > > > > sure, attached
> > > >
> > > > That would be a missing PagePrivate bit in page_buffers() called from
> > > > end_buffer_async_write. PG_private can only be cleared via drop_buffers
> > > > which requires the page not having PG_writeback set which must be
> > > > set until end_buffer_async_write is done. Very strange, and all this
> > > > is generic code without xfs involvement. Did this happen once
> > > > or can you reproduce it?
> > >
> > > Hmmmm - i wonder if this has anything to do with the writeback fixes
> > > that went into 2.6.28.2? Alessandro, can you revert to 2.6.28.1 (not
> > > plain 2.6.28) and see if you can reproduce the problem?
> >
> > another test another bug
> > kernel 2.6.29-rc4-git4 with DEBUG_PAGEALLOC and CONFIG_DEBUG_LIST
> > enabled (idea taken from a totally unrelated mail from Ingo Molnar to
> > catch a memory corruption), usual bug attached
> > 2.6.27 from ubuntu not survived to rsync
> >
> > btw my first report of a similar problem was with a kernel 2.6.26.6 but
> > at time I was using binary driver for my radeon card and Christoph
> > suggest me that I have to recreate problem without any binary driver
> > maybe it's not a recent regression, it's simply easier to hit with a
> > newer kernel
> >
> > I don't have abandoned idea of a hardware problem but I don't know how
> > to be sure
> >
> > any suggestion?
> Hmm, are you still able to reproduce the problem? As I'm looking into
> registers in your dump, no register really seems to contain sensible page
> flags so it could be some corruption of page pointer. If you are still
> able to reproduce, could you please do so with the attached patch
> applied? It will dump us much more information... Thanks.
>
> Honza
>
> --
> Jan Kara <jack@suse.cz>
> SuSE CR Labs
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
From 289408c005dc2ffce2fb495bd5d76a4eeda9190a Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Thu, 26 Feb 2009 17:56:32 +0100
Subject: [PATCH] Add debuging info.

Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/buffer.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 9f69741..1d42c02 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -531,6 +531,14 @@ static void end_buffer_async_write(struct buffer_head *bh, int uptodate)
SetPageError(page);
}

+ if (!PagePrivate(page)) {
+ printk("Buffer %p of page %p not private! Some data to debug:\n", bh, page);
+ printk("flags: %lx, mapping: %p, index: %ld, private: %lx\n", page->flags, page->mapping, page->index, page->private);
+ printk("Buffer: state=%lx, block=%llu, b_size=%lu, b_this_page=%p\n", bh->b_state, (unsigned long long)bh->b_blocknr, (unsigned long)bh->b_size, bh->b_this_page);
+ printk("Other buffers in the page:\n");
+ for (tmp = bh->b_this_page; tmp != bh; tmp = tmp->b_this_page)
+ printk("Buffer %p: state=%lx, block=%llu, b_size=%lu, b_page=%p\n", tmp, tmp->b_state, (unsigned long long)tmp->b_blocknr, (unsigned long)tmp->b_size, tmp->b_page);
+ }
first = page_buffers(page);
local_irq_save(flags);
bit_spin_lock(BH_Uptodate_Lock, &first->b_state);
--
1.6.0.2
\
 
 \ /
  Last update: 2009-02-26 18:01    [W:0.092 / U:10.048 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site