On Fri, July 06, 2012 at 16:33 (+0200), Sami Liedes wrote:
> On Fri, Jul 06, 2012 at 12:42:50PM +0200, Jan Schmidt wrote:
>> I've no good idea at the moment how to go on. It might help to get a feeling 
>> if
>> it's shifting around at least a little bit or really constant in the timing 
>> of
>> occurrence. So can you please apply the next patch on top of the other two 
>> and
>> give it some more failure tries? The "checksum mismatch [1234]" line will be 
>> of
>> most interest. I'm also curious what the additional debug variables will say 
>> in
>> the extended version of the very first printk. You can leave out the stack
>> traces if you like, they won't matter much anyway.
> 
> Ok. Also turned on CONFIG_DEBUG_PAGEALLOC and CONFIG_SLUB_DEBUG_ON as
> suggested by Chris Mason.
> 
> With those and the latest patch, there's an oops already at boot. I
> don't have netconsole yet at that point, but here's the important
> parts (sure I can capture it fully if you need).

Oh I see. root->node can be NULL during mount. Please add this on top:

--
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index df0b347..22838a3 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -578,7 +578,8 @@ static noinline int check_node(struct btrfs_root *root,
        }
        node->debug[5] = node->start;
        node->debug[6] = btrfs_header_level(node);
-       node->debug[6] |= btrfs_header_level(root->node) << 16;
+       if (root->node)
+               node->debug[6] |= btrfs_header_level(root->node) << 16;
        node->debug[7] = 0xb22f50b22f5;

        return 0;
--


> By the way, something seems to be untabifying your patches. I don't
> know if it's on my side or yours, but at least some other patches I
> receive via linux-btrfs contain tabs. Doing a M-x tabify in emacs
> mostly makes them apply cleanly for me.

Oh, I'm sorry. Should have been on my side. I hope it's better with the current
diff?

-Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to