public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Robert Hancock <hancockrwd@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Jens Axboe <jens.axboe@oracle.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: 2.6.32-rc4ish: task umount blocked for more than 120 seconds after USB drive removal
Date: Tue, 3 Nov 2009 15:18:12 -0800	[thread overview]
Message-ID: <20091103151812.2acc5259.akpm@linux-foundation.org> (raw)
In-Reply-To: <4ADE9B79.9090906@gmail.com>

On Tue, 20 Oct 2009 23:26:17 -0600
Robert Hancock <hancockrwd@gmail.com> wrote:

> Running a post-2.6.32-rc4 git kernel, and just unmounted a USB drive 
> after writing a bunch of data to it, then pulled the plug after I 
> thought it had finished unmounting, but apparently it hadn't.. Ran into 
> a hung task warning that repeats every 120 seconds, the umount command 
> for the drive is stuck in D state.
> 
> The full SysRq-T output is shown at the bottom.. any ideas what it's 
> waiting for?

At a guess I'd say the new per-bdi writeback stuff blew up.  Is this
still happening in current mainline?

> Oct 20 21:42:42 newcastle kernel: usb 1-1.6: USB disconnect, address 5
> Oct 20 21:42:42 newcastle gnome-keyring-daemon[2598]: removing removable 
> location: volume_uuid_01E0_9221
> Oct 20 21:45:26 newcastle kernel: INFO: task umount:5380 blocked for 
> more than 120 seconds.
> Oct 20 21:45:26 newcastle kernel: "echo 0 > 
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Oct 20 21:45:26 newcastle kernel: umount        D 0000000000000002     0 
>   5380   2853 0x00000080
> Oct 20 21:45:26 newcastle kernel: ffff880118651bc8 0000000000000086 
> ffff880118651b68 00000000d54e0b08
> Oct 20 21:45:26 newcastle kernel: 00000000000004f1 ffff88013bbd9798 
> ffff8800282558b0 ffff880118651fd8
> Oct 20 21:45:26 newcastle kernel: ffff880118651fd8 ffff8800504cb280 
> 000000000000fb38 0000000000015840
> Oct 20 21:45:26 newcastle kernel: Call Trace:
> Oct 20 21:45:26 newcastle kernel: [<ffffffff8117d534>] ? 
> bdi_sched_wait+0x0/0x39

It's remarkable how much harder these traces are to read post-wordwrapping.

  reply	other threads:[~2009-11-03 23:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-21  5:26 2.6.32-rc4ish: task umount blocked for more than 120 seconds after USB drive removal Robert Hancock
2009-11-03 23:18 ` Andrew Morton [this message]
2009-11-04  7:41   ` Jens Axboe

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=20091103151812.2acc5259.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=hancockrwd@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    /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