All of lore.kernel.org
 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 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.