lkml.org 
[lkml]   [2010]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: INFO: umount blocked for more than 120 seconds
Hello,

Robert Hancock added to Cc list.

First of all, let me describe hw (sorry for skipping this part in prev. email).
The device is ASUS p535 in a card reader mode. The card is 1Gb MiniSD (Kingston).


On (04/26/10 15:36), Alan Stern wrote:
> Is this repeatable?
>
Yes.

kernel: [14980.102019] usb 2-1: new full speed USB device using uhci_hcd and address 2
kernel: [14980.270773] usb 2-1: New USB device found, idVendor=0b05, idProduct=422f
kernel: [14980.270783] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: [14980.270790] usb 2-1: Product: Generic Mass Storage
kernel: [14980.270797] usb 2-1: Manufacturer: ASUS
kernel: [14980.270803] usb 2-1: SerialNumber: *********************************
kernel: [14980.273767] scsi3 : usb-storage 2-1:1.0
kernel: [14981.279875] scsi scan: INQUIRY result too short (5), using 36
kernel: [14981.279890] scsi 3:0:0:0: Direct-Access PQ: 0 ANSI: 0
kernel: [14981.289597] sd 3:0:0:0: Attached scsi generic sg2 type 0
kernel: [14981.301967] sd 3:0:0:0: [sdb] 2012160 512-byte logical blocks: (1.03 GB/982 MiB)
kernel: [14981.304760] sd 3:0:0:0: [sdb] Write Protect is off
kernel: [14981.304765] sd 3:0:0:0: [sdb] Mode Sense: 00 06 00 00
kernel: [14981.304768] sd 3:0:0:0: [sdb] Assuming drive cache: write through
kernel: [14981.316864] sd 3:0:0:0: [sdb] Assuming drive cache: write through
kernel: [14981.316877] sdb: sdb1
kernel: [14981.339861] sd 3:0:0:0: [sdb] Assuming drive cache: write through
kernel: [14981.339873] sd 3:0:0:0: [sdb] Attached SCSI removable disk
kernel: [15014.446419] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
kernel: [15360.625323] INFO: task umount:7148 blocked for more than 120 seconds.
kernel: [15360.625332] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kernel: [15360.625340] umount D 00000dd9 0 7148 6292 0x00000000
kernel: [15360.625353] f38bfe38 00000046 12abbd47 00000dd9 c1610cc0 c12c3890 c1610cc0 c1610cc0
kernel: [15360.625377] c1610cc0 c1610cc0 f6fc5790 c1610cc0 00010bbe 00000000 12aab189 00000dd9
kernel: [15360.625400] f6fc5500 f38bfe40 f38bfe70 00000000 f38bfe78 f38bfe40 c10b7cf0 f38bfe5c
kernel: [15360.625423] Call Trace:
kernel: [15360.625442] [<c12c3890>] ? _raw_spin_unlock_irqrestore+0x36/0x5b
kernel: [15360.625457] [<c10b7cf0>] bdi_sched_wait+0x8/0xc
kernel: [15360.625467] [<c12c20ef>] __wait_on_bit+0x34/0x5b
kernel: [15360.625477] [<c10b7ce8>] ? bdi_sched_wait+0x0/0xc
kernel: [15360.625487] [<c12c216d>] out_of_line_wait_on_bit+0x57/0x5f
kernel: [15360.625497] [<c10b7ce8>] ? bdi_sched_wait+0x0/0xc
kernel: [15360.625510] [<c103fa75>] ? wake_bit_function+0x0/0x4d
kernel: [15360.625521] [<c10b84d4>] wait_on_bit.clone.0+0x17/0x23
kernel: [15360.625531] [<c10b8544>] sync_inodes_sb+0x64/0x10d
kernel: [15360.625546] [<c10d373f>] ? vfs_quota_sync+0x0/0x1da
kernel: [15360.625556] [<c10baef6>] __sync_filesystem+0x37/0x62
kernel: [15360.625566] [<c10bb062>] sync_filesystem+0x3c/0x3f
kernel: [15360.625578] [<c10a2def>] generic_shutdown_super+0x1c/0xca
kernel: [15360.625588] [<c10a2eba>] kill_block_super+0x1d/0x31
kernel: [15360.625599] [<c10a3833>] deactivate_super+0x48/0x5a
kernel: [15360.625610] [<c10b385c>] mntput_no_expire+0x5e/0x89
kernel: [15360.625620] [<c10b41cf>] sys_umount+0x277/0x29b
kernel: [15360.625631] [<c10b4200>] sys_oldumount+0xd/0xf
kernel: [15360.625642] [<c1002813>] sysenter_do_call+0x12/0x32
kernel: [15360.625652] 1 lock held by umount/7148:
kernel: [15360.625657] #0: (&type->s_umount_key#32){++++..}, at: [<c10a382e>] deactivate_super+0x43/0x5a


> Can you do this with CONFIG_USB_DEBUG enabled? And acquire a usbmon
> trace at the same time (see Documentation/usb/usbmon.txt)?
>

Sure. Rebuilding the kernel right now.



Robert Hancock wrote:
> Is this some super-slow SD card or USB reader that you just wrote a bunch of data to?
> It's not impossible it could take 2 minutes for the writeout of all the dirty data to
> complete on unmount..
Please see above.

> did the unmount ever complete?
No entry in /etc/mtab. So, I guess, yes - umount complete.


Sergey
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2010-04-27 10:03    [W:0.177 / U:24.936 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site