Bug 19152

Summary:	Can't read from usb-storage after swsusp
Product:	Drivers	Reporter:	Andrey Rahmatullin (wrar)
Component:	USB	Assignee:	Greg Kroah-Hartman (greg)
Status:	CLOSED UNREPRODUCIBLE
Severity:	normal	CC:	florian, maciej.rutecki, rjw, stern
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.36-rc5	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	7216, 16444

Description Andrey Rahmatullin 2010-09-27 12:16:18 UTC

I have an USB HDD with some mounted partitions. I hibernate using swsusp and resume. Now the device is unavailable though there is no error messages in dmesg. Reads from /dev/sdd just block and ls for a mounted directory is blocked in the following path:

[ 1800.553697] ls            D c0252908     0 11582   7435 0x00000000
[ 1800.553704]  f1446cd4 00200082 f1446c90 c0252908 f0a3e280 f0a3e4f0 f0a3e4ec c04f2ec0
[ 1800.553713]  c04f2ec0 f0a3e4ec c04f2ec0 c04f2ec0 c04f2ec0 c851f8fc 00000176 c84ff43d
[ 1800.553722]  00000176 f0a3e280 00000001 f0a3e280 c3408ec0 f1446d24 f1446ce4 c035e3db
[ 1800.553731] Call Trace:
[ 1800.553743]  [<c0252908>] ? kobject_put+0x37/0x3c
[ 1800.553750]  [<c035e3db>] io_schedule+0x5a/0x93
[ 1800.553758]  [<c01b984c>] sync_buffer+0x33/0x37
[ 1800.553762]  [<c035e7b1>] __wait_on_bit+0x34/0x5b
[ 1800.553767]  [<c01b9819>] ? sync_buffer+0x0/0x37
[ 1800.553773]  [<c01b9819>] ? sync_buffer+0x0/0x37
[ 1800.553777]  [<c035e873>] out_of_line_wait_on_bit+0x9b/0xa3
[ 1800.553786]  [<c01401fc>] ? wake_bit_function+0x0/0x37
[ 1800.553791]  [<c01b97e1>] __wait_on_buffer+0x19/0x1c
[ 1800.553817]  [<f947a9a5>] ext4_find_entry+0x2f5/0x462 [ext4]
[ 1800.553826]  [<c0125dea>] ? dequeue_task+0xaa/0xb9
[ 1800.553832]  [<c035f807>] ? _raw_spin_unlock_irq+0x15/0x20
[ 1800.553838]  [<c0146a85>] ? ktime_get_ts+0xc0/0xca
[ 1800.553844]  [<c035f7e7>] ? _raw_spin_unlock_irqrestore+0x16/0x21
[ 1800.553862]  [<f947ab3a>] ext4_lookup+0x28/0xb6 [ext4]
[ 1800.553869]  [<c01a5255>] d_alloc_and_lookup+0x3f/0x56
[ 1800.553874]  [<c01a533a>] do_lookup+0x94/0xcb
[ 1800.553880]  [<c01a6b2f>] link_path_walk+0x231/0x358
[ 1800.553885]  [<c01a6d1d>] path_walk+0x50/0xb0
[ 1800.553890]  [<c01a6e53>] do_path_lookup+0x21/0x6f
[ 1800.553895]  [<c01a766a>] user_path_at+0x39/0x5f
[ 1800.553901]  [<c0185811>] ? __do_fault+0x377/0x3a3
[ 1800.553908]  [<c02a389c>] ? tty_ioctl+0x3d4/0x6b6
[ 1800.553914]  [<c017a22e>] ? lru_cache_add_lru+0x22/0x24
[ 1800.553921]  [<c01a143f>] vfs_fstatat+0x2d/0x54
[ 1800.553926]  [<c018691d>] ? handle_mm_fault+0x9db/0xa02
[ 1800.553932]  [<c01a14aa>] vfs_lstat+0x16/0x18
[ 1800.553937]  [<c01a14c0>] sys_lstat64+0x14/0x28
[ 1800.553944]  [<c011b652>] ? do_page_fault+0x1e4/0x242
[ 1800.553949]  [<c011b680>] ? do_page_fault+0x212/0x242
[ 1800.553955]  [<c035fbec>] syscall_call+0x7/0xb

This is latest Linus tree (32163f4b2cef28a5aab8b226ffecfc6379a53786). There was no such thing in .35 or earlier kernels. I can bisect this if needed.

Comment 1 Greg Kroah-Hartman 2010-09-27 21:28:14 UTC

On Mon, Sep 27, 2010 at 12:16:21PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> This is latest Linus tree (32163f4b2cef28a5aab8b226ffecfc6379a53786). There
> was
> no such thing in .35 or earlier kernels. I can bisect this if needed.

bisection would be wonderful, could you please do that?

Comment 2 Andrey Rahmatullin 2010-09-30 07:16:44 UTC

I tried, but unfortunately I can't reproduce this anymore even with kernels that surely had this behavior.

Comment 3 Rafael J. Wysocki 2010-10-03 21:01:21 UTC

Closing as unreproducible.  Please reopen if you can reproduce again.