mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Roger Leigh <rleigh@whinlatter.ukfsn.org>
Cc: linux-kernel@vger.kernel.org, linux-usb-devel@lists.sourceforge.net
Subject: Re: BUG: 2.6.14/2.6.15: USB storage/ext2fs uninterruptable sleep
Date: Thu, 5 Jan 2006 05:41:06 -0800	[thread overview]
Message-ID: <20060105054106.2d4076bc.akpm@osdl.org> (raw)
In-Reply-To: <87zmmbt1ce.fsf@hardknott.home.whinlatter.ukfsn.org>

Roger Leigh <rleigh@whinlatter.ukfsn.org> wrote:
>
> Hi folks,
> 
> I use a USB storage device (Kingston 128 MiB keydrive) to hold GPG
> keys, which is automounted with autofs4.  It's looking like a write
> operation on the device (so far always involving an ext2_delete_inode
> up to sync_buffer) causes the process to hang in an uninterruptable
> sleep.
> 
> The system is running stock kernel.org linux-2.6.15 and 2.6.14.5 on a
> PowerPC 7447A system (Mac Mini) running Debian unstable.  The .config
> is here: http://www.whinlatter.ukfsn.org/config-2.6.15-hardknott.bz2
> 
> For example:
> # cd /misc/pen-secure/.gnupg
> # rm secring.gpg.lock pubring.gpg.lock pubring.gpg.tmp
> 
> 7818 pts/1    D+     0:00 rm secring.gpg.lock pubring.gpg.lock pubring.gpg.tmp
> 
> rm            D 0FF35634     0  7818   7196                   (NOTLB)
> Call trace:
>  [c0007524] __switch_to+0x54/0x6c
>  [c0287c28] schedule+0x584/0x634
>  [c0287d08] io_schedule+0x30/0x60
>  [c006be78] sync_buffer+0x50/0x64
>  [c0288854] __wait_on_bit_lock+0x60/0xc0
>  [c0288928] out_of_line_wait_on_bit_lock+0x74/0x88
>  [c006b33c] __lock_buffer+0x3c/0x4c
>  [c006c570] sync_dirty_buffer+0x58/0x130
>  [e2eef13c] ext2_xattr_delete_inode+0x1bc/0x278 [ext2]
>  [e2ee8324] ext2_free_inode+0x38/0x27c [ext2]
>  [e2eeb0a8] ext2_delete_inode+0x8c/0xac [ext2] [c00863b0] generic_delete_inode+0x104/0x17c
>  [c0085450] iput+0x9c/0xb0
>  [c007b09c] sys_unlink+0x124/0x180
>  [c00046dc] ret_from_syscall+0x0/0x44
> 
> I have had the same with the entry point being sys_rename:
> 
> [gpg --recv-key ...]
> 
> gpg           D 0F6D76B4     0 19099   3976 19103               (NOTLB)
> Call trace:
>  [c0007524] __switch_to+0x54/0x6c
>  [c0287c28] schedule+0x584/0x634
>  [c0287d08] io_schedule+0x30/0x60
>  [c006be78] sync_buffer+0x50/0x64
>  [c0288854] __wait_on_bit_lock+0x60/0xc0
>  [c0288928] out_of_line_wait_on_bit_lock+0x74/0x88
>  [c006b33c] __lock_buffer+0x3c/0x4c
>  [c006c570] sync_dirty_buffer+0x58/0x130
>  [e2eaf13c] ext2_xattr_delete_inode+0x1bc/0x278 [ext2]
>  [e2ea8324] ext2_free_inode+0x38/0x27c [ext2]
>  [e2eab0a8] ext2_delete_inode+0x8c/0xac [ext2] [c00863b0] generic_delete_inode+0x104/0x17c
>  [c0085450] iput+0x9c/0xb0
>  [c0083b14] dput+0x234/0x264
>  [c007b908] sys_rename+0x168/0x1c4
> 
> I can write other files to the device without trouble, but it's
> clearly getting stuck somewhere inside the kernel.  In all the times
> it's happened so far, eventually pdflush will subsequently go into D
> state, and it's downhill from there (I can't unmount the filesystems
> properly, and shutdown also hangs, so have to use Alt-SysRq to remount
> readonly and reboot).
> 
> The device is using usb-storage, rather than ub:
> $ cat /proc/partitions |grep sda
>    8     0     125952 sda
>    8     1      97776 sda1
>    8     2      28160 sda2
> 
> 
> I'll be happy to provide any additional details or do any further
> testing.
> 

I'd say that usb-storage is failing to send back I/O completions.

  parent reply	other threads:[~2006-01-05 13:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-05 10:29 Roger Leigh
2006-01-05 13:39 ` Roger Leigh
2006-01-05 13:41 ` Andrew Morton [this message]
2006-01-05 15:59   ` Roger Leigh
2006-01-05 16:45     ` [linux-usb-devel] " Alan Stern
2006-01-05 17:39       ` Roger Leigh
2006-01-05 19:00         ` Alan Stern
2006-01-05 19:28           ` Roger Leigh
2006-01-05 16:50     ` Ian Kent

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=20060105054106.2d4076bc.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=rleigh@whinlatter.ukfsn.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

all inboxes | Powered by JetHome®