[Btrfs-devel] OOPs on ppc/2.6.20-16-powerpc ?

[Chris Mason]

On Tuesday 11 March 2008, Miguel Figueiredo Mascarenhas Sousa Filipe wrote:
> On Sun, Mar 2, 2008 at 3:29 AM, Yan Zheng <yanzheng at 21cn.com> wrote:
> > 2008/3/2, Miguel Figueiredo Mascarenhas Sousa Filipe 
<miguel.filipe at gmail.com>:
> > > I'm playing with btrfs-unstable (hg tip reports: e4cd88595ed7) on ppc,
> > >
> >  >  and I've caught this on dmesg...:
> >  >
> >  >  [71240.543144] ------------[ cut here ]------------
> >  >  [71240.543157] Badness at
> >  > /home/miguel/code/btrfs-unstable/extent-tree.c:1293 [71240.543164]
> >  > Call Trace:
> >  >  [71240.543169] [D047F9A0] [C0008BB0] show_stack+0x3c/0x194
> >  > (unreliable) [71240.543200] [D047F9D0] [C01103E4] report_bug+0x84/0xf4
> >  >  [71240.543217] [D047F9E0] [C0011ED4]
> >  > program_check_exception+0xd4/0x520 [71240.543238] [D047FA30]
> >  > [C0013B4C] ret_from_except_full+0x0/0x4c [71240.543250] --- Exception:
> >  > 700 at __free_extent+0x618/0x69c [btrfs] [71240.543371]     LR =
> >  > __free_extent+0x618/0x69c [btrfs]
> >  >  [71240.543377] [D047FBA0] [EAA16BF4] btrfs_free_extent+0xcc/0x158
> >  > [btrfs] [71240.543398] [D047FBF0] [EAA05D44]
> >  > __btrfs_cow_block+0x1358/0x1428 [btrfs] [71240.543419] [D047FC80]
> >  > [EAA05FC4] btrfs_cow_block+0x1b0/0x2c0 [btrfs] [71240.543438]
> >  > [D047FCC0] [EAA10C68] btrfs_search_slot+0x165c/0x2844 [btrfs]
> >  > [71240.543459] [D047FDD0] [EAA11EE8]
> >  > btrfs_insert_empty_items+0x98/0x91c [btrfs] [71240.543479] [D047FE40]
> >  > [EAA127C4] btrfs_insert_item+0x58/0xc0 [btrfs] [71240.543499]
> >  > [D047FE70] [EAA1E9E8] btrfs_insert_root+0x14/0x24 [btrfs]
> >  > [71240.543520] [D047FE80] [EAA262C0] add_dirty_roots+0x24c/0x434
> >  > [btrfs] [71240.543543] [D047FEF0] [EAA26708]
> >  >  btrfs_commit_transaction+0x260/0x658 [btrfs]
> >  >  [71240.543565] [D047FF40] [EAA26BC8]
> >  > btrfs_transaction_cleaner+0xc8/0xf8 [btrfs] [71240.543587] [D047FF50]
> >  > [C0042408] run_workqueue+0xb4/0x174 [71240.543611] [D047FF70]
> >  > [C0042D0C] worker_thread+0x150/0x17c [71240.543620] [D047FFC0]
> >  > [C0046968] kthread+0xc0/0xfc
> >  >  [71240.543633] [D047FFF0] [C0014434] kernel_thread+0x44/0x60
> >  >  [71240.543661] Unable to find ref byte nr 36864 root 1  gen 0 owner 0
> >  > offset 0 [72207.530342] btrfs: dm-5 checksum verify failed on 4116480
> >  > wanted 46D4996A found 1E2B503D from_this_trans 0
> >  >  [72260.415833] btrfs: dm-5 checksum verify failed on 4411392 wanted
> >  >  D681AA75 found 46BD8FEE from_this_trans 0
> >  >  [72263.184305] btrfs: dm-5 checksum verify failed on 4427776 wanted
> >  >  7735BEE8 found 759BDF50 from_this_trans 0
> >  >  [72266.003313] btrfs: dm-5 checksum verify failed on 4444160 wanted
> >  >  AC8E3D13 found F36AA813 from_this_trans 0
> >  >  [72269.549965] btrfs: dm-5 checksum verify failed on 4476928 wanted
> >  >  5BA0B00D found 41B349C8 from_this_trans 0
> >  >
> >  >  the checksum errors don't seem endianess problems...
> >
> >  The warning at extent-tree.c:1293 is due to a endian problem in
> >  btrfs-progs v0.13. you can use btrfs-progs v0.12 to create the
> >  filesystem.
>
> Should I provide a patch to fix v0.13 ?

Please do.

>
> >  The checksum verify failed message is due to a race.
> >  http://oss.oracle.com/pipermail/btrfs-users/2008-January/000032.html
>
> Is a fix for this attainable by btrfs amateurs like me? Any hints
> about the best approach to fix this?

The real fix for the race is more fine grained locking in the btree.  I'll 
start on that after the multi-device code is done.

-chris