I've seen some buggy devices act this way. They can't handle the control requests interspersed between usb-storage transaction requests. It's a spec violation.
Matt On Mon, Mar 29, 2004 at 02:42:36PM +0100, Richard Curnow wrote: > We've found some kind of deadlock between these 2 subsystems. > To provoke it: > > 0. mount -t usbdevfs none /proc/bus/usb > > 1. plug a USB2 flash drive into a USB1.1 port. The device we're using > looks like this: > > T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=0ea0 ProdID=2168 Rev= 2.00 > S: Manufacturer=USB > S: Product=Mass stroage > S: SerialNumber=230760A43FEF7392 > C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=1ms > > 2. cat /proc/bus/usb/devices > > 3. badblocks -sv /dev/sda (or whatever device the flash drive is) > > 4. cat /proc/bus/usb/devices (concurrently with #3 running) > > The badblocks process is now stuck, and the output from step 4 is very > sluggish. > > We have reproduced this so far on these platforms: > > x86, UHCI, RH 2.4.18-14 kernel > x86, UHCI, stock 2.6.1 & 2.6.4 kernels > sh64, OHCI, 2.4.23-pre6 kernel > sh, Philips USB ISP1161A1BM, 2.4.23-pre6 kernel > > However the problem is not present on > sh64, OHCI, 2.4.26-pre2 kernel > > Perhaps this means there's been a fix in 2.4 between 2.4.23 and 2.4.26 > that's not been forward ported to 2.6 yet, or it may be something else > entirely. > > Taking the x86 2.6.4, "ps -auxww | grep ' D' " gives > > root 410 0.0 0.0 0 0 ? DW 14:10 0:00 [usb-storage] > root 411 0.0 0.0 0 0 ? DW 14:10 0:00 [scsi_eh_0] > root 441 0.0 0.1 1364 408 pts/1 D 14:13 0:00 badblocks -sv /dev/sda > > and Alt-SysRq-T filtered down to these processes gives > > usb-storage D 6C667D11 0 410 1 411 344 (L-TLB) > ce1f3e0c 00000046 d349ec20 6c667d11 0000009e 00000001 00000000 ce1f3df0 > ce1f3ddc 6c667d11 0000009e d349ec20 d349ec40 0002b5ee 6c667d11 0000009e > ce8849e0 ce1f2000 cc9c6cec ce1f3e30 ce1f3e68 c011c7be c03b00ad 00000753 > Call Trace: > [<c011c7be>] wait_for_completion+0x7e/0xb0 > [<c011c590>] default_wake_function+0x0/0x20 > [<c010b2ac>] common_interrupt+0x18/0x20 > [<c011c590>] default_wake_function+0x0/0x20 > [<c02c2cc9>] usb_sg_wait+0xa9/0x120 > [<c02d5e5a>] usb_stor_bulk_transfer_sglist+0x8a/0xe0 > [<c02d5ef4>] usb_stor_bulk_transfer_sg+0x44/0x80 > [<c02d6634>] usb_stor_Bulk_transport+0x124/0x2b0 > [<c02d5f54>] usb_stor_invoke_transport+0x24/0x2c0 > [<c011c590>] default_wake_function+0x0/0x20 > [<c02d551e>] usb_stor_transparent_scsi_command+0x1e/0x60 > [<c02d6c99>] usb_stor_control_thread+0x179/0x200 > [<c010b052>] ret_from_fork+0x6/0x14 > [<c02d6b20>] usb_stor_control_thread+0x0/0x200 > [<c02d6b20>] usb_stor_control_thread+0x0/0x200 > [<c01092b9>] kernel_thread_helper+0x5/0xc > > scsi_eh_0 D FFFF0174 0 411 1 410 (L-TLB) > ce74def0 00000046 00000002 ffff0174 40249fcc 00000002 ffff0175 40249fc9 > 00000002 ffff0176 40249fc6 00000002 ffff0177 00003c9c 69e10143 000000a5 > cdaa6fc0 ce74c000 cc9c6d14 ce74df14 ce74df4c c011c7be c03b00ad 00000753 > Call Trace: > [<c011c7be>] wait_for_completion+0x7e/0xb0 > [<c011c590>] default_wake_function+0x0/0x20 > [<c011c590>] default_wake_function+0x0/0x20 > [<c011b578>] recalc_task_prio+0xa8/0x1d0 > [<c02d4d26>] command_abort+0x76/0x90 > [<c0299ae5>] scsi_try_to_abort_cmd+0x45/0x50 > [<c0299c0a>] scsi_eh_abort_cmds+0x4a/0x80 > [<c029a5c5>] scsi_unjam_host+0x85/0xb0 > [<c029a6a8>] scsi_error_handler+0xb8/0xe0 > [<c029a5f0>] scsi_error_handler+0x0/0xe0 > [<c01092b9>] kernel_thread_helper+0x5/0xc > > badblocks D CEA505A0 0 441 317 (NOTLB) > cbe0dda4 00000082 c029baff cea505a0 c0265c5e cc9c6540 cea5057c cc9c6400 > ce884820 cbe0ddd8 cbe0dd8c c1337120 c1337140 0001224f bba1b6a6 00000099 > cdaa6480 c11def70 c1320880 cbe0ddd8 cbe0ddac c011d22e cbe0de04 c0137015 > Call Trace: > [<c029baff>] scsi_request_fn+0x1cf/0x2b0 > [<c0265c5e>] elv_next_request+0x4e/0x110 > [<c011d22e>] io_schedule+0xe/0x20 > [<c0137015>] __lock_page+0xa5/0xd0 > [<c011d9b0>] autoremove_wake_function+0x0/0x50 > [<c011d9b0>] autoremove_wake_function+0x0/0x50 > [<c013762d>] do_generic_mapping_read+0x2cd/0x3a0 > [<c0137700>] file_read_actor+0x0/0x100 > [<c01379a7>] __generic_file_aio_read+0x1a7/0x1e0 > [<c0137700>] file_read_actor+0x0/0x100 > [<c0137adf>] generic_file_read+0x8f/0xb0 > [<c011c590>] default_wake_function+0x0/0x20 > [<c011c590>] default_wake_function+0x0/0x20 > [<c0241c88>] tty_write+0x188/0x1e0 > [<c011b578>] recalc_task_prio+0xa8/0x1d0 > [<c0157e77>] block_llseek+0x37/0xe0 > [<c01509ca>] vfs_read+0xaa/0x130 > [<c0150705>] sys_lseek+0x65/0xc0 > [<c0150c7f>] sys_read+0x3f/0x60 > [<c010b13f>] syscall_call+0x7/0xb > > This message is repeated in the syslog: > > usb 1-2: control timeout on ep0in > > Does this leap out at anybody? Is there more information we can > provide? > > Cheers > Richard > > -- > Richard \\\ SH-4/SH-5 Core & Debug Architect > Curnow \\\ SuperH (UK) Ltd, Bristol > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > [EMAIL PROTECTED] > To unsubscribe, use the last form field at: > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver NYET! The evil stops here! -- Pitr User Friendly, 6/22/1998
pgp00000.pgp
Description: PGP signature
