From: Marc MERLIN <marc@merlins.org>
To: Chris Mason <clm@fb.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: 3.16.2 btrfs deadlock
Date: Tue, 7 Oct 2014 16:45:13 -0700 [thread overview]
Message-ID: <20141007234513.GC20416@merlins.org> (raw)
In-Reply-To: <1412716972.2374.1@mail.thefacebook.com>
On Tue, Oct 07, 2014 at 05:22:52PM -0400, Chris Mason wrote:
> >Here's the trace:
> >SysRq : Show Blocked State
> > task PC stack pid father
> >md8_raid5 D ffff88017028cb80 0 675 2 0x00000000
> > ffff88020fd67aa8 0000000000000046 ffffffff812f1799 ffff88020fd67fd8
> > ffff880037228410 00000000000140c0 ffff88021e3940c0 ffff880037228410
> > ffff8801f5579bf0 0000000000000004 ffff880211ad07c8 ffff88020fd67ab8
> >Call Trace:
> > [<ffffffff812f1799>] ? blk_flush_plug_list+0x1bc/0x1cb
> > [<ffffffff8163a889>] schedule+0x6e/0x70
> > [<ffffffff8163aa2b>] io_schedule+0x60/0x7a
> > [<ffffffff812ef8f6>] get_request+0x4b8/0x56a
> > [<ffffffff8130ba01>] ? cfq_merge+0x49/0x9e
> > [<ffffffff81087b70>] ? finish_wait+0x65/0x65
> > [<ffffffff812f1921>] blk_queue_bio+0x179/0x262
> > [<ffffffff812eec2c>] generic_make_request+0x9c/0xdb
> > [<ffffffffc042b31d>] handle_stripe+0x1e41/0x2166 [raid456]
> > [<ffffffff81017316>] ? ___preempt_schedule+0x56/0xa8
> > [<ffffffff8163d0d9>] ? _raw_spin_unlock_irqrestore+0x1f/0x32
> > [<ffffffffc042b925>] handle_active_stripes.isra.22+0x2e3/0x359
> >[raid456]
> > [<ffffffff8151d35e>] ? md_wakeup_thread+0x55/0x58
> > [<ffffffffc042bdd6>] raid5d+0x330/0x428 [raid456]
> > [<ffffffff810795b1>] ? get_parent_ip+0xd/0x3c
> > [<ffffffff815202f9>] md_thread+0x11c/0x13a
> > [<ffffffff81087b70>] ? finish_wait+0x65/0x65
> > [<ffffffff815201dd>] ? bb_store+0x55/0x55
> > [<ffffffff8106e3a9>] kthread+0xae/0xb6
> > [<ffffffff8106e2fb>] ? __kthread_parkme+0x61/0x61
> > [<ffffffff8163d8fc>] ret_from_fork+0x7c/0xb0
> > [<ffffffff8106e2fb>] ? __kthread_parkme+0x61/0x61
>
> This trace shows we're stuck somewhere different from the 3.15
> stalls. md is waiting for a request, and unfortunately those are
> outside of btrfs completely. It's likely that if you had let it
> sit, the box would have eventually dig its way out.
Thanks for having a look.
I didn't actually reboot it, it deadlocked and hit a CPU stuck watchdog
and self rebooted.
But as long as it's not btrfs, then that's good :)
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
prev parent reply other threads:[~2014-10-07 23:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-05 20:29 3.16.2 btrfs deadlock Marc MERLIN
2014-10-05 23:16 ` 3.16.2 btrfs deadlock -> detecting deadlocks with cron Marc MERLIN
2014-10-07 21:22 ` 3.16.2 btrfs deadlock Chris Mason
2014-10-07 23:45 ` Marc MERLIN [this message]
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=20141007234513.GC20416@merlins.org \
--to=marc@merlins.org \
--cc=clm@fb.com \
--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 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).