On Tue, Jul 03, 2012 at 03:11:04PM +0200, Jan Schmidt wrote:

quoted

The oops is transcribed from photos, so it may contain some errors. I

You did *what*? :-) Uploading a photo would be fine, just in case that's easier
for you the next time.

Nah, it's sometimes refreshing to do something that doesn't take too
much thinking for a while. Besides I fault myself for not having had
netconsole logging on that machine and needed to punish myself for
that omission ;)

That's looking strange.

I checked the readahead code again: It deliberately skips locking and uses
btrfs_node_key with a counter variable. This means, we might end up reading a
key that's no longer actually there. However, it only operates on nodes of
trees, not leaves. Node entries have a fixed size, so no matter what changes in
the node, you won't reach behind the end of that node with an index that was
valid the moment before.

As far as I see it, that algorithm is safe. It could miss some keys or do some
extra work that's not strictly required, but it should never reach a GPF from
btrfs_node_key.

If no other ideas come up, I'd try memtesting that machine.

Ran a full pass of memtest86+ v4.20, with no errors found. Also the
machine works very well in all other respects under heavy load.

I think I might try setting up that netconsole to see if there are any
interesting console messages before the oops... As I said, I also was
able to reproduce this on 3.4.4, so ATM I assume I'm able to reproduce
this at will.

	Sami