From: Sami Liedes <sami.liedes@iki.fi>
To: Jan Schmidt <list.btrfs@jan-o-sch.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs GPF in read_extent_buffer() while scrubbing with kernel 3.4.2
Date: Fri, 6 Jul 2012 17:33:51 +0300 [thread overview]
Message-ID: <20120706143350.GA10427@sli.dy.fi> (raw)
In-Reply-To: <4FF6C12A.10305@jan-o-sch.net>
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]
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).
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.
Sami
------------------------------------------------------------
btrfs: disk space caching is enabled
BUG: unable to handle kernel NULL pointer dereference at 0000000000000150
IP: [<ffffffffa0223568>] check_node+0x138/0x250 [btrfs]
PGD 0
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
CPU 6
Modules linked in: <omitted> [last unloaded: scsi_wait_scan]
Pid: 1176, comm: btrfs-endio-met Tainted: G W 3.4.4+btrfsdebug2 #2 System Product Name/P8P67 EVO
RIP: 0010:[<ffffffffa0223568>] [<ffffffffa0223568>] check_node+0x138/0x250 [btrfs
[...]
Process btrfs-endio-met (pid: 1176, [...])
Call trace:
[...] btree_readpage_end_io_hook+0x1e5/0x2d0 [btrfs]
[...] end_bio_extent_readpage+0xcb/0xa30 [btrfs]
[...] ? end_workqueue_fn+0x31/0x50 [btrfs]
[...] bio_endio+0x18/0x30
[...] end_workqueue_fn+0x3c/0x50 [btrfs]
[...] worker_loop+0x157/0x560 [btrfs]
[...] ? btrfs_queue_worker+0x310/0x310 [btrfs]
[...] kthead+0x8e/0xa0
[...] kernel_thread_helper+0x4/0x10
[...] ? flush_kthread_worker+0x70/0x70
[...] ? gs_change+0x13/0x13
Code: [...]
RIP [<ffffffffa0223568>] check_node+0x138/0x250 [btrfs]
RSP <ffff8801f3843cb0>
------------------------------------------------------------
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-07-06 14:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-02 23:01 btrfs GPF in read_extent_buffer() while scrubbing with kernel 3.4.2 Sami Liedes
2012-07-02 23:08 ` Sami Liedes
2012-07-03 13:11 ` Jan Schmidt
2012-07-03 13:58 ` Sami Liedes
2012-07-03 14:35 ` Jan Schmidt
2012-07-03 22:47 ` Sami Liedes
2012-07-04 0:17 ` Sami Liedes
2012-07-04 11:26 ` Jan Schmidt
2012-07-04 16:03 ` Sami Liedes
2012-07-04 16:38 ` Jan Schmidt
2012-07-04 20:24 ` Sami Liedes
2012-07-05 13:41 ` Jan Schmidt
2012-07-05 23:47 ` Sami Liedes
2012-07-06 10:42 ` Jan Schmidt
2012-07-06 11:50 ` Chris Mason
2012-07-06 14:33 ` Sami Liedes [this message]
2012-07-06 14:40 ` Chris Mason
2012-07-06 15:02 ` Jan Schmidt
2012-07-06 15:19 ` Chris Mason
2012-07-06 15:09 ` Jan Schmidt
[not found] ` <20120706195923.GA10687@sli.dy.fi>
2012-07-06 21:41 ` Sami Liedes
2012-07-06 23:44 ` Sami Liedes
2012-07-09 9:05 ` *** GMX Spamverdacht *** " Arne Jansen
2012-07-10 4:16 ` Sami Liedes
2012-07-10 6:05 ` Arne Jansen
2012-07-10 6:57 ` *** GMX Spamverdacht *** " Arne Jansen
2012-07-16 8:20 ` Arne Jansen
2012-07-16 21:29 ` Sami Liedes
2012-07-28 12:08 ` Sami Liedes
2012-07-28 18:50 ` Sami Liedes
2012-07-03 13:14 ` Sami Liedes
2013-03-27 11:54 ` Stefan Behrens
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=20120706143350.GA10427@sli.dy.fi \
--to=sami.liedes@iki.fi \
--cc=linux-btrfs@vger.kernel.org \
--cc=list.btrfs@jan-o-sch.net \
/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).