linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Karl Mardoff Kittilsen <karl@kittilsen.org>, linux-btrfs@vger.kernel.org
Subject: Re: kernel BUG at /build/buildd/linux-3.2.0/fs/btrfs/extent-tree.c:4816!
Date: Tue, 29 Nov 2011 13:12:14 -0500	[thread overview]
Message-ID: <20111129181214.GO24338@shiny> (raw)
In-Reply-To: <20111129164746.GN12759@twin.jikos.cz>

On Tue, Nov 29, 2011 at 05:47:46PM +0100, David Sterba wrote:
> On Tue, Nov 29, 2011 at 10:49:13AM -0500, Chris Mason wrote:
> > The good news about this one is that it is very clear cut.  The hard
> > part is figuring out where these bogus link counts came from.
> > 
> > I'd suggest that you spend some time running memtest on the machine.
> 
> Just to add some evidence from the log:
> 
> Nov 28 00:11:14 karl-workstation kernel: [212918.235050] kernel BUG at
> /home/apw/COD/linux/fs/btrfs/extent-tree.c:4775!
> Nov 28 00:11:14 karl-workstation kernel: [212918.235118] RAX:
> 00000000ea000001 RBX: ffff880412c3ab40 RCX: ffff880380173900
> ^^^^^^^^^^^^^^^^
> 
> 4765                         ret = btrfs_search_slot(trans, extent_root,
> 4766                                                 &key, path, -1, 1);
> 4767                         if (ret) {
> 4768                                 printk(KERN_ERR "umm, got %d back from search"
> 4769                                        ", was looking for %llu\n", ret,
> 4770                                        (unsigned long long)bytenr);
> 4771                                 if (ret > 0)
> 4772                                         btrfs_print_leaf(extent_root,
> 4773                                                          path->nodes[0]);
> 4774                         }
> 4775                         BUG_ON(ret);
> 
> the ret value comes from btrfs_search_slot, returning " < 0" or 1, but
> RAX has some extra bits set, this could really be a RAM failure.
> 
> 
> david

Interesting, look at this:

> karl@karl-precise:~/git/btrfs-progs$ sudo ./btrfsck /dev/md0
> ref mismatch on [2176962560 8192] extent item 480, found 1
> Incorrect local backref count on 2176970752 root 5 owner 2101705
> offset 368640 found 1 wanted 3925868545
> backpointer mismatch on [2176970752 4096]

3925868545 == EA000001

Are you sure this is the BUG_ON he was triggering?

-chris


  reply	other threads:[~2011-11-29 18:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29  1:39 kernel BUG at /build/buildd/linux-3.2.0/fs/btrfs/extent-tree.c:4816! Karl Mardoff Kittilsen
2011-11-29 15:12 ` Chris Mason
2011-11-29 15:29   ` Karl Mardoff Kittilsen
2011-11-29 15:49     ` Chris Mason
2011-11-29 16:47       ` David Sterba
2011-11-29 18:12         ` Chris Mason [this message]
2011-12-15  0:01           ` David Sterba

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=20111129181214.GO24338@shiny \
    --to=chris.mason@oracle.com \
    --cc=karl@kittilsen.org \
    --cc=linux-btrfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).