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
